A redirect is a small instruction — "go here next" — but it carries the trust of the site that issues it. When an application builds that destination from untrusted input and follows it without checking, the result is an unvalidated redirect (often called an open redirect).
This subject was once its own OWASP Top 10 entry, A10:2013 - Unvalidated Redirects and Forwards. It now lives under A01:2021 - Broken Access Control, because at heart it is a failure to control where the application's authority may be pointed.
In this lesson you will:
- Find a redirect link in the Nebula and inspect its
to=parameter. - Defeat a redirect endpoint that validates its destination by substring match — the OWASP Nebula Allowlist Bypass challenge.
- Learn why blocklists and substring checks both fail, and why only an exact allowlist of origins, validated on the server, is a durable control.
- Understand the difference between a redirect (the browser is told to go elsewhere — the address bar changes) and a forward (the server routes the request internally to a different handler — the browser never sees it), and why both require the same allowlist validation rule.
Estimated time: 10 to 15 minutes.
Prerequisites: http-fundamentals for URL structure, query parameters, and HTTP status codes. No additional tooling beyond a running Nebula instance is needed; you will work with the /redirect?to= endpoint directly from the browser.
When you are ready, send the Continue signal.