Insecure Authentication via HTTP GET

html.insecure_authentication

Severity

high

Resource

Information Leak

Language

Html

Description

This rule identifies authentication forms that transmit passwords or other sensitive credentials using the HTTP GET method. When credentials are sent via GET, they are appended to the URL query string and exposed to multiple storage and transmission mechanisms outside the application’s control.

Credentials sent via GET are not treated as confidential data by browsers or intermediaries and can be trivially leaked to unauthorized parties.

Rationale

Using the HTTP GET method for authentication introduces severe and often irreversible information disclosure risks:

URL-Based Credential Exposure: The GET method appends form data directly to the URL, making credentials visible in: - Browser address bars - Browser history - Bookmarks - Screenshots and screen recordings - Copy-pasted URLs shared with others

Persistent Logging of Credentials: URLs containing credentials are commonly logged by: - Web servers (access logs) - Reverse proxies and load balancers - CDN providers - Application performance monitoring tools - Security appliances and firewalls

These logs are often retained for long periods and accessed by multiple systems and operators.

Referer Header Leakage: When a user follows a link after authenticating, the full URL (including query parameters) may be sent in the Referer HTTP header to: - Third-party analytics services - External links - Embedded resources (images, scripts, iframes) - Advertisement networks

This results in silent credential exfiltration to external domains.

Violation of Security Standards: Most security standards explicitly prohibit transmitting authentication secrets via URLs: - OWASP prohibits credentials in URLs - PCI-DSS forbids exposure of authentication data in logs - NIST recommends protecting memorized secrets in transit and storage - CWE-549 classifies this as missing protection of sensitive data

Irreversibility of Leakage: Once credentials appear in logs or browser history, they: - Cannot be reliably erased - May persist in backups - Can be indexed by internal search tools - Are often overlooked during incident response

Consider the following vulnerable code:

<!-- Password transmitted via HTTP GET -->
<form action="/login" method="GET">
  <input type="text" name="username" />
  <input type="password" name="password" />
  <button type="submit">Login</button>
</form>

<!-- Implicit GET method (default behavior) -->
<form action="/authenticate">
  <input type="password" name="passwd" />
</form>

<!-- URL example after submission -->
/login?username=admin&password=SuperSecret123

Remediation

Authentication forms must always transmit credentials using the HTTP POST method over HTTPS. This prevents credentials from being embedded in URLs and limits their exposure to logging and referral mechanisms.

Vulnerable Patterns:

<!-- Explicit GET method -->
<form method="GET" action="/login">
  <input type="password" name="password" />
</form>

<!-- Missing method attribute defaults to GET -->
<form action="/auth">
  <input type="password" name="pwd" />
</form>

<!-- GET with sensitive query parameters -->
<a href="/login?user=admin&password=secret">Login</a>

Secure Patterns:

<!-- Secure authentication using POST -->
<form method="POST" action="/login">
  <label for="username">Username</label>
  <input type="text"
         id="username"
         name="username"
         autocomplete="username"
         required />

  <label for="password">Password</label>
  <input type="password"
         id="password"
         name="password"
         autocomplete="current-password"
         required />

  <button type="submit">Sign In</button>
</form>

Additional Hardening Measures:

Always use HTTPS
- Prevents interception of credentials in transit
- Mandatory for any authentication endpoint
Avoid credentials in URLs entirely
- Never pass passwords, tokens, or secrets as query parameters
- Applies to links, redirects, and API calls
Disable logging of sensitive parameters
- Scrub authentication fields from logs
- Apply log filtering at reverse proxy and application levels
Use CSRF protections
- Include CSRF tokens in POST-based authentication forms
- Prevents credential submission via forged requests
Implement proper cache controls
- Use Cache-Control: no-store on authentication responses
- Prevents caching of sensitive data
Review third-party integrations
- Ensure analytics and monitoring tools do not capture request URLs containing secrets

Insecure Authentication via HTTP GET

Description

Rationale

Remediation

References