miji.beAn open redirect is a vulnerability in which a web application uses a URL parameter value as a redirect destination without validating it. OWASP (Open Web Application Security Project) catalogs it in the Top 10 as CWE-601 (URL Redirection to Untrusted Site), mapped to Broken Access Control (A01), the top-ranked category in the 2025 edition.
Here is a concrete example. With a URL like "https://trusted-site.com/redirect?url=https://evil-site.com", if trusted-site.com redirects to the url parameter value without validation, the user clicks what appears to be a link on a trusted domain but ends up on a malicious site.
Open redirects are exploited in phishing attacks because a trusted domain's URL serves as the entry point. Email security filters and users performing visual checks tend to judge a link as safe if it starts with a legitimate domain.
URL shortening services are inherently redirect services, making them closely related to the open redirect problem. Malicious actors using shortening services to create links to phishing sites is a real-world occurrence. Shortening services do take countermeasures, but which methods they use and how much they catch is generally not disclosed. The measures visible to users include warning screens that show the destination before redirecting (splash pages) and a channel for reporting abuse. The presence of those features does not mean that links issued through the service are safe. Rather than judging safety from assumptions about detection, it is more reliable to go by what can be checked from the outside.
To prevent open redirects in your own applications, effective measures include restricting redirect destinations to a whitelist, allowing only relative URLs, and validating the redirect target's domain. Implementations that pass URL parameters directly as redirect destinations should be avoided in all cases.
Two loopholes commonly survive validation that looks correct. The first is matching the domain by prefix: a URL such as "https://trusted-site.com.attacker-domain.example/" extends the hostname to the right and slips through a prefix check, so parse the URL, extract the hostname, and require an exact match against the allowlist. The second is treating every value that begins with a slash as a relative URL: "//attacker-domain.example/" is interpreted as a scheme-relative URL and sends the browser to another domain, so values starting with two slashes must be handled as external URLs.