Spring Security supports URI placeholders such as {baseUrl}, {baseScheme}, {baseHost}, {basePort}, and {basePath} in OAuth 2.0 / OIDC client configuration, SAML 2.0 RelyingPartyRegistration, OIDC logout URLs, and related areas. These placeholders are resolved from the current HTTP request (via mechanisms such as UrlUtils.buildFullRequestUrl on Servlet), which makes configuration portable but introduces security considerations when the apparent request origin is not trustworthy (for example, spoofed Host or untrusted Forwarded / X-Forwarded-* headers).
It would be helpful to include in the documentation the security considerations around using URI placeholders so applications can make an informed decision about when to use them.
Some things that would be helpful:
- Add documentation that explains how
{baseUrl}, etc. are derived, including that they are built using the Host header. This documentation would outline the security tradeoffs of using {baseUrl} vs hardcoding a URI in situations where the Host header is not trusted. This might go in the Exploits section of the documentation.
- Update the
HttpFirewall documentation to demonstrate configuring an expected set of host headers
- Update the Proxy configuration documentation to be in line with modern Boot configurations
- Update both
HttpFirewall and Proxy configuration documentation to refer back to the new documentation about URI placeholders.
- Update RelyingPartyRegistration documentation to outline which properties support placeholders and what each property is used for during login.
- Update the OAuth 2.0, OIDC, and SAML documentation to point to this new documentation wherever URI placeholders are a relevant topic of conversation.
Spring Security supports URI placeholders such as
{baseUrl},{baseScheme},{baseHost},{basePort}, and{basePath}in OAuth 2.0 / OIDC client configuration, SAML 2.0RelyingPartyRegistration, OIDC logout URLs, and related areas. These placeholders are resolved from the current HTTP request (via mechanisms such asUrlUtils.buildFullRequestUrlon Servlet), which makes configuration portable but introduces security considerations when the apparent request origin is not trustworthy (for example, spoofedHostor untrustedForwarded/X-Forwarded-*headers).It would be helpful to include in the documentation the security considerations around using URI placeholders so applications can make an informed decision about when to use them.
Some things that would be helpful:
{baseUrl}, etc. are derived, including that they are built using theHostheader. This documentation would outline the security tradeoffs of using{baseUrl}vs hardcoding a URI in situations where theHostheader is not trusted. This might go in the Exploits section of the documentation.HttpFirewalldocumentation to demonstrate configuring an expected set of host headersHttpFirewalland Proxy configuration documentation to refer back to the new documentation about URI placeholders.