No. An SDK should send API keys and tokens in an HTTP header, not in the URL query string. URLs are logged by servers, proxies and browsers, so a key placed there is copied into places you do not control. Support the query form only as a documented last resort.
What the standards say
RFC 6750, which defines bearer tokens, does allow an access token in a query parameter, but it says that method should not be used unless it is impossible to carry the token in a header. It gives the reason directly: there is a high likelihood that the URL containing the token will be logged. Its security section adds that bearer tokens should not be passed in page URLs and should go in message headers or bodies instead.
The OWASP REST Security Cheat Sheet makes the same point from the API side. It says passwords, security tokens and API keys should not appear in the URL, because web server logs capture URLs and that makes them valuable to an attacker. Its own example of a bad request is a URL with an apiKey query parameter.
Where a leaked URL ends up
- Web server and load balancer access logs, often retained for months.
- Reverse proxies, corporate gateways and CDNs.
- Browser history and the Referer header when a user follows a link from a page.
- Error reports and crash dumps that capture the failing request URL.
- Screenshots, tickets and chat messages where someone pastes the failing call.
Your SDK cannot control any of these, which is why the safe default is to keep secrets out of the URL entirely.
Steps to remove keys from URLs
- Accept credentials only through a constructor argument or an environment variable, and attach them to the Authorization header, or a clearly named header, inside the SDK.
- Build URLs from a path and a parameter map that never includes the credential, so a developer cannot add it by accident.
- If your API still accepts a key in the query string, announce a deprecation, return a response header that tells callers, and give a removal date. The Deprecation and Sunset headers are suited to this.
- Redact query strings when your SDK logs requests. Treat any parameter named key, token, secret or signature as sensitive by name.
- On the server, stop writing full query strings to access logs for authenticated routes, and rotate any key that was ever seen in one.
- Add a test that fails if any outgoing request URL contains the configured credential value.
What about signed URLs?
Some designs need a link a browser can open without custom headers, such as a file download. A short lived signed URL is a different thing from a long lived API key in a query string. Keep the lifetime short, scope it to one object, and make sure it cannot be used for anything else. Your SDK should hand these out only on request and warn in docs that they are bearer secrets for their lifetime.
Migration notes for existing customers
Removing query string support in a patch release will break callers, so treat it as a deprecation with a window. Warn first, log a counter of how many requests still use the old form, and contact the largest remaining callers directly. The counter tells you when removal is safe.
Quick check
Is it fine if the request is over HTTPS?
HTTPS protects the URL in transit, but the URL is still written to logs at the endpoints and may appear in history and referrers. TLS does not fix that.
Does a query string key violate the OAuth bearer token RFC?
RFC 6750 permits it but says it should not be used unless the header method is impossible. Treat it as a discouraged option.
Safeguard's policies, gates and guardrails can enforce rules like this in pull requests across your repositories, and its SBOM and dependency scanning shows which client libraries you ship. A free scan is a quick place to start.
Sources
Last reviewed: 19 October 2026.
