Open redirect
An open redirect is a flaw where an application sends the visitor to a URL taken from a parameter without checking it against a list of permitted destinations. On its own it leaks nothing, which is why it is often dismissed; its value to an attacker comes from what it is chained to.
The parameter is usually there for a good reason: return the user to the page they were on after login, after a language change, or after an interstitial. The flaw is accepting an absolute URL, or a relative one that a browser resolves as absolute, and following it without validation. Filters that check whether the value starts with the site’s own domain are routinely defeated by a value that merely contains it.
Two chains raise the severity. The first is OAuth 2.0: if the redirect lives on a host registered as a valid callback, an authorisation code can be routed through it and out to the attacker, which turns a cosmetic issue into account takeover. The second is phishing, where the link a target receives genuinely begins with their employer’s domain and their own mail gateway rates it accordingly.
In a report we write it against the chain, not the parameter, and where no chain exists we say so rather than inflating it. The evidence is the request and the resulting Location header, plus the specific callback or filter it defeats. The fix is an allow list of permitted destinations, or an opaque token that maps to a stored URL, and this is covered in the web application testing where redirect parameters are traced end to end.