AI-Generated Open Redirect Review Rules

Purpose

Use these rules when an AI coding assistant writes or edits code that redirects or forwards a request to a URL influenced by user input. The goal is to stop a generated "return to previous page," post-login redirect, or similar feature from becoming an open redirect that phishing campaigns or access-control bypasses can exploit.

This is a review policy, not an open-redirect tutorial. It tells reviewers what must be true about a generated redirect's destination handling before the change is safe to merge.

Review Inputs

Collect enough context to know where a redirect destination comes from and where it can send a user.

• Every redirect, forward, or "return to" call the change adds or edits, and the exact source of its destination value (query parameter, form field, header, session/stored value).
• Whether the destination is ever a full URL versus always a relative path within the application.
• The application's trusted domain(s), if an allowlist check is relevant.
• Whether anything executes on the server after the redirect response is issued.

Destination Validation Rules

• Prefer a hardcoded or indexed-mapping destination over taking any part of the URL from the client. If the client only needs to pick from a small known set of destinations, send a key and look up the real path server-side.
• When a caller-supplied return path is required, accept only a relative, same-origin path: reject values that are absolute URLs, start with // (protocol-relative, which browsers treat as absolute), or contain a scheme such as http:, https:, or javascript:.
• If an absolute URL is unavoidable, validate the parsed hostname against an explicit allowlist of trusted domains — parse the URL and compare the host field exactly (or against an allowed-suffix list of real subdomains), never a raw substring/.includes()/prefix check on the whole URL string.
• Reject malformed or unparseable URLs outright rather than falling back to a default that might still be attacker-influenced.

Impact And Chaining Rules

• Treat an unvalidated redirect as more than a cosmetic risk: it can make phishing links look legitimate (the initial domain is trusted) and can be chained to bypass allowlist-based checks in a proxy, WAF, or gateway that only inspects the first hop.
• Check whether a redirect is used as part of an authentication or authorization flow (OAuth callback, SSO return URL, "continue to" after login) — these are higher-impact targets because a successful redirect can be paired with credential phishing or token leakage.
• Confirm the handler actually stops executing after issuing a redirect response; in some frameworks/languages, setting a Location header does not itself halt the rest of the function, so code intended to run "after redirect" can still execute for a client that doesn't follow it.

Merge Blockers

Block merge when any of these is true.

• A redirect or forward destination is built directly from user input (query parameter, form field, header, stored value) with no restriction to a relative path or validated allowlist.
• Destination validation uses a substring/prefix/.includes() check on the trusted domain instead of parsing the URL and comparing the actual host.
• An authentication/SSO-related redirect (login return URL, OAuth callback) accepts an unvalidated destination.
• Code intended to run after a redirect is issued does not actually stop execution when the redirect is set.

Review Checklist

• {"task": "Destination source identified", "description": "Every redirect's destination source (client input vs. hardcoded/mapped) is identified"}
• {"task": "Relative path preferred", "description": "User-influenced redirects are restricted to relative, same-origin paths where possible"}
• {"task": "Allowlist for absolute URLs", "description": "Any absolute-URL destination is validated against a real parsed-host allowlist, not a substring check"}
• {"task": "Protocol-relative and scheme rejected", "description": "Values starting with // or containing a scheme (javascript:, https:, etc.) are rejected as relative paths"}
• {"task": "Auth-flow redirects scrutinized", "description": "Login/SSO/OAuth return-URL redirects get the strictest validation, not the general-purpose one"}
• {"task": "Execution halts on redirect", "description": "No code intended to run only after a redirect executes for clients that ignore it"}

AI Review Rules

AI assistants can write and review redirect logic, but they should show their evidence.

• Ask the assistant to list every redirect/forward in the change and the exact source of its destination value.
• Require the assistant to state whether each destination is restricted to a relative path or validated against a real host allowlist, not just "checked."
• Have the assistant show the allowlist check's exact comparison logic (not a substring/prefix check) when an absolute URL destination is accepted.
• Do not let the assistant claim a redirect is safe because it "looks like" it points at the right domain in the happy-path example.
• Re-run review after any change to authentication flows, SSO callbacks, or shared redirect helper functions.

Troubleshooting

• A legitimate cross-subdomain redirect gets rejected: add the specific subdomain to the allowlist explicitly rather than loosening the check to a suffix or substring match that could also match attacker-registered lookalike domains.
• The relative-path restriction breaks a valid external partner redirect: that destination needs its own reviewed, explicit allowlist entry — do not remove the restriction to accommodate one case.
• Tests only cover a same-site redirect: add a test asserting that an off-site or protocol-relative (//evil.example) destination is rejected, not just that the happy-path destination works.
• A redirect works even though a check was added: confirm the check actually runs before the redirect call and that the function returns/exits after a rejection instead of falling through to redirect anyway.

Duplicate And History Check

Before adding a new redirect destination check, confirm the codebase does not already have a shared "safe redirect" helper or allowlist. A generated change that builds a new ad hoc validation next to an existing shared helper should be treated as suspicious — check whether the existing mechanism was simply not reused before introducing a second, potentially inconsistent one.

Reference

Sources

• OWASP Unvalidated Redirects and Forwards Cheat Sheet
• CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
• PortSwigger Web Security Academy: DOM-based open redirection
• PortSwigger: Open redirection (reflected) issue reference

• Source repositorygithub.com 2026-07-16T13:01:56+00:00
• Documentationcheatsheetseries.owasp.org
• Submitted by lourincedaging0-commits2026-07-15