> ## Content Index > Fetch the complete content index at: https://securinglaravel.com/llms.txt > Use this file to discover other available public pages before exploring further. # Security Tip: Avoid Open Redirects! - URL: https://securinglaravel.com/security-tip-open-redirects/ - Published: 2022-03-01T12:00:38.000Z - Updated: 2024-11-05T23:21:50.000Z - Description: [Tip#16] Ever clicked a link that looked legitimate, but took you somewhere unexpected? - Author: Stephen Rees-Carter - Tags: Security Tips, Open Redirects, Vulnerabilities An **Open Redirect vulnerability** is where an attacker can trick the server into redirecting the victim somewhere specific, usually somewhere completely unrelated to the site the vulnerability is on. They are used to mask the final destination of a URL, so if the victim looks at the malicious open redirect link, all they see is a safe domain name at the beginning, not the real domain hiding at the end. *For example*, consider an app that redirects a user to a login form with the intended authenticated URL in as a query string parameter. A legitimate redirect could look like this: ``` https://example.com/login?redirect=/project/1 ``` The user is shown the login form, and upon successful authentication, they are redirected to the “`/project/1`” route. But, if the redirect is “open”, an attacker could send a victim to this URL: ``` https://example.com/login?redirect=https://evilsite.com ``` The user would see the valid login form, but then be redirected to a malicious page that could be **absolutely anything.** Yes, it wouldn’t have cookies, session, or login details, but you can get quite creative with it. 🤔 Maybe the page shown after the login form could ask the user to reset their password, asking for email and password again to confirm as part of the flow. Would a normal user really go check the URL at that point, or would the blindly enter their password? It’s a common pattern that gets used in apps! What if the redirect existed on a URL that wasn’t a form endpoint, but rather responded to `GET` requests to trigger the redirect? Something like this: ``` GET https://example.com/redirect?url=https://evilsite.com ``` If you throw that in an email or on a website, and pad it out a bit, it’s easy for an attacker to show the victim only this bit before they click on it: ``` https://example.com/redirect?url=... ``` As far as the victim is concerned, they are going to your **safe** website at `example.com`. But it will immediately redirect to the attacker’s `evilsite.com`. That’s your site reputation they are using to trick their victims, and the victim may not trust your site again. ## How do we mitigate this? 1. **Inject the redirect URL into the session**. This only works in some instances (like auth redirects), but when it’s possible, it is definitely the best solution as the attacker cannot modify the redirect destination. *This is how Laravel does it by default with it’s authentication redirects*. 2. **Use an allow-list of domains and/or URLs.** Only complete the redirect request if the domain and/or URL being redirected to is on the allow-list. This gives you the freedom to redirect to multiple locations in different scenarios, without opening the gates to redirect anywhere. 3. **Hard-code the list of redirections in code/configuration.** Very similar to #2, but rather than allow a dynamic redirection through an allow-list of domains/URLs, have all redirections listed and reference them by an identifier. ## redirect()->back() While we’re talking about this subject, I want to very briefly mention `redirect()->back()`, around which there is [some discussion](https://github.com/laravel/framework/issues/14642?ref=securinglaravel.com) about open redirect vulnerabilities. `redirect()->back()` uses the `Referer` header to know where to redirect the user back to, which means it’s technically an Open Redirect vulnerability (as the referrer header could be anything). It is important to note however that in order to abuse this vulnerability, you need to control the `Referer` headers in the browser. This cannot be done without having a level of control in the browser or over the request that makes an open redirect vulnerability meaningless. If you can modify the request to change headers, you can modify it to do anything else you like too. So in my opinion, `redirect()->back()` is safe to use. --- **Found this security tip helpful?* Don't forget to* [*subscribe*](https://securinglaravel.com/#/portal/signup) *to receive new* [*Security Tips*](https://securinglaravel.com/tag/tips/) *each week, and upgrade to a* [*premium subscription*](https://securinglaravel.com/#/portal/signup) *to receive monthly* [*In Depth articles*](https://securinglaravel.com/tag/in-depth/)*, or toss a coin in the* [*tip jar*](https://securinglaravel.com/#/portal/support)*.* *Reach out if you're looking for a* [*Laravel Security Audit and Penetration Test*](https://stephenreescarter.net/laravel-security-audits-and-pentesting/?utm%5Fsource=securinglaravel.com) *or a budget-friendly* [*Security Review*](https://stephenreescarter.net/laravel-security-reviews/?utm%5Fsource=securinglaravel.com)*, and find me on the various socials through* [*Pinkary*](https://pinkary.com/@valorin?ref=securinglaravel.com)*. Finally, don't forget to check out* [*Practical Laravel Security*](https://practicallaravelsecurity.com/?utm%5Fsource=securinglaravel.com)*, my interactive security course.*