[Enhancement] Add safe redirect utilities with domain whitelisting to WebUtils / RedirectView

[Allen-wick]

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!

[lprimak]

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]

You are absolutely right — relying on request.getServerName() or attempting to parse X-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 RedirectView and WebUtils to block inherently dangerous redirect patterns at the syntax level:

1. Block Dangerous Schemes: Reject redirects targeting javascript:, data:, vbscript:, or file: schemes to prevent XSS via open redirect.
2. Block Protocol-Relative URLs: Reject URLs starting with // (e.g., //evil.com/phishing), which are a common vector for Open Redirects and bypass naive string-matching filters.

[lprimak]

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]

I am going to go ahead and move this to a discussion since I don't think this is straight-forward.

[lprimak]

Making as abandoned...