A scheduler mails technicians a link carrying the access token in the query string — which copies can you never recall?

## A URL is not a private place A credential in the query string is not protected by the fact that the connection is encrypted. Transport encryption hides the request from anyone watching the wire between two hops; it does nothing about the hops themselves. And a URL is the single most widely **copied** part of an HTTP request: the request line is what proxies log, what caches key on, what browsers remember, what users paste, and what pages repeat. Every one of those copies is created by software nobody on your team wrote and cannot reach afterwards. The turbine maintenance scheduler mails technicians a deep link to a shift board, and someone puts the access token in the query string because a mail client cannot set a request header. That is exactly the situation the trade-off exists for, so the honest thing is to enumerate the channels rather than wave at "don't do that". ## The channels, one at a time | channel | who creates the copy | can you recall it? | |---|---|---| | access logs at every hop | your server, a reverse proxy, a content delivery network | no — logs are shipped, indexed and retained | | the `Referer` on same-origin subresource requests | the browser | no — repeated on every asset the page loads | | a shared intermediary cache | the cache, keyed on the full URL | only by preventing storage in the first place | | history and bookmarks | the browser, at the user's request | only the user can, and only on that device | | pasted links and their previews | chat and ticketing systems fetching the URL | no — and the fetch itself uses the credential | Two of those deserve a closer look. **Logs are the channel that actually causes incidents.** Not because anyone is careless, but because the request line is logged *by default, everywhere*, long before your own code runs. The token lands in a file on a proxy, in a log-shipping pipeline, in a searchable index with a retention policy measured in weeks, readable by everybody with support access. A redaction rule added afterwards removes nothing that was already written. **The referring-page channel is narrowed, not closed.** Browsers changed their default so that a request to a *different* origin carries only the origin, not the path or query — so a query-string credential no longer routinely walks out to an unrelated host. But a request back to your own origin still carries the full URL, so every script, image and font the page loads repeats the credential in a header, and each of those requests is itself logged. Treat the channel as reduced, and do not tell an interviewer it is gone. ## What the specification actually says The OAuth 2.0 bearer-token specification, RFC 6750, defines three ways to present an access token: the `Authorization` request header with the `Bearer` scheme, a form-encoded body parameter, and a URI query parameter named `access_token`. It does not forbid the third. It says it **SHOULD NOT** be used unless it is impossible to carry the token in the header or in the body, and it gives the reason: the high likelihood that the URL will be logged. Quote that strength exactly. "SHOULD NOT with a narrow escape hatch" is a different claim from "MUST NOT", and upgrading it is the kind of small inaccuracy that costs a candidate credibility. The escape hatch exists because some clients genuinely cannot set a header — and that is the case you are in when the link arrives by mail. ## The fix, and what it costs 1. **Move the credential to the header** wherever a client can set one. This removes the URL channel completely: headers are not part of the cache key, not repeated in the referring-page header, not bookmarked, and not in the request line a proxy logs by default. 2. **Where a header is impossible, move it to the body.** A form-encoded parameter is not logged by default and not cached, though it forces the request to stop being a `GET`. 3. **Where neither is possible**, do not send the long-lived credential at all. Send a single-use, short-lived, narrowly scoped handle that the landing page exchanges once and then removes from the address bar. The thing that leaks is then worth much less, for a much shorter time. `Cache-Control: no-store` on the response belongs in all three cases, but be precise about what it does: it stops a cache storing the *response*. It does not touch the request line already in a log, the browser's history entry, or the header the page sends on its next asset request. ## The copies that already exist If a credential has been in a URL, treat it as disclosed. Not "probably fine because the link expired" — disclosed. Replace it, and then find out how long your log retention keeps the evidence of the exposure, because that retention window is the real duration of the incident, not the token's lifetime. A short expiry shrinks the window in which the leaked copy is useful; it does nothing about the copy existing. ## What to say when you are asked List the channels, say which of them you created and which the platform created for you, and then name the one you cannot recall: the log. Finish by quoting the specification at its actual strength and saying what you would do for the case that forced the URL in the first place.