Regarding the dangers of redirects, I think Ben is talking about open redirects, where your taking the URL or part of it from user input. If you don't validate this, an attacker can create a link that looks like a link to your site, but that actually takes the user to another site.
For example, it's very common to redirect users back to the page they were viewing when they logged in.
Let's say a user visits
which requires login, so you redirect them to
After logging in, you take that next parameter from the URL and redirect them there.
If you're not careful to validate that that parameter starts with a single slash (which indicates that it is a path within your site), an attacker could give someone a link to
which causes your server to redirect the user to http://evil.com
Thanks for the description of this, Frederik! That is good to protect against. I think I've covered this risk, but I should verify.
How I handle that next url: in the auth middleware, if the check fails, I store the path of the request in the session before redirecting to login. Then, in the login handler, retrieve the path from the session and redirect. That way, we're guaranteed that the path is on our site AND it can't be modified.
Nice. Thanks for sharing your approach. I have seen devs (in videos) have a catchall route for any route that doesn't match something on the server or client -> if any route is passed to domain.com/someroute that doesn't match an explicit route just goes to domain.com/ - but catching it in the next would ensure that they go to the right place and not just back to the homepage.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.