mediumCWE-598A02:2021

Sensitive Data in URL Query Strings

Tokens, passwords, or sensitive identifiers passed as URL query parameters, where they're visible in browser history, server logs, Referrer headers, and shared links.

How It Works

URLs appear in browser history, server access logs, CDN logs, analytics tools, and the HTTP Referer header (sent to every embedded resource). A password reset token in a URL like `/reset?token=abc123` is logged in your web server, visible to analytics SDKs, and forwarded to third-party scripts via Referer.

Vulnerable Code
// BAD: token in URL query string
const resetUrl = `https://yourapp.com/reset-password?token=${resetToken}&email=${email}`;
// This token appears in:
// - Browser history, server logs, CDN logs
// - HTTP Referer header sent to any embedded script
Secure Code
// GOOD: token in URL path (not query), one-time use
// Path params are still logged, but at least not in Referer
const resetUrl = `https://yourapp.com/reset-password/${resetToken}`;
// Even better: POST the token, not GET
// Or: validate and immediately redirect to a session-based flow

Real-World Example

Password reset tokens in URLs have been logged by nginx, CloudFlare, Google Analytics, Segment, and other tools. When these logs are exposed or shared, tokens are compromised. GitHub deprecated URL-based OAuth tokens after this exact issue.

How to Prevent It

  • Never put session tokens, passwords, or sensitive IDs in URL query parameters
  • Use POST requests to submit sensitive data, not GET
  • For password reset, use short-lived tokens and invalidate them immediately after use
  • Ensure Referrer-Policy: no-referrer or strict-origin is set to limit token leakage via Referer

Affected Technologies

ReactNext.jsnodejs

Data Hogo detects this vulnerability automatically.

Scan Your Repo Free

Related Vulnerabilities