Information Exposure Through Query String
ID |
csharp.information_exposure_through_query_string |
Severity |
low |
Remediation Complexity |
medium |
Remediation Risk |
low |
Remediation Effort |
medium |
Resource |
Information Leak |
Language |
CSharp |
Tags |
ASVS50:v8.3.1, CWE:598, NIST.SP.800-53, OWASP:2025:A04, PCI-DSS:6.5.10 |
Description
Sensitive data — a password, token, secret or API key — is placed in a URL query string.
Rationale
Data in a URL query string is not protected the way a request body is: it is written to web-server and proxy access logs, kept in the browser history, and forwarded in the Referer header to third-party sites. Even over HTTPS the full URL, including the query string, routinely ends up in logs and history. Sending credentials or tokens this way exposes them well beyond the intended endpoint.
// VULNERABLE: reading a secret from the query string (endpoint expects it in the URL)
var pwd = context.Request.Query["password"];
// VULNERABLE: building a URL whose query string carries a secret
// (the token lands in logs, history and Referer headers)
var url = $"https://api.example.com/data?access_token={token}";
var login = "/account/login?password=" + password;A URI whose scheme is not fetched over the network, such as the otpauth: URI an authenticator app reads from a QR code or a mailto: link, is not reported: its query string never reaches a server, a proxy or the browser history.
Remediation
Send sensitive values in the request body of a POST/PUT request, or in an Authorization header — never in the URL query string.
using var request = new HttpRequestMessage(HttpMethod.Post, "https://api.example.com/data");
request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", token);
// credentials go in the body, form-encoded or JSON, not the query stringReferences
-
CWE-598 : Use of GET Request Method With Sensitive Query Strings