redirects

Overview

Redirects tell a browser to go to a different URL. They are everywhere in web apps (after login, for moved pages), and when they incorporate user input unsafely they become a security problem — the open redirect. This lesson covers redirects and their risks.

Learning objectives

• Explain how HTTP redirects work.
• Describe the open-redirect vulnerability.
• Identify safe redirect practices.

Core concept

A redirect is a response (status 3xx, e.g. 301 permanent or 302 found) with a Location header naming where the browser should go next. Applications use redirects constantly — for example, sending a user to their dashboard after login, or to the page they originally requested.

The risk arises when the redirect target is derived from user input without validation — an open redirect, where an attacker can make the application redirect victims to an arbitrary (malicious) site.

How it works

If an app reads a ?next= or ?returnUrl= parameter and redirects to it without checking, an attacker can craft a link to the trusted site that bounces the victim to an attacker-controlled site. Because the link starts on the legitimate domain, it lends credibility to phishing. Safe practice is to validate redirect targets against an allowlist of permitted destinations (or only allow relative paths within the site), never redirecting to an arbitrary user-supplied absolute URL.

Practical example

A login flow uses /login?next=/dashboard to return users after signing in. If it will redirect to any value of next, an attacker sends a victim a link like /login?next=https://evil.example — the victim trusts the legitimate login domain, logs in, and is then bounced to the attacker's look-alike site. Restricting next to relative in-site paths (or an allowlist) closes this. (Open redirects also amplify other attacks, e.g. some OAuth and SSRF chains.)

Cybersecurity relevance

Open redirects are a recognized web weakness: they strengthen phishing (a trusted domain in the link), can be chained into OAuth token theft or SSRF-related flows, and are common assessment findings. The defense is straightforward — validate redirect destinations against an allowlist or restrict to relative paths. Testers look for redirect parameters and try to point them off-site; defenders ensure only intended destinations are allowed.

Common mistakes

• Redirecting to an unvalidated user-supplied URL, creating an open redirect.
• Allowlisting by naive substring checks (e.g. "contains our domain"), which attackers bypass with crafted URLs.
• Underestimating open redirects as "low severity," ignoring their role in phishing and attack chains.

Key takeaways

• A redirect is a 3xx response with a Location header directing the browser elsewhere (301 permanent, 302 found).
• An open redirect occurs when the target comes from unvalidated user input, letting attackers bounce victims from a trusted site to a malicious one.
• Validate redirect targets against an allowlist or restrict to relative in-site paths; open redirects enable phishing and can chain into larger attacks.

Check your understanding

• What makes a redirect an "open redirect," and why is it useful to an attacker?
• What is a safe way to handle a next/returnUrl redirect parameter?