They don't seem to consider open redirects an issue worth mitigating (see https://sites.google.com/site/bughunteruniversity/nonvuln/open-redirect https://sites.

They don't seem to consider open redirects an issue worth mitigating (see https://sites.google.com/site/bughunteruniversity/nonvuln/open-redirect https://sites.google.com/site/bughunteruniversity/nonvuln/op...). Though in the example given, they have taken the sensible step of inserting an interstitial warning page, there are known URLs (e.g. https://vagmour.eu/google-open-url-redirection/ https://vagmour.eu/google-open-url-redirection/) that don't use such a page. Personally, I don't think it's particularly realistic to expect users to be able to work out when an open redirect is being abused in a phishing attack - particularly if e.g. other junk query string parameters are used to obfuscate the destination, or a domain is chosen that looks like it could legitimately be part of a site's URL structure. Checking the domain gets you some peace of mind (assuming it's not abusing lookalike Unicode characters!) but if there are "reflected" or even "stored" open redirects [1] on the domain then all bets are off. I don't think I could confidently make a decision regarding the safety of such a link except by following it (with e.g. curl -L) and seeing what happened. [1] I'm abusing XSS terminology here by applying it to redirects, but hopefully the meaning is clear. I consider a "stored open redirect" a page under a user-known-safe domain where an attacker can persist the final destination s.t. it's not visible in the original URL.