Any credential, token, redemption code, or identifier embedded in a query string, path, or fragment. These values are risky because URLs are copied, logged, cached, shared, and exposed through browser state far more often than security teams expect.
Expanded Definition
A URL-carried secret is any sensitive value placed into a URL component, including the query string, path, or fragment. In practice, that can mean session tokens, invite codes, password reset links, API keys, or machine-readable redemption values that are embedded for convenience and then reused outside the original context. This pattern is especially dangerous in identity-heavy workflows because URLs are designed to move through browser history, referrers, logs, link previews, analytics tools, reverse proxies, and ticketing systems. Once exposed, a URL-carried secret often outlives the action it was meant to enable.
Definitions vary across vendors on whether a one-time code remains a “secret” after first use, but from a security operations perspective the risk is the same: if a value grants access or triggers privileged action, it should be treated as sensitive from the moment it is embedded in a URL. NHI Management Group treats this as a design flaw rather than a logging problem, because the exposure usually begins before any monitoring control can intervene. The most common misapplication is assuming a short-lived link is safe when it is still copied into chat, browser sync, or web server logs.
For guidance on adjacent identity and credential handling risks, OWASP Non-Human Identity Top 10 is a useful reference point where secrets and machine identities intersect.
Examples and Use Cases
Implementing link-based workflows rigorously often introduces usability and delivery constraints, requiring organisations to weigh frictionless access against the risk of silent credential leakage.
- Password reset links that carry a bearer token in the query string and are forwarded through help desk systems or browser histories.
- One-time login or verification links sent by email, where the URL itself becomes the credential until it is consumed or expired.
- Invitation links for SaaS tenants or developer portals that expose tenant IDs or redemption codes in a path segment.
- Webhook setup URLs and callback endpoints that contain embedded API keys or secret parameters used for bootstrap access.
- Agent onboarding or machine registration links where a provisioned NHI receives a token via URL instead of a secure out-of-band exchange.
These use cases are often discussed in secure URL design guidance from standards bodies and web application communities, including OWASP Secrets Management Cheat Sheet and browser referrer privacy guidance. The point is not that links are unusable, but that the secret should be removed from the URL as early as possible, or exchanged for a non-sensitive handle after first contact.
Why It Matters for Security Teams
URL-carried secrets create a control failure that crosses application security, identity governance, and incident response. If a token is exposed through a URL, traditional protections like password complexity or MFA do not help, because the attacker may never need to authenticate in the normal sense. For identity teams, the issue becomes especially acute when URLs are used in onboarding, recovery, or machine trust flows, since those journeys often bridge human users, service accounts, and NHI lifecycles.
Security teams should treat URL exposure as a policy violation in development, testing, and production. That means blocking secret-bearing URLs in code review, avoiding secrets in referrer-visible redirects, and ensuring logs, analytics pipelines, and support tooling do not preserve sensitive query parameters. Where links must be used, the safer pattern is a short-lived, single-purpose identifier that is immediately exchanged for a credential through a protected channel.
Organisations typically encounter the operational impact only after a leak has been replayed from logs, chat transcripts, or browser history, at which point URL-carried secret handling becomes unavoidable to contain the exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Treats exposed secrets in identity flows as a core NHI governance risk. |
| NIST CSF 2.0 | PR.AC-1 | Covers access control and credential exposure risks created by unsafe URL handling. |
| NIST SP 800-53 Rev 5 | SC-28 | Protects information at rest and in transit, relevant when URLs leak sensitive tokens. |
| NIST SP 800-63 | Digital identity guidance informs secure use of recovery and verification links. | |
| NIST AI RMF | AI systems that issue links or tokens inherit risks from URL-carried secrets. |
Use single-use, short-lived recovery links and exchange them for stronger authenticated sessions.
