Is every redirect a vulnerability?

No. Same-site HTTPS upgrades and short canonical hops are fine. The miss is an unvalidated destination or a credential in the URL.

Are password-reset links in email unsafe?

They are a common pattern. Keep them single-use, short-lived, and do not bounce them through third-party redirectors. Prefer a page that does not echo the token in Referer to other origins.

How does RoastMyOpsec inspect redirects?

It follows public redirects within bounds, compares public-suffix domains, and looks at parameter names with values redacted. No session theft.

Vulnerabilities

Open Redirects vs Tokens in URLs

November 22, 2024

Open redirects vs tokens in URLs are two ways a public site donates trust. An open redirect lets a stranger pick the next location on your hostname. Tokens in query strings (reset links, OAuth codes, session ids) show up in logs, history, and Referer. Together they are how a magic link walks off-site. RoastMyOpsec follows a bounded public redirect chain, compares registrable domains, and inspects parameter names while redacting values. It does not steal sessions or fuzz open-redirect payloads.

The practical difference

A redirect is a Location header (or meta/JS hop). Same-site HTTPS to HTTPS with a short chain is normal. A hop to a different registrable domain is a new trust boundary. An unvalidated next= parameter is how that boundary becomes attacker-controlled.

A token in the URL is a credential in a place browsers treat as less secret than a cookie. Even with a tight Referrer-Policy, your CDN logs still saw it.

How to choose a fix order

Ban open redirects: allowlists of paths on your origin, never a free-form URL. Put secrets in POST bodies, HttpOnly cookies, or one-time server-side stores — not ?token=. Collapse marketing redirect chains so ads do not bounce through three trackers.

Pattern	Risk	First move	Takeaway
http → https on the same host	First-hop cleartext	Keep it; add HSTS	See the HSTS vs redirect guide
next=https://evil.example	Phishing on your hostname	Allowlist relative paths only	Open redirect is the miss
?reset= or ?code= in GET	Logs, Referer, history	One-time store; short TTL	Do not put vault keys in the address bar
OAuth callback with extra hops	Code leakage	Exact redirect URI; no third-party bounce	Register the URI at the IdP

When a long chain still fails OPSEC

Campaign tools love redirector hosts. Each hop is another log. If a token rides along, every hop is a leak. Strip query strings before leaving your origin.

Pair this with the Referrer-Policy guide: policy reduces outbound Referer; it does not fix your own query strings.

Common mistakes

The first mistake is decode-then-redirect on a user-supplied URL.

The second mistake is putting the session in the fragment and then a hop that drops the fragment into a query.

The third mistake is collapsing HTTPS redirects but leaving a tracking domain in the middle.

Free audit the URL you own

RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.

Free audit now

FAQ

Is every redirect a vulnerability?: No. Same-site HTTPS upgrades and short canonical hops are fine. The miss is an unvalidated destination or a credential in the URL.
Are password-reset links in email unsafe?: They are a common pattern. Keep them single-use, short-lived, and do not bounce them through third-party redirectors. Prefer a page that does not echo the token in Referer to other origins.
How does RoastMyOpsec inspect redirects?: It follows public redirects within bounds, compares public-suffix domains, and looks at parameter names with values redacted. No session theft.