Redirect

What a redirect is and why it matters

A redirect is a routing instruction, delivered by the server or browser, that moves a user from one URL to another. It is common in site migrations, canonicalisation, and login flows, but it only works safely when the destination is tightly controlled and the browser is not allowed to choose an arbitrary target.

For security teams, the important distinction is between a legitimate redirect and a user-controlled redirect parameter. The first preserves application intent; the second can become an abuse path for phishing, token theft, or trust boundary bypass if the destination is not validated.

How redirects work in web applications

Servers can issue redirects with HTTP response codes, while client-side code can also send the browser onward after a page loads. In both cases, the browser follows a new location, but the security properties differ because server-side redirects are easier to govern and audit than logic embedded in scripts or application parameters.

Redirects are often used to normalise URLs, preserve SEO value, move users from old paths to new ones, or send unauthenticated users to a sign-in page. In those legitimate cases, the redirect target should usually be fixed, derived from a trusted mapping, or restricted to an approved set of locations.

When the target is taken directly from query strings, form fields, headers, or other user input, the application must treat it as untrusted data. That is where open redirect abuse starts: the application becomes a trusted trampoline to an attacker-controlled destination.

Security implications of open redirect abuse

An open redirect does not always start as a standalone vulnerability, but it can materially weaken the safety of authentication and navigation flows. Attackers use it to make malicious links look more trustworthy, to chain users through trusted domains, and to support social engineering that depends on an apparently legitimate first hop.

Redirects can also create confusion in security controls that inspect only the initial URL, especially when users are sent through multiple hops or when different components apply different allowlists. That is why redirect handling is part of broader application trust management, not just page navigation.

Safe redirect design and validation patterns

The safest pattern is to keep redirect destinations server-controlled whenever possible. If user choice is required, constrain destinations to a strict allowlist, use opaque route identifiers instead of raw URLs, and reject any absolute URL, protocol-relative URL, or encoded variant that escapes the approved set.

Good redirect logic also needs consistent normalisation. The application should compare the final interpreted destination, not just the raw string, because encoding tricks, mixed slashes, and host manipulation can bypass superficial checks.

Redirects should be reviewed wherever they intersect with sign-in, password reset, logout, and post-transaction flows. Those paths are especially sensitive because a weak redirect can affect both user trust and the integrity of the surrounding control.

Operational testing and review points

Test redirect handling as part of application security review, not just functional QA. Look for parameters that accept destination values, chained redirects, wildcard allowlists, and places where redirects cross from a trusted domain into an external one without a clear business need.

Security teams should also review logging and monitoring for suspicious redirect patterns, especially repeated attempts to supply external destinations or encoded payloads that try to evade validation. Redirect abuse is often low-noise, so simple visibility into destination parameters can make a real difference.

When redirects are used for legitimate routing, document the allowed destinations and ownership of the logic. That makes it easier to spot unintended changes, review exceptions, and keep security, product, and platform teams aligned on what the redirect is supposed to do.

Related resources from NHI Mgmt Group

• What is the difference between redirect URI validation and PKCE?
• What breaks when Google OAuth redirect URIs are not registered exactly?
• How do teams know whether redirect URI management is under control?
• Who is accountable when a redirect URI migration breaks sign-in?