Payloads.
Pick a vulnerability class, learn how to hunt it step by step, grab the payloads that actually work. Curated from PayloadsAllTheThings — the full section is linked under every class.
Open Redirect
Unvalidated redirects send users wherever the URL says — phishing with your victim's own trusted domain. Alone it's usually low/medium; chained into OAuth or token flows it becomes account takeover.
Severity guide
Low-medium alone (many programs pay nothing for it); high when it chains into OAuth/token theft — always hunt for the chain before reporting.
Where to look
entry points to test first01
Login/logout/return URLs
?next=, ?redirect=, ?returnTo=, ?url=, ?r= — every auth flow bounces somewhere.
02
OAuth redirect_uri
The highest-value redirect in any app — validation flaws here are account takeover.
03
Email/link features
Click-tracking wrappers, unsubscribe links — server-side redirectors inside the trusted domain.
04
Share/invite flows
Referral and invitation links that pass destinations through.
05
Client-side redirects
window.location = getParam('next') — same bug, client-side, still phishable.
How to hunt it
in order, start to finishFind redirect parameters
url=, next=, redirect=, returnTo=, r= — and any login/logout flow that bounces through a URL.
Test a full external URL
?url=https://evil.com — an unfiltered hop means it's reportable immediately.
Bypass allow-lists
Whitelisted? Try //evil.com, https:evil.com, theirsite.com@yoursite.com, subdomain confusion, or parameter pollution (?next=safe&next=evil).
Hunt the token flow
Does any auth/OAuth flow pass tokens through redirects? redirect_uri carrying codes/tokens to attacker domains is account takeover — report the chain.
Escalate with token theft
OAuth/state flows that redirect to attacker URLs turn this into account takeover — report the chain, not the hop.
Filter & validation bypasses
when your first tries get blocked- 01Scheme checked? Protocol-relative //evil.com or missing-slash https:evil.com pass naive regexes.
- 02Domain allow-listed? Subdomain tricks (evil.target.com via takeover), userinfo (target.com@evil.com), or dots-in-domain (。).
- 03Path-prefixed? /redirect/https://evil.com and //evil.com after the prefix normalize externally.
- 04Param validated once? HTTP Parameter Pollution (?next=safe&next=evil) — one layer reads the first, the router the last.
Impact ladder
what makes it payable- 01Phishing on a trusted domain — victims see a real URL, then land on evil.com.
- 02OAuth code/token theft — the chain to full account takeover.
- 03Chained XSS — javascript: URIs where the redirect is client-side.
- 04SSRF pair — server-side redirect followers turn the same flaw internal.
Payloads
7 · from PayloadsAllTheThings\/\/google.com/Protocol-relative redirect — bypasses scheme checks.
/\/google.com/Path-prefixed variant that still normalizes to an external host.
https:google.comMissing-slash form — some validators accept it as relative.
?next=whitelisted.com&next=google.comParameter pollution — one layer validates the first, the other reads the last.
http://www.theirsite.com@yoursite.com/userinfo trick — everything before @ is credentials, the real target is yoursite.
/?redir=google。comUnicode full-stop — normalizes to a dot after validation.
java%0d%0ascript%0d%0a:alert(0)CRLF-embedded javascript: scheme — chained XSS via redirect.
Payload strings, code and technical terms are shown in English on purpose — payloads must be copied exactly as published.
Payloads originate from PayloadsAllTheThings (MIT) — use them only on programs you're authorized to test.