Repository navigation
Repeated calls to headers.contentSecurityPolicy(...) should not clobber previous ones #19842
Description
Activity
- 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 - added a commit that references this issue
on Oct 9, 2026 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 oneSecurityFilterChainbean definition. It might be repeatedly called by accident, however, when multiple modular configurationCustomizerbeans are defined in different locations.By retaining all customizations instead of resetting, unintended repeated calls of
headers.contentSecurityPolicy(...)are more likely to be discovered.
Today, invoking
headers.contentSecurityPolicy(...)more than once replaces everything the previous call configured, in both stacks:HeadersConfigurer#contentSecurityPolicy(Customizer)constructs a newContentSecurityPolicyConfig(and with it a newContentSecurityPolicyHeaderWriter) on every call.HeaderSpec#contentSecurityPolicy(Customizer)creates a newContentSecurityPolicySpec, which resets the policy directives (and, with Support nonce-based Content Security Policy #18499, the exchange matcher and nonce filter), whilereportOnlyis retained.Other
HeadersConfigurerconfigs let repeated calls compose so this is inconsistent and surprising. This ticket is to look at addressing this inconsistency.@ziqin has a branch worth considering at https://github.com/ziqin/spring-security/tree/multi-csp-config-call
Since this changes behavior for applications that call the method more than once, we may need to wait until the next major unless this can be conceived as a bug.