How do you test unvalidated redirects and forwards?

How to test unvalidated redirects and forwards in practice

Start by treating every redirect or forward parameter as attacker-controlled input. Test whether the application accepts external URLs, alternate schemes, encoded variants, or path tricks, then confirm that only approved destinations are allowed. The key question is whether the application enforces a fixed allowlist or merely checks for a substring, suffix, or “looks internal” pattern.

Include both obvious and subtle bypass attempts. A redirect that appears harmless in a browser can still be abused if it preserves a trusted domain in the visible link while sending the user elsewhere after a click, or if a forward lets the requester reach a protected handler without the normal navigation path. That is why testing should cover direct requests, modified parameters, and any endpoint that accepts a return, next, url, target, or destination value.

Validate the failure condition as well as the success path. A secure implementation should reject off-domain destinations, normalize inputs before validation, and send users only to known internal routes or fixed post-action pages. If the application uses redirects after login, logout, password reset, or federated flows, check that the destination cannot be manipulated to support phishing, open redirect chaining, or access-control bypass.

What to probe when redirects are exposed to the user

Focus on places where the application reflects a URL or route supplied by the requester. Common targets include login return URLs, marketing links, error pages, confirmation pages, and “go back” buttons. If the application accepts a full URL, test whether it blocks external hosts, protocol-relative values, nested redirects, and encoded payloads that resolve after normalization. If it accepts a route, test whether path traversal, double encoding, or route aliases can push it outside the intended navigation set.

Forwarding deserves separate attention because it may happen server-side without changing the browser address bar. That makes it easier to overlook in ordinary testing, yet it can still change which handler processes the request and which authorization checks are applied. Confirm that protected resources still require the correct access checks after the forward, and that the application does not treat the forwarded target as already trusted just because it was reached internally.

When a redirect is intended, observe the exact response behavior. A safe implementation typically returns a clear reject response for invalid destinations, uses canonical destination mapping, and avoids letting user input directly select an arbitrary target. If the application logs the rejected value, verify that the logging does not become a separate injection or disclosure issue.

How to confirm the issue is actually exploitable

Prove impact, not just presence. A vulnerable redirect becomes materially useful to an attacker when it can support credential harvesting, session theft through user trust, malware delivery, or convincing phishing from a legitimate domain. A vulnerable forward becomes more serious when it can help reach content or functionality that should require a separate authorization decision.

Check whether the application rewrites the destination after validation, follows redirects in chained requests, or allows a user-supplied URL to be combined with a trusted base URL in unsafe ways. Also test whether the application normalizes input consistently across layers, because mismatched parsing between the application, reverse proxy, and browser can create a bypass even when the code appears to validate the value.

Web Application Attacks Guide covers open redirect patterns alongside other common web attack classes, which is useful when you want to place redirect testing in the wider context of input handling and request processing flaws.

Risk and Threat Considerations

unvalidated redirects and forwards are often treated as low severity because they look like navigation bugs, but they can become a trust abuse primitive. Attackers rely on the legitimacy of your domain to make malicious links look safe, then use the redirect to send victims to a phishing page or a payload delivery site.

Failure mechanism: The application accepts attacker-controlled destination data, then uses it without strong normalization and allowlist enforcement. In forwards, the same weakness can also alter the execution path inside the application and bypass the intended control flow or authorization boundary.

Impact: Users may be misled into trusting a malicious destination, security controls may be bypassed through unexpected internal routing, and the application can become a launch point for phishing, credential capture, or chained abuse of trusted URLs.

Practitioner Guidance

What to verify: Test the exact redirect and forward parameters with external hosts, encoded variants, and invalid internal routes, then verify that only a fixed allowlist of destinations succeeds. If the application is supposed to forward only within one workflow, confirm that the forward cannot be repurposed to reach another handler or skip a required check.

Decision rule: If the destination is user-influenced at all, treat direct string comparison as insufficient unless the application first canonicalizes the value and compares it to an approved destination set. If the business logic truly needs dynamic routing, constrain it to named route keys rather than raw URLs.

Practitioner takeaway: The real test is not whether the redirect “works”, it is whether untrusted input can change where trust is sent. If it can, the control should be redesigned so the application chooses the destination, not the requester.

Related resources from NHI Mgmt Group

• What are the key Unvalidated Redirects and Forwards best practices?
• What are common mistakes with unvalidated redirects and forwards?
• Unvalidated Redirects and Forwards
• How should teams test authentication flows that depend on redirects and cookies?