OAuth token leak

The idea

An OAuth access token (a "bearer" token) is a credential: whoever holds it can act as the user. So the whole game is keeping it in places only your app can see.

The classic mistake is putting the token in the page URL, or letting it sit in a request URL. When that page loads anything from a third party — an analytics script, an image on a content delivery network (CDN), a font — the browser politely attaches a Referer header naming the page that triggered the request. That header carries the full URL, token included, straight to an origin you don't control. The token didn't get hacked out; it was handed over.

See it work

How it works

The fix is to keep the token out of any place the browser will copy elsewhere. Send it in the Authorization header (never the URL), keep it short-lived, and tell the browser not to broadcast page URLs cross-origin with a Referrer-Policy. With no-referrer the header is dropped entirely; strict-origin-when-cross-origin (a sensible default) sends only the bare origin, never the path or query.

# Server response headers on every page of the app
# 1. Stop the browser leaking full URLs to other origins.
Referrer-Policy: strict-origin-when-cross-origin

# 2. Defence in depth: limit where the page may even load from.
Content-Security-Policy: default-src 'self'; img-src 'self' https://cdn-metrics.io

# Calling the API: token rides in the header, never the URL.
GET /v1/me HTTP/1.1
Host: api.example
Authorization: Bearer tok_a3f9c2e7
# bad:  GET /v1/me?access_token=tok_a3f9c2e7   <-- token in URL, leaks via Referer

When something does slip, the response is mechanical: revoke and rotate the exposed token so the copy in someone else's logs is dead, then close the path that leaked it.

Signals

Watch out for

• Tokens in URLs at all. Query strings and path segments end up in browser history, server logs, proxies, and the Referer header. The Authorization header is the only safe place for a bearer token.
• Trusting a long token lifetime. A token that lives for days gives a thief a long window. Short-lived access tokens plus refresh rotation shrink the blast radius of any leak.
• Forgetting cross-origin sub-resources. One analytics tag, web font, or hot-linked image is enough — the leak doesn't need an attacker on your page, just an external request the browser makes for you.
• Revoking the session but not the token. Signing the user out doesn't invalidate a bearer token already copied elsewhere. You must revoke that specific token server-side.
• Setting Referrer-Policy on some routes only. The OAuth redirect and callback page is exactly where tokens and codes appear; apply the policy site-wide, not per-page.

Worked example

A dashboard at app.example renders the user's access token into the page URL so a deep link can be shared: /dash?access_token=tok_a3f9c2e7. The same page embeds an analytics pixel from cdn-metrics.io. When the browser fetches that pixel, it sends Referer: https://app.example/dash?access_token=tok_a3f9c2e7 — the live token, in plain text, into a third party's logs. Days later, the metrics vendor's log export is reviewed and the token is spotted. Triage confirms the value is a real, still-valid token. Containment: the token is revoked and the user's session rotated, so the copy in the vendor's logs is now useless; then Referrer-Policy: strict-origin-when-cross-origin is shipped so only https://app.example would have been sent. Root cause: the token never belonged in the URL — it moves to the Authorization header, and deep links use a short opaque id instead.

Check yourself