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.

[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?

[jzheaux]

Thanks, @ziqin, for this thorough PR!

In addition to my inline notes, will you please take a look at XML support? We can either:

• Add the nonce-generating filter there too so that the XML support continues to work, or
• It will need an error message stating that nonces aren't supported in XML config

Either way, no need to add nonce-attribute-name, etc. This is to make sure that this change doesn't inadvertently break XML config.

Additionally, for brevity, I made some comments in servlet that naturally also apply to reactive. If you are unsure, please feel free to ask!

[jzheaux]

I lean towards giving this a default value as having a nonce is the stronger security position. It also prevents folks from having to specify an attribute name that Spring Security already has defined.

[ziqin]

Having a null nonceAttributeName here in ContentSecurityPolicySpec means using the default attribute name _csp_nonce. (Now the default name is _csp.) When it's not null, it would be passed to ContentSecurityPolicyNonceGeneratingWebFilter#setAttributeName(String), otherwise the filter will use the default attribute name.

In 6c1fbf3, this nonceAttributeName field is removed from ContentSecurityPolicySpec together with the removal of ContentSecurityPolicySpec#getNonceGeneratingFilter(). Now ContentSecurityPolicySpec#nonceAttributeName(String) directly configures the pre-constructed HeaderSpec#nonceGeneratingFilter. I believe such changes simplify the code and reduce changes in this PR.

[jzheaux]

Because ContentSecurityPolicyHeaderWriter is reconstructed each time headers.contentSecurityPolicy is invoked, there is a lifecycle mismatch between nonceAttributeName/requestMatcher and reportOnly/policyDirectives.

Let's please see if we can set these values eagerly as well. We can use another ticket to see change the fact that a second call to contentSecurityPolicy clobbers the first.

[ziqin]

In 6c1fbf3, ContentSecurityPolicyConfig#requestMatcher(RequestMatcher) now directly configures on ContentSecurityPolicyConfig.this.writer, just like reportOnly and policyDirectives.

Similarly, ContentSecurityPolicyConfig#nonceAttributeName(String) now directly configures on ContentSecurityPolicyConfig.this.nonceGeneratingFilter.

Thus, I believe the lifecycle of these properties should be the same now.

The problem that a second call to contentSecurityPolicy clobbers the first could be addressed with the following solution, which is applied by many other inner config classes in HeadersConfigurer:

// 1. Add an enable() method to class ContentSecurityPolicyConfig
private ContentSecurityPolicyConfig enable() {
	if (this.writer == null) {
		this.writer = new ContentSecurityPolicyHeaderWriter();
	}
	if (this.nonceGeneratingFilter == null) {
		this.nonceGeneratingFilter = new ContentSecurityPolicyNonceGeneratingFilter();
	}
	return this;
}

// 2. Call contentSecurityPolicy.enable() in HeadersConfigurer#contentSecurityPolicy(Customizer)
// to preserve already constructed writer and nonceGeneratingFilter
public HeadersConfigurer<H> contentSecurityPolicy(
		Customizer<ContentSecurityPolicyConfig> contentSecurityCustomizer) {
	contentSecurityCustomizer.customize(this.contentSecurityPolicy.enable());
	return HeadersConfigurer.this;
}

I've added the above changes to a new branch.

[jzheaux]

I think it would be okay to default to having this be a pre-constructed field in the config. If they set nonceAttributeName to null, then that filter can be set to null.

[ziqin]

In 6c1fbf3, ContentSecurityPolicyNonceGeneratingFilter becomes a field in ContentSecurityPolicyConfig. Currently it is pre-constructed by HeadersConfigurer#contentSecurityPolicy(Customizer), but is expected to be constructed by a separate enable() method. See the discussion in #18499 (comment).

I don't understand neither why a user might want to set nonceAttributeName to null, nor the semantic of a null nonceAttributeName. From my point of view, if a nonce is generated and written to the Content-Security-Policy header but cannot be referenced by any inline blocks in server-rendered HTML, the nonce is useless and the user had better remove that {nonce} placeholder from the policy directives. The current implementation of ContentSecurityPolicyConfig#nonceAttributeName(String) rejects null argument.

[jzheaux]

I believe this is correct. Also, this means that CompositeServerHttpHeadersWriter will fail fast, and the ensuing headers will not be written.

If you are able, can you please add a separate commit for updating CompositeServerHttpHeadersWriter to not fail fast? I believe it would mean changing the concatMap call to concatMapDelayError.

[ziqin]

CompositeServerHttpHeadersWriter is updated to not fail fast in 2be35ce.

I also updated CompositeHeaderWriter analogously for the servlet stack in cba8dd8, but I’m not very confident about the type of exception thrown there (I used RuntimeException).

[ziqin]

@jzheaux

Thanks again for your patient review.

Following your guidance, I have resolved most problems. Please see my replies to inline comments for details and my remaining questions.

• By introducing a request matcher to ContentSecurityPolicyHeaderWriter instead of using DelegatingRequestMatcherHeaderWriter, I managed to change several places in HeadersConfigurer and ServerHttpSecurity back to their original state before this PR.

• The request/exchange attribute for the nonce object is renamed to _csp so that the nonce value could be referenced in a template as ${_csp.nonce}.

• XML namespace configuration support is added in 55d55a9 to allow {nonce} placeholders in CSP directives. I used CompositeFilter there for ease of implementation, and consequently there will be structural differences between the XML-built filter chain and that built with Java lambda DSL. I hope they provide the same functionalities.