URLs are copied, logged, cached, screenshotted, shared, analyzed, and stored in more places than most application developers realize. Putting an access token, password-reset token, API key, session identifier, or other sensitive value in a query string can therefore spread that secret far beyond the code that originally created the link.
MITRE's CWE-598 describes this directly: sensitive information in query strings can appear in browser history, Referer data, web logs, and other recording systems. The safest design is to keep credentials out of URLs whenever the protocol allows it.
Where URLs get recorded
A sensitive URL may appear in:
- browser history and synced history;
- reverse-proxy and web-server access logs;
- CDN and WAF logs;
- application performance monitoring;
- analytics platforms;
- error trackers;
- support tickets and screenshots;
- chat messages and email;
- network monitoring systems;
- Referer headers in some navigation scenarios.
That makes URL secrecy a poor assumption even when the initial connection uses HTTPS.
HTTPS does not fix URL storage
TLS protects the request in transit between endpoints. It does not stop the browser, server, proxy, CDN, application, or monitoring platform from recording the URL after decryption at its own layer.
A secret can therefore remain confidential on the network and still leak through logs.
API keys usually do not belong in query strings
Prefer authorization headers or another provider-documented credential mechanism:
Authorization: Bearer <token>Do not invent a custom header if the API already defines a standard mechanism. Follow the service's authentication contract.
Password-reset links are a special case
Password-reset flows often need a one-time token in a link because the user must click from an email. That creates unavoidable URL exposure, so the token must be designed accordingly.
Use high entropy, short expiration, single use, server-side invalidation after successful reset, and careful logging. Do not put the user's password, reusable session token, or other long-lived credential in the link.
Exchange URL tokens for safer state quickly
When a reset or magic-link token arrives in the URL, validate it and move the session into a safer server-managed state as early as practical. Redirect to a clean URL after consumption so the token is not left in the address bar throughout the workflow.
A token used only once and then invalidated has a much smaller exposure window than a reusable credential left in navigation history.
Understand Referer behavior
Modern browsers commonly use strict-origin-when-cross-origin as the default referrer policy. That means cross-origin requests generally send only the origin under normal HTTPS conditions, while same-origin navigation can still include path and query information.
Do not use the modern default as permission to put secrets in URLs. Applications embed third-party content, navigate within the same origin, and run in user agents with different policies.
Set Referrer-Policy deliberately
A site handling sensitive URL state can choose a stricter policy such as no-referrer or same-origin where appropriate. The correct choice depends on analytics, navigation, and integration requirements.
Vulnify's Security Headers Analyzer can help inspect the public Referrer-Policy alongside other security headers.
Logs need redaction even after code is fixed
Reverse proxies and application frameworks often log the complete request target by default. If sensitive parameters exist, configure redaction or structured logging that omits them.
Do not simply replace the parameter value after the access log has already captured the raw URL at an earlier layer. Trace the full logging path from CDN to application.
Analytics and error trackers can become secret stores
Client-side telemetry commonly records page URLs, navigation, breadcrumbs, and failed network requests. A tokenized link can be copied into a third-party dashboard automatically.
Configure URL scrubbing, parameter allowlists, and privacy controls in monitoring products. Test with a synthetic token to verify what actually leaves the browser.
Moving the value into the path does not solve the problem
/reset/SECRET may look cleaner than /reset?token=SECRET, but it is still a URL. Many loggers record the full path. Use route design for usability, not as a secrecy mechanism.
URL fragments behave differently, but are not magic secrecy
The browser does not send the fragment portion after # in the HTTP request. Some browser-based flows use fragments or client-side state for that reason. The value is still available to JavaScript, browser history, screenshots, extensions, and client-side telemetry.
Follow the relevant protocol instead of moving secrets between URL components ad hoc.
Rotate long-lived credentials found in URLs
If a reusable API key or bearer token has been exposed in production URLs, removing the parameter from new requests does not revoke copies already present in logs and history.
- Revoke or rotate the credential.
- Review access logs for suspicious use.
- Search logging and analytics systems for stored copies.
- Update the authentication design.
- Apply redaction to prevent recurrence.
Do not email reusable secrets merely because reset links are emailed
A password-reset token is designed to be short-lived and single-purpose. That does not make email a safe delivery channel for API keys, passwords, or permanent access tokens.
Keep the credential's lifetime and scope proportional to the exposure channel.
How Vulnify fits URL-secret review
Vulnify can inspect public security headers and exposed web behavior, but it cannot see every private CDN log, analytics dashboard, support ticket, or APM system where a URL may be stored. Repository and telemetry review remain necessary.
The Security Headers Analyzer is particularly relevant for checking Referrer-Policy, while a broader scan can identify related web configuration issues within supported scope.
Sensitive URL checklist
- Keep passwords, bearer tokens, and API keys out of query strings.
- Use protocol-defined authorization headers where available.
- Design reset and magic-link tokens as short-lived, single-use credentials.
- Redirect to a clean URL after consuming one-time tokens.
- Set an appropriate Referrer-Policy.
- Redact sensitive parameters in proxy and application logs.
- Scrub URLs in analytics and error tracking.
- Rotate reusable credentials that have already leaked.
- Test the entire telemetry path with synthetic values.
One-time links need deliberate binding decisions
A reset or magic-link token may be usable by anyone who possesses it. That is often the intended design, but the application should still decide whether additional context is required before a sensitive action completes. High-risk account changes may require a second factor, recent authentication, or re-entry of information known only to the account owner.
Do not bind tokens to fragile signals such as a single IP address without understanding the user impact. Mobile networks, VPNs, and privacy services can change addresses during a legitimate flow.
Avoid sensitive values in client-side routing state
Single-page applications often keep state in the URL so pages can be bookmarked or restored. That is appropriate for search filters and navigation, but not for reusable credentials. Router libraries, analytics SDKs, and error trackers may all observe route changes.
Store authenticated state in secure cookies or another protocol-appropriate mechanism and keep navigation URLs free of long-lived secrets.
Scrub URLs before third-party telemetry receives them
Many monitoring products offer hooks to redact query parameters or drop sensitive events. Configure those controls before a production incident forces you to discover where URLs have been replicated. Prefer an allowlist of safe parameters over a blacklist when the application has a small known set.
Also review session replay tools. They can capture address bars, form values, or network metadata depending on configuration.
Signed download links have the same lifecycle problem
Object-storage signed URLs are often intentionally bearer URLs. Keep their lifetime short, scope them to one object and operation, and avoid placing them in places that are broadly logged or indexed. If a customer needs long-term access, authorize a request and generate a fresh short-lived URL instead of issuing a permanent signed link.
Referrer-Policy cannot clean existing logs
Changing the header reduces future referrer leakage according to browser behavior, but it does not remove sensitive URLs already stored in access logs, analytics, or support systems. Incident response should identify the retention locations and decide whether stored copies need deletion or tighter access.
Credential rotation is still required for reusable secrets because copied values may exist outside systems you control.
Search and support tooling can recopy sensitive links
Internal search indexes, ticketing systems, chat bots, and knowledge-base tools may automatically unfurl or index URLs pasted by staff. A sensitive link copied during troubleshooting can therefore spread inside the organization even when no external referrer is involved.
Train support teams not to paste live bearer URLs into tickets. Provide redaction guidance and safe diagnostic identifiers such as request IDs or account IDs that do not grant access.
Use request bodies for sensitive form submissions
When a user submits a password, recovery code, API credential, or other sensitive field, send it in the request body over HTTPS rather than encoding it in the URL. This reduces exposure to routine URL logging and history.
The body can still be logged by badly configured systems, so application and proxy logging policies remain important. The improvement is reducing unnecessary propagation, not making the value magically invisible.
URLs are excellent identifiers and poor secret containers
URLs are intentionally observable. Design authentication around that reality. When a flow genuinely requires a tokenized link, make the token disposable. For everything reusable or privileged, keep the credential in a channel designed for credentials rather than in the address bar.