Send bearer tokens in the Authorization header. RFC 6750 makes that the method every resource server must support, treats the form body as discouraged, and describes the URI query parameter as the least preferred route. OWASP also lists tokens in URLs as a sign of broken authentication.
The three methods
RFC 6750 section 2 defines three ways to transmit a bearer token:
- Authorization header. Preferred. Clients should use the Bearer scheme, and resource servers must support it.
- Form encoded body. Allowed only under strict conditions: a form content type, a single part body, ASCII only content and a non-GET method. It should not be used except where browsers cannot access the Authorization header.
- URI query parameter. Least preferred. Avoid unless the token cannot go in the header or body. Clients that use it should send a Cache-Control no-store header.
A request must not use more than one method.
Why the query string is worse
URLs get recorded in many places: server access logs, proxy logs, browser history, referrer headers and monitoring tools. A token in the URL is copied into all of them, often with long retention and wide access.
OWASP's broken authentication entry lists putting tokens and passwords in the URL among the signs that an API is vulnerable.
What to do
- Accept tokens only in the Authorization header on new APIs.
- If a legacy client needs the query form, scope that token narrowly and shorten its lifetime.
- Scrub tokens from access logs and error reports.
- Set Cache-Control no-store on responses to requests that carry tokens in the URL.
- Do not put tokens in redirect URLs.
Related safeguards from the RFC
RFC 6750 section 5 adds that TLS is mandatory on both channels, clients must validate certificate chains, and tokens valid for an hour or less reduce the impact of leakage. It says tokens should name the intended resource server and that scope should be restricted. It also says bearer tokens must not be stored in cookies that can be sent in cleartext.
Beyond that, consider binding tokens to a key. See bearer tokens versus DPoP.
Common patterns that break the rule
- Download links with a token parameter. Prefer short lived signed links created for one object.
- Webhooks that ask for the token in the callback URL. Use a header or a signed payload.
- WebSocket handshakes where the browser cannot set headers. Use a short lived one time ticket rather than the main access token.
- Debug tools that print full request URLs.
Quick check
Is the query string forbidden?
Not strictly. RFC 6750 allows it as a last resort. In practice, avoid it and mitigate if you cannot.
Does HTTPS hide a token in the URL?
It protects the URL in transit. It does not stop the URL being logged on either end or stored in history.
Safeguard's secrets related policies and the free scan at gold.safeguard.sh/scan can help you catch leaked credentials in dependencies and code, though log scrubbing stays with your team.
Sources
Last reviewed: 19 October 2026.
