Restrict return URLs and external redirects
Review return-to parameters without trusting URL prefixes. Define accepted destinations, fallback behavior, and browser-visible redirect tests.
A return URL is navigation input, not an instruction the server must follow. Start by deciding whether the workflow needs external navigation at all. A signed-in user returning to a project page usually needs an application route, not an arbitrary destination.
OWASP discusses validation of redirects and forwards. The review worksheet below turns that principle into a destination policy for one application. Authentication callbacks and payment-provider handoffs need their own documented exceptions.
Replace destination freedom with a contract
Where possible, accept a short destination key that the server maps to a fixed route. If a full URL is necessary, parse it with the platform URL library and compare the relevant structured fields. Do not treat a string prefix as proof of host identity.
| Requested destination | Suggested handling | Review note |
|---|---|---|
| Known local destination key | Resolve to the owned route | Check user access at the destination |
| Approved absolute callback | Exact configured destination | Keep environment-specific configuration |
| Unrecognized external host | Reject or use a fixed safe fallback | Do not echo it into a link automatically |
| Ambiguous or malformed input | Reject before navigation | Record only a redacted reason |
Keep redirect authorization separate from destination-page authorization. A permitted local path can still identify a record the current user cannot access.
Test what the browser finally opens
Create synthetic cases for a changed scheme, unexpected port, encoded separator, user-information field, and a hostname that merely resembles the approved host. Include relative paths and protocol-relative forms if the parser accepts them.
Check the final Location header and the browser destination on controlled pages. An initial safe redirect can lead to another redirect that reintroduces an untrusted parameter. Trace the complete approved journey rather than testing only the first handler. Never put real credentials or recovery tokens in the test URL.
Preserve a predictable failure path
Choose a fixed fallback such as the account overview, or show an explicit validation error before leaving the page. Avoid constructing the fallback from the same invalid value. Confirm that error handling does not display unescaped input or disclose tokens in logs.
Store the policy owner, approved destination set, and rejection tests with the route. When an integration changes its callback, review that exact change rather than broadening the rule to every subdomain. The finished test should show both the intended return journey and the rejected destination remaining outside the navigation path.
Find the gaps before your next launch
Use the release checklist to identify changed security boundaries and missing evidence. Discuss the application paths you want reviewed before launch.