-
Notifications
You must be signed in to change notification settings - Fork 38.9k
Description
Overview
Applications migrating from Spring MVC to WebFlux lose the ability to configure HTML escaping globally, creating a consistency and potential security gap.
In the servlet stack, RequestContext reads this setting cleanly from web.xml:
Lines 224 to 226 in 0676c95
| // Determine default HTML escape setting from the "defaultHtmlEscape" | |
| // context-param in web.xml, if any. | |
| this.defaultHtmlEscape = WebUtils.getDefaultHtmlEscape(this.webApplicationContext.getServletContext()); |
In the reactive stack, the equivalent is simply never implemented:
Line 97 in 0676c95
| this.defaultHtmlEscape = null; // TODO |
Lines 150 to 157 in 0676c95
| /** | |
| * (De)activate default HTML escaping for messages and errors, for the scope | |
| * of this RequestContext. | |
| * <p>TODO: currently no application-wide setting ... | |
| */ | |
| public void setDefaultHtmlEscape(boolean defaultHtmlEscape) { | |
| this.defaultHtmlEscape = defaultHtmlEscape; | |
| } |
Those TODOs have existed since the reactive RequestContext was introduced in 5.0 M4 (2016).
Why this matters
- Migration consistency: MVC apps migrating to WebFlux expect feature parity on this setting
- Security: Global HTML escaping enforcement prevents accidental XSS exposure
Proposed solution
Add property-driven configuration for reactive applications:
propertiesspring.web.defaultHtmlEscape=true
this.defaultHtmlEscape = environment.getProperty( "spring.web.defaultHtmlEscape", Boolean.class );
Note: The MessageSource parameter already passed to the RequestContext constructor is in practice an ApplicationContext instance, which provides direct access to Environment. This means the fix requires no public API changes — just reading the property at initialization time from the already-available context, falling back to null to preserve current behavior.
I will be happy to submit a PR if this direction makes sense.