A password submitted via GET is sent in the URL query string instead of the request body. This exposes secrets in browser history, server logs, analytics, caches, and referrer headers, creating a high risk of credential leakage. Secure authentication should use POST over TLS and avoid placing secrets in URLs.
What It Means to Put a Password in the URL
Submitting a password via GET places it in the query string, which makes the secret part of the visible request URL rather than private form data. That design choice changes the exposure surface immediately, because URLs are routinely copied, stored, and inspected by multiple layers of the web stack.
The key issue is not the browser alone, but the entire request path. Once a secret becomes part of the URL, it may be retained in history, proxy records, server access logs, analytics tooling, bookmarks, and referrer handling, any of which can outlive the original session.
Why This Is Dangerous
URLs are fundamentally poor containers for secrets because they are designed for routing and retrieval, not confidentiality. Even if the transport is encrypted, the secret can still leak through application telemetry, reverse proxies, shared infrastructure, error reports, or anyone with visibility into logs and traces.
This pattern also increases the blast radius of a single mistake. A password exposed in a URL can be disclosed to unrelated internal operators, third-party observability tools, browser plugins, and downstream services that see the request metadata. For organisations trying to reduce credential exposure, this is a classic avoidable failure mode.
For secure authentication design, use POST over TLS and keep secrets out of URLs entirely. The browser should send credentials in the request body, while the URL remains free of sensitive material that could be cached, forwarded, or replayed in unintended places. This aligns with NIST SP 800-53 Rev 5 Security and Privacy Controls, which treats authenticated access and logging controls as core security obligations.
How Exposure Typically Happens
The most common exposure path is indirect. A user submits a form, the URL is logged by web servers or intermediaries, and the password later appears in places that were never intended to store secrets. Referrer headers can also propagate the full URL to another destination when a page loads external content or the user navigates away.
Operationally, the danger is that the leak is often silent. The application may still function normally, while the password has already been copied into logs, caches, browser history, monitoring systems, or incident tools. That makes this a data handling problem as much as an authentication problem.
Good web authentication design avoids exposing secrets in request metadata and keeps a clear separation between identity material and addressable resource identifiers. Guidance on NIST SP 800-63 Digital Identity Guidelines reinforces the broader principle that authenticators should be handled in ways that minimise disclosure and misuse.
What to Check and What to Fix
To assess exposure, inspect application code, form handlers, reverse proxy rules, load balancer logs, WAF logs, analytics pipelines, and any downstream observability products that may capture full URLs. Search for login endpoints or password reset flows that use query parameters, and review whether referrer policy settings could propagate secrets to third parties.
The practical fix is simple but non-negotiable: move credential submission to POST, ensure TLS is enforced, remove logging of sensitive query strings where possible, and review whether existing logs or caches already contain leaked values. If the pattern has been deployed in production, treat it as a credential exposure event and verify whether affected passwords or sessions should be rotated.
For log hygiene and control hardening, the most relevant governance lens is to prevent the collection of secret-bearing URLs in the first place. The same principle appears in NIST Cybersecurity Framework 2.0, which emphasises protecting sensitive data and reducing exposure across operational systems.
Risk and Threat Considerations
Passwords in URLs create a durable credential leakage risk because they can be copied into logs, caches, browser history, referrer headers, and analytics systems that were never meant to protect secrets. The issue is especially serious when the same URL is shared across teams, vendors, or support workflows.
Failure mechanism: The application places authentication material into a request field that is routinely recorded and redistributed by infrastructure components, so the secret escapes the intended trust boundary even without an overt exploit.
Impact: Attackers or unauthorised insiders who obtain those records may reuse the password to access the account, escalate access if credentials are reused elsewhere, or pivot into additional systems protected by the same secret.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, OWASP ASVS and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | URL secret leakage is often amplified by logging of request data. |
| IA-5 — Authenticator Management | Passwords in URLs are authentication material handled insecurely. | |
| SC-8 — Transmission Confidentiality and Integrity | Passwords sent in query strings still require protected transmission controls. | |
| Recommendation — Exclude secrets from logged request metadata and review log capture rules. Keep authenticators out of URLs and manage them through protected authentication flows. Enforce TLS for authentication traffic and protect credential transmission end to end. | ||
| OWASP ASVS | V6 — Authentication | Authentication should not place secrets in URLs or other exposed request metadata. |
| V16 — Security Logging and Error Handling | Leaked passwords often enter logs, traces, and error telemetry. | |
| Recommendation — Require credential submission through secure authentication mechanisms that avoid URL leakage. Prevent secret-bearing requests from being written to logs or error output. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | Captured URLs can store credentials in logs and archives that persist at rest. |
| PR.AA-05 — Access permissions and authorizations are defined, managed, enforced, and reviewed. | Leaked passwords can undermine access control by bypassing intended authentication. | |
| Recommendation — Protect stored request records and remove sensitive data from retained telemetry. Review and enforce access controls so leaked credentials cannot be reused unchecked. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Authentication data in URLs is a direct authentication weakness. |
| Recommendation — Keep authentication material out of URL parameters and validate auth flows securely. | ||
Practitioner Guidance
Why practitioners should care: This is one of the clearest examples of avoidable secret exposure in web authentication. A seemingly minor implementation choice can turn normal operational telemetry into a credential distribution channel.
What to watch for: Any authentication flow that accepts secrets in query parameters, or any log pipeline that records full URLs by default, deserves immediate review. If the same credential appears anywhere outside the intended login flow, assume it has lost confidentiality.
Practitioner takeaway: Treat URLs as public metadata, not secret transport, and design login flows so that no password ever has to appear outside the protected request body.