Open redirect
An application redirects to a URL taken from the request without validating it (CWE-601), so attackers can borrow its domain for phishing or to capture OAuth codes and tokens.
- Also called
- unvalidated redirect
- Fix it in your stack
- Open redirect fix cards (10 stacks) · CWE-601 page
- Defined in
- MITRE CWE-601
- Identifiers
- CWE-601: Open redirect
Covered in
Redirect users only to destinations you control
Check every redirect target taken from a request, so attackers cannot borrow your domain for phishing, carry OAuth tokens off-site or steer a server-side fetcher through your redirects.
OAuth 2.0 and OpenID Connect login: authorization code with PKCE
Implement OAuth 2.0 and OpenID Connect login with the authorization code flow and PKCE, keep each transaction bound to its browser, and block redirect, mix-up, code-injection and token-theft attacks.
Defend OAuth and OIDC against redirect and token attacks
Apply RFC 9700 and RFC 10017: exact redirect matching, PKCE with downgrade protection, state and iss binding, refresh-token rotation, sender-constrained tokens, and a backend-for-frontend so browser tokens cannot be stolen.
Consume third-party APIs safely (OWASP API10:2023)
Treat every upstream and third-party API response as untrusted input: validate it against a schema, set connect and read timeouts, cap the response size, refuse to follow redirects blindly, keep TLS verification on, and scope the credentials you hold for each provider.
Prevent CRLF header injection, log forging and CSV formula injection
Carriage return and line feed separate HTTP header fields, log records and CSV rows, and a leading = turns a spreadsheet cell into a formula. Let the framework write headers, log structured JSON, and neutralize formula triggers in exports.
Practice: Open redirect lab: Return users to this site only · OAuth redirect and PKCE lab: Match redirect URIs and verify PKCE