Repeated calls to headers.contentSecurityPolicy(...) should not clobber previous ones #19842

Activity

1. jzheaux

   added

   in: configAn issue in spring-security-configAn issue in spring-security-config

   type: enhancementA general enhancementA general enhancement

   on Oct 7, 2026
2. jzheaux

   changed the title [-]Allow repeated headers.contentSecurityPolicy(...) calls to compose instead of replace[/-] [+]Repeated calls to headers.contentSecurityPolicy(...) should not clobber previous ones[/+] on Oct 7, 2026
3. ziqin

   added a commit that references this issue on Oct 9, 2026

   Allow repeated headers.contentSecurityPolicy(...) calls to compose

   ...

   This issue will close once commit b9c14ec is merged into the 'main' branch.

   b9c14ec
4. ziqin commented on Oct 9, 2026

   

   ziqin

   on Oct 9, 2026

   Last edited by ziqin

   Contributor

   More actions

   I tend to regard this inconsistency as a bug, especially the chaotic situation in the reactive HeaderSpec.

   Usually, people won’t call headers.contentSecurityPolicy(...) multiple times within one SecurityFilterChain bean definition. It might be repeatedly called by accident, however, when multiple modular configuration Customizer beans are defined in different locations.

   By retaining all customizations instead of resetting, unintended repeated calls of headers.contentSecurityPolicy(...) are more likely to be discovered.
5. ziqin

   added a commit that references this issue on Oct 14, 2026

   Allow repeated headers.contentSecurityPolicy(...) calls to compose

   ...

   This issue will close once commit ac0d1b3 is merged into the 'main' branch.

   ac0d1b3
6. ziqin commented on Oct 15, 2026

   

   ziqin

   on Oct 15, 2026

   Last edited by ziqin

   Contributor

   More actions

   The test headersWhenContentSecurityPolicyConfiguredTwiceThenSecondCallReplacesFirst in reactive stack still conflicts with composable headers.contentSecurityPolicy(...).
   

   spring-security/config/src/test/java/org/springframework/security/config/web/server/HeaderSpecTests.java

   Lines 529 to 548 in 78c30b7

   	@Test
   	public void headersWhenContentSecurityPolicyConfiguredTwiceThenSecondCallReplacesFirst() {
   	String headerName = ContentSecurityPolicyServerHttpHeadersWriter.CONTENT_SECURITY_POLICY;
   	String policyDirectives = "default-src 'self'";
   	// @formatter:off
   	this.http.headers((headers) -> headers
   	.contentSecurityPolicy((csp) -> csp
   	.exchangeMatchers("/foo/**")
   	.policyDirectives("script-src 'self'"))
   	.contentSecurityPolicy((csp) -> csp
   	.policyDirectives(policyDirectives)));
   	// @formatter:on
   	WebTestClient client = WebTestClientBuilder.bindToWebFilters(this.http.build()).build();
   	// @formatter:off
   	client.get()
   	.uri("https://example.com/bar")
   	.exchange()
   	.expectHeader().valueEquals(headerName, policyDirectives);
   	// @formatter:on
   	}

   It is assuming that the second HeaderSpec#contentSecurityPolicy(Customizer) call resets the exchangeMatcher to ServerWebExchangeMatchers.anyExchange(), so that the response to /bar contains CSP default-src 'self' instead of empty CSP.

   This is also why #19864 doesn't pass the CI pipeline.

   ---

   Related context: #18499 (comment)
7. ziqin commented on Oct 17, 2026

   

   ziqin

   on Oct 17, 2026

   Last edited by ziqin

   Contributor

   More actions

   I've opened #19924 to update headersWhenContentSecurityPolicyConfiguredTwiceThenSecondCallReplacesFirst so that it could test CSP replacement without conflicting with the composition feature.
8. ziqin

   added a commit that references this issue on Oct 17, 2026

   Allow repeated headers.contentSecurityPolicy(...) calls to compose

   ...

   This issue will close once commit 7723678 is merged into the 'main' branch.

   7723678