How to set a Content Security Policy header in Spring Boot, Tomcat and Angular

What a Content-Security-Policy header does in a Java or Angular app

A Content Security Policy is an HTTP response header that tells the browser which sources it may load scripts, styles, images, fonts, frames and connections from. If an attacker manages to inject a script tag into one of your pages, a good policy stops the browser from running it. That makes CSP one of the most useful defences against cross-site scripting, and it is one of the headers every security scanner checks for.

The header itself is the same whatever framework you use. A sensible starting policy looks like this:

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'self'

What changes between Spring Boot, Tomcat 9 and Angular is where the header is added. In a Spring Boot application the code that builds the response can add it. In a plain Tomcat 9 deployment you add it with a servlet filter. An Angular app is different again: Angular runs in the browser, so it cannot send HTTP headers at all. The server that delivers the built files, whether that is nginx, Apache, a Node server or Spring Boot itself, has to send the header for it.

If you are not sure which headers your site sends today, the missing security headers guide explains what each one does and how scanners grade them.

How to check what your app sends now

Before changing code, see what actually reaches the browser. Headers can be added or removed by the application, the servlet container, a reverse proxy and a CDN, so test the public address rather than localhost:

curl -sI https://example.com/ | grep -i content-security
curl -sI https://example.com/app/dashboard | grep -i content-security

Check more than one URL. A policy set only on the home page, or only on HTML responses from one controller, leaves the rest of the site unprotected. Also check that the header appears once. Two Content-Security-Policy headers are not merged: the browser enforces both, so a resource has to pass every policy, and the stricter one effectively wins.

In Chrome DevTools, open the Network panel, reload, click the document request and look under Response Headers. Then open the Console. Every blocked resource produces a message that names the directive, for example:

Refused to load the script 'https://cdn.example.net/widget.js' because it violates
the following Content Security Policy directive: "script-src 'self'".

Those messages are your to-do list. Each one is either something you want to allow, by adding its source to the right directive, or something that should not be there at all.

How to set the Content Security Policy header in Spring Boot

If your application uses Spring Security, the headers configuration is the right place. Spring Security already sends several security headers by default, but it does not send a Content Security Policy until you supply one, because no single policy suits every application. In Spring Security 6 and Spring Boot 3, add it to your filter chain bean:

@Configuration
public class SecurityConfig {

  @Bean
  SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    http.headers(headers -> headers
        .contentSecurityPolicy(csp -> csp
            .policyDirectives("default-src 'self'; script-src 'self'; "
                + "style-src 'self'; img-src 'self' data:; object-src 'none'; "
                + "base-uri 'self'; frame-ancestors 'self'")
        )
    );
    return http.build();
  }
}

To trial the policy first, add .reportOnly() after policyDirectives(...). Spring then sends Content-Security-Policy-Report-Only instead, and you remove that one call when you are ready to enforce.

Spring Boot without Spring Security

If the app does not use Spring Security, register a small filter. Spring Boot picks up any Filter bean and applies it to every request:

@Component
public class CspHeaderFilter extends OncePerRequestFilter {

  private static final String POLICY =
      "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'";

  @Override
  protected void doFilterInternal(HttpServletRequest req, HttpServletResponse res,
                                  FilterChain chain) throws ServletException, IOException {
    res.setHeader("Content-Security-Policy", POLICY);
    chain.doFilter(req, res);
  }
}

Nonces in Thymeleaf templates

If your server-rendered pages need inline scripts, give each response a fresh random nonce instead of allowing 'unsafe-inline'. Generate at least 128 bits with SecureRandom, Base64-encode it, put it in the header as script-src 'self' 'nonce-VALUE', store it as a request attribute, and print it in the template:

<script th:attr="nonce=${cspNonce}">
  window.appConfig = { region: 'uk' };
</script>

The nonce must change on every response. A fixed value, or one cached in a full-page cache, gives an attacker the same key you use and defeats the point.

How to set the Content Security Policy header in Tomcat 9

Tomcat 9 ships with HttpHeaderSecurityFilter, which can add HSTS, X-Frame-Options and X-Content-Type-Options, but it has no Content Security Policy option. For a WAR running on Tomcat 9 you have three choices: a filter inside your application, a filter that applies to every application on the server, or the reverse proxy in front of Tomcat.

A filter class

Tomcat 9 implements Servlet 4.0, so use the javax.servlet package. Tomcat 10 and later moved to jakarta.servlet, and a class compiled against the wrong one will not load.

package com.example.security;

import java.io.IOException;
import javax.servlet.*;
import javax.servlet.http.HttpServletResponse;

public class CspFilter implements Filter {
  private String policy;

  @Override
  public void init(FilterConfig config) {
    policy = config.getInitParameter("policy");
  }

  @Override
  public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)
      throws IOException, ServletException {
    ((HttpServletResponse) res).setHeader("Content-Security-Policy", policy);
    chain.doFilter(req, res);
  }
}

Registering it in web.xml

Declare it in your application's WEB-INF/web.xml. Putting it in Tomcat's own conf/web.xml applies it to every application, but the class must then be in Tomcat's lib folder.

<filter>
  <filter-name>cspFilter</filter-name>
  <filter-class>com.example.security.CspFilter</filter-class>
  <init-param>
    <param-name>policy</param-name>
    <param-value>default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'</param-value>
  </init-param>
</filter>
<filter-mapping>
  <filter-name>cspFilter</filter-name>
  <url-pattern>/*</url-pattern>
  <dispatcher>REQUEST</dispatcher>
  <dispatcher>ERROR</dispatcher>
</filter-mapping>

The ERROR dispatcher means Tomcat's error pages carry the header too. Restart the application or Tomcat, then run the curl check again.

If Tomcat sits behind Apache or nginx, setting the header on the proxy is often simpler and covers static files that never reach Tomcat. The Apache and nginx security header guides show the syntax. Set it in one place only, or you will send two policies.

How to set the Content Security Policy header in Angular

An Angular build is a folder of static files: index.html, JavaScript bundles and CSS. The header has to be added by whatever serves that folder. Two Angular behaviours decide what the policy must allow.

• Component styles are injected as inline <style> elements. A style-src 'self' policy blocks them unless you add 'unsafe-inline' or give Angular a nonce.
• Bundles are normal script files. With the default ahead-of-time build, script-src 'self' works and you do not need 'unsafe-eval'.

Giving Angular a nonce

Since Angular 16 you can put an ngCspNonce attribute on the root element. Angular then adds that nonce to every style element it creates:

<app-root ngCspNonce="NGINX_CSP_NONCE"></app-root>

The server replaces the placeholder with a fresh random value on every response and sends the same value in the header. With nginx serving the build:

location / {
  root /var/www/example-app/browser;
  try_files $uri /index.html;
  sub_filter_once off;
  sub_filter 'NGINX_CSP_NONCE' $request_id;
  add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'nonce-$request_id'; style-src 'self' 'nonce-$request_id'; object-src 'none'; base-uri 'self'" always;
}

The $request_id variable is a random 32-character value generated for each request, which is enough for a nonce. Make sure nothing in front, such as a CDN, caches index.html, or every visitor receives the same nonce.

Hashes instead of nonces

If your hosting cannot rewrite index.html per request, use hashes. Recent Angular versions, from 19 onwards, offer an automatic option in angular.json that computes hashes for the inline scripts in index.html and writes a policy into a meta tag:

"build": {
  "options": {
    "security": { "autoCsp": true }
  }
}

A meta-tag policy cannot use frame-ancestors or reporting, so still send a header from the server for those. While you develop, ng serve accepts a headers object in its options, which lets you test the same policy locally.

A worked example: Example Bakery on Spring Boot and Angular

Example Bakery runs an Angular storefront at shop.example.com, served by nginx, and a Spring Boot API at api.example.com. A scan reports no Content Security Policy on either.

1. They add a report-only policy to the API's SecurityFilterChain with default-src 'none'; frame-ancestors 'none'. An API that returns only JSON loads nothing, so the strictest policy is safe.
2. For the storefront they add the nginx block above as Content-Security-Policy-Report-Only and the ngCspNonce placeholder in index.html.
3. The Console shows three kinds of message: the API calls are refused by connect-src, a payment script from the provider's domain is refused by script-src, and product photos from images.example.com are refused by img-src.
4. They add connect-src 'self' https://api.example.com, the payment domain to script-src and frame-src, and https://images.example.com to img-src.
5. After a week with no new violations from real visitors, they change the header name to Content-Security-Policy.

The finished storefront policy is longer than the starter, but every source in it is one they recognise and chose.

The fix, step by step

Edge cases worth knowing

• Policies in two places. Spring Security plus an nginx add_header means two headers. Both are enforced, so pick one owner for the policy.
• Error pages. Responses from Tomcat's default error handling or a proxy's 502 page may not pass through your filter. Test a missing URL with curl as well.
• nginx inheritance. An add_header inside a location block replaces all those set at server level. Repeat your headers in that block or use an include file.
• Angular critical CSS inlining. The production build can inline critical CSS and load the rest with an onload attribute, which a strict policy blocks. If the Console reports it, set inlineCritical to false under the styles optimisation options.
• Third-party scripts loading more scripts. Tag managers and widgets often pull in further domains. Adding 'strict-dynamic' alongside a nonce lets scripts you trusted load their own dependencies without listing every host.
• Meta tags. A <meta http-equiv="Content-Security-Policy"> tag works for most directives, but it ignores frame-ancestors, report-uri and sandbox, and scanners that only read headers will still report the header as missing.

Keeping the policy working

A Content Security Policy is not a set-and-forget header. Every new analytics tag, chat widget, font host or embedded video needs a matching source, and a developer under time pressure is tempted to add 'unsafe-inline' or a wildcard to make the error go away.

• Keep the policy string in one constant or configuration value, under version control, with a comment for each third-party source saying what it is for.
• Run the curl check in your deployment pipeline and fail the build if the header is missing or appears twice.
• Leave a reporting endpoint in place after you enforce, so you hear about breakages from real visitors, not from support tickets.
• Review the policy when you remove a supplier. Sources nobody uses any more are just extra places an attacker could host a script.
• Re-scan after framework upgrades. Spring Security, Tomcat and Angular each changed how headers or nonces work between major versions.

The security audit guide explains how CSP fits alongside the other headers that scanners check.