Support nonce-based Content Security Policy

[ziqin]

This PR implements gh-10826.

Introduction

When strict Content Security Policy is used, web browsers block inline <script> or <style> blocks in HTML to mitigate XSS attacks injecting malicious inline blocks. To allow intended inline blocks, web developers can generate a hard-to-guess nonce and specify it in both the CSP and allowed inline blocks.

Currently, Spring Security only supports specifying static content security policy directives. This PR introduces support for dynamically generating a secure random nonce for CSP.

Implementation

A nonce is written to the CSP header in 2 steps:

1. NonceGeneratingFilter / NonceGeneratingWebFilter generates a nonce and set it as a request attribute named _csp_nonce;
2. ContentSecurityPolicyHeaderWriter / ContentSecurityPolicyServerHttpHeadersWriter reads the _csp_nonce attribute and write it to the CSP header, replacing the {nonce} placeholder in the configured policyDirectives.

Note:

• The whole process is separated in 2 steps because by default a header writer cannot set a request attribute visible to views rendering the nonce in HTML.
• _csp_nonce is chosen as the default attribute name because it has a similar format with the existing _csrf attribute. The attribute name is configurable.

Configuration

This PR also adds configurers for setting up nonce-based CSP with Java/Kotlin lambda DSL, including the ability to specify a request matcher to determine whether a request requires CSP protection.

@Bean
SecurityFilterChain filterChain(HttpSecurity http) {
    http
        .headers((headers) -> headers
            .contentSecurityPolicy((csp) -> csp
                .policyDirectives("default-src 'self'; script-src 'self' 'nonce-{nonce}'; style-src 'self' 'nonce-{nonce}'")
                .nonceAttributeName("_csp_nonce")
                .requireCspMatchers("/admin/**", "/user/**")
            )
        );
    return http.build();
}

The ability to enable CSP conditionally is useful especially when the CSP directives contain a nonce, because the HTTP header value becomes dynamic and may change the cacheability of static asserts protected by Spring Security.

The conditional enabling of CSP protection is implemented in spring-security-config by wrapping the ContentSecurityPolicyHeaderWriter / ContentSecurityPolicyServerHttpHeadersWriter with the existing DelegatingRequestMatcherHeaderWriter / ServerWebExchangeDelegatingServerHttpHeadersWriter. The _csp_nonce attribute is generated unconditionally if nonce-based CSP is configured.

Breaking changes in corner case

In commit 381dc38 I changed the return type of 2 public configuration APIs:

• ContentSecurityPolicySpec#reportOnly(boolean)
• ContentSecurityPolicySpec#policyDirectives(String)

The return type is changed from HeaderSpec to ContentSecurityPolicySpec to allow method chaining.

I believe this API change was missed during the migration to lambda DSL and think it's small enough to be updated when releasing v7.1, but if 100% API stability is required, we could simply revert that commit, or introduce new APIs and deprecate the old ones.

[ziqin]

It seems that #18840 may affect the two-step assumption made here.

If HTTP headers are written eagerly, HeaderWriter#writeHeaders(HttpServletRequest, HttpServletResponse) may be changed to run earlier, which means it may be possible to set a nonce attribute directly in ContentSecurityPolicyHeaderWriter without requiring an extra NonceGeneratingFilter.

[jzheaux]

Thanks for contributing this feature, @ziqin! I've left some feedback inline. Mostly, I focused on the reactive stack; please consider applying my observations to both stacks.

[jzheaux]

Let's please place the Mono directly into the exchange as an attribute. This will allow so that only when the attribute is read that we have the expense of generating a nonce. You can see ServerCsrfTokenRequestAttributeHandler for an example.

[ziqin]

Lazy generation of nonce is beneficial for performance. Thank you for pointing out this aspect which I didn't take into account. I have updated the code accordingly in 56e3884 with SingletonSupplier and Mono#cache() so that the nonce used by views is the same as the one appearing in the CSP header.

Nevertheless, I still have a concern on how to access the nonce in a template. If I remember correctly, in WebFlux applications a Mono<String> can be directly accessed in a Thymeleaf template like <style th:nonce="${_csp_nonce}">, but I doubt whether there is similar support for Supplier<String> in servlet applications.

Is there anything we can do to avoid having users to write different templates for different stacks?

[ziqin]

A possible solution could be ${_csp.nonce}, where the request attribute named _csp is an object with a getNonce() method performing the lazy evaluation, just like SupplierCsrfToken#getToken().

[ziqin]

Another possible approach is to hack the toString() method of the Supplier<String> instance to perform the deferred generation.

[jzheaux]

Let's instead keep track of the request matcher(s) inside of ContentSecurityPolicySpec and apply them when the filter chain is being built.

[ziqin]

To avoid the hack here, the initialization of this.writers in HeaderSpec constructor is moved to HeaderSpec#configure, which requires me to change the disable() method implementations of other XxxSpecs. See my comment for how theses changes may affect some weird applications.

This is updated in acf956a. Could you please check whether these changes are appropriate?

[ziqin]

If someone has written some weird code like below, the changes here could cause NullPointerException which the old code won't throw.

@Bean
SecurityWebFilterChain springSecurity(ServerHttpSecurity http) {
	http
		.headers((headers) -> headers
			.frameOptions((frame) -> {
				frame.disable();
				frame.mode(XFrameOptionsServerHttpHeadersWriter.Mode.DENY);
			})
		);
	return http.build();
}

[ziqin]

@jzheaux Thank you for your detailed and insightful review feedback!

I have resolved most problems you pointed out, but there are still some points that I am uncertain about (see my comments for details). Would you like to help me about these?

[ziqin]

Should we define a new SecurityWebFiltersOrder enum for ContentSecurityPolicyNonceGeneratingWebFilter? In SecurityWebFiltersOrder, is it a good idea to expose the presence of ContentSecurityPolicyNonceGeneratingWebFilter to users considering that it may not be necessary in the future if headers are written eagerly?