No. Spring Security provides a default set of security response headers, including HSTS, but it does not add Content-Security-Policy. Its reference says a reasonable default is impossible to know without knowing the application, so the author must declare the policy. You add and tune it yourself.
Why there is no default
A Content-Security-Policy (CSP) tells the browser which sources of scripts, styles, images and other content are allowed. A policy that fits a simple server rendered site would break an app that loads scripts from a CDN, uses inline handlers, or embeds third party widgets. A framework default would either be too weak to matter or break things.
The Spring Security reference explains this and shows an example policy, along with how to enable it through the headers configuration. It also says that not all clients use every header, so you should test.
What you do get
The reference says Spring Security gives a default set of headers, and that you can customise individual ones. It confirms that HSTS is provided by default and that you can adjust it, and that you can switch defaults off with defaultsDisabled() and add back only the ones you want. CSP is not in the default set.
| Header | Default in Spring Security | Your job |
|---|---|---|
| Strict-Transport-Security | Provided | Review max age and subdomain settings |
| X-Frame-Options | Customisable, for example SAMEORIGIN | Match your embedding needs |
| Content-Security-Policy | Not added | Write and test a policy |
A safe rollout
- List where your pages load scripts, styles, images and frames from.
- Start with a report only policy so the browser reports violations without blocking.
- Collect reports for a while and adjust the policy.
- Move to an enforcing policy, starting with script sources.
- Avoid broad allowances such as wildcard sources, which weaken the policy.
- Re-test after front end changes, especially new third party scripts.
CSP complements output encoding and input validation. It limits damage if something slips through. See our security headers guide and implementation checklist.
A worked example
A team adds a policy that allows scripts only from their own origin. The site breaks because an analytics snippet and a chat widget load from other hosts. Rather than allowing everything, they run in report only mode, read which hosts appear in reports, decide which are justified, and list those few explicitly. The policy ends up strict enough to block an injected script from an unknown host, which is the point of having one.
The work is in the inventory of what the page loads, and no framework could do that for you.
Safeguard scans dependencies, produces SBOMs and uses reachability analysis to show which findings your code can actually reach. You can run a free scan at gold.safeguard.sh/scan.
Quick check
Can I turn off all default headers?
Yes, the reference shows defaultsDisabled and then adding back specific headers. Do it only if you set an equal or better set yourself.
Is a report only policy safe to deploy first?
It does not block content, so it is a common first step. Review the reports before enforcing.
Sources
Last reviewed: 19 October 2026.
