Repository navigation
[Enhancement] Add safe redirect utilities with domain whitelisting to WebUtils / RedirectView #2757
Description
Search before asking
- I had searched in the issues and found no similar issues.
Enhancement Request
Currently, WebUtils.issueRedirect() and RedirectView perform HTTP 302 redirects without validating the target URL against a whitelist or checking for protocol-relative URLs (e.g., //evil.com).
While I understand from the Shiro Security Model that input validation is primarily the responsibility of the application developer, providing inherently unsafe redirect utilities often leads to Open Redirect vulnerabilities in downstream applications that rely on Shiro for post-login/post-logout flows.
Describe the solution you'd like
I suggest introducing a "safe redirect" mechanism as a defense-in-depth measure. For example:
Add a WebUtils.issueSafeRedirect(request, response, targetUrl, allowedDomains) method.
Or introduce a SafeRedirectView that rejects absolute URLs not matching the current host or a configured whitelist, and blocks protocol-relative URLs (//).
If the URL fails validation, fallback to a default safe landing page (e.g., / or a configured default success URL).
I previously reported this via the security channel, and the security team advised opening a public issue for this hardening enhancement. I am happy to submit a Pull Request implementing this if the PMC agrees with the approach.
Are you willing to submit PR?
- Yes I am willing to submit a PR!
Activity
lprimak commentedon Jun 5, 2026
Keep in mind that a lot of times, the request URI is not the same as the URI the backend sees.
This is because many times, backends run behind proxies on private networks.
This makes it particularly difficult to make whitelisting work in all cases, and keep them in sync with the proxy configuration
Allen-wick commentedon Jun 7, 2026
You are absolutely right — relying on
request.getServerName()or attempting to parseX-Forwarded-*headers to build an "automatic" domain whitelist is extremely fragile in reverse-proxy environments and introduces its own trust boundary issues.Given this architectural constraint, I would like to pivot the proposal to a narrower, syntax-based defense-in-depth approach that does not rely on inferring the current host.
Instead of automatic domain whitelisting, I propose enhancing
RedirectViewandWebUtilsto block inherently dangerous redirect patterns at the syntax level:javascript:,data:,vbscript:, orfile:schemes to prevent XSS via open redirect.//(e.g.,//evil.com/phishing), which are a common vector for Open Redirects and bypass naive string-matching filters.lprimak commentedon Jun 11, 2026
I am not so sure the above is the right approach either.
I can see legitimate redirects to different schemas, I can also see legitimate redirects to different domains, and protocol-relative URLs.
Not sure what can safely be done here without requiring complex configuration upfront or breaking compatibility...
lprimak commentedon Jun 11, 2026
I am going to go ahead and move this to a discussion since I don't think this is straight-forward.