How To Implement Content Security Policy (CSP) Headers For Astro

Content Security Policy is like a bouncer for your website. It tells the browser what content is allowed to load and from where. This helps prevent a whole bunch of nasty attacks, like Cross-Site Scripting (XSS) and data injection.

Content Security Policy (CSP) should be implemented as a response header, not a request header. Here’s why:

1. CSP is a security mechanism enforced by the browser on the client-side.
2. The server sends the CSP directives to the browser as part of its response.
3. The browser then enforces these policies when loading and executing content.

So, in the context of Astro.js and web servers in general, CSP headers should be set on the server’s responses to the client. This means that when configuring CSP, we’re always dealing with response headers.

Implementing CSP in Astro

Let’s start with a basic CSP setup for an Astro site. We’ll use the astro.config.mjs file to add our headers.

1
import { defineConfig } from 'astro/config';
2

3
export default defineConfig({
4
  server: {
5
    headers: {
6
      "Content-Security-Policy": "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline';"
7
    }
8
  }
9
});

This configuration does a few things:

1. default-src 'self': Only allows resources to be loaded from the same origin.
2. script-src 'self' 'unsafe-inline': Allows scripts from the same origin and inline scripts (which Astro uses).
3. style-src 'self' 'unsafe-inline': Allows styles from the same origin and inline styles.

The Astro CSP Gotcha

Astro has a unique architecture that can trip up CSP. It uses a technique called “partial hydration” where some components are static and others are interactive. This means your CSP needs to be flexible enough to allow for this hybrid approach.

Here’s a more comprehensive CSP for a typical Astro site.

1
export default defineConfig({
2
  server: {
3
    headers: {
4
      "Content-Security-Policy": `
5
        default-src 'self';
6
        script-src 'self' 'unsafe-inline' 'unsafe-eval';
7
        style-src 'self' 'unsafe-inline';
8
        img-src 'self' data: https:;
9
        font-src 'self';
10
        object-src 'none';
11
        base-uri 'self';
12
        form-action 'self';
13
        frame-ancestors 'none';
14
        block-all-mixed-content;
15
        upgrade-insecure-requests;
16
      `
17
    }
18
  }
19
});

This policy is more permissive but still secure. It allows for Astro’s hydration needs 'unsafe-eval' and common use cases like loading images from HTTPS sources.

Vercel Approach

With Vercel, you can use a vercel.json file in your project root:

1
{
2
  "headers": [
3
    {
4
      "source": "/(.*)",
5
      "headers": [
6
        {
7
          "key": "Content-Security-Policy",
8
          "value": "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline';"
9
        }
10
      ]
11
    }
12
  ]
13
}

This applies the CSP header to all routes on your Vercel-deployed Astro site. All you have to do with git push to deploy your changes.

Cloudflare Approach

Cloudflare uses Page Rules to add headers. Here’s how you might set it up:

1. Go to your Cloudflare dashboard
2. Navigate to Rules > Page Rules
3. Click on the ‘Modify Response Headers’ tab
4. Click ‘Create rule’
5. Click ‘Add Static Header to Response’
6. Add a “CSP” Header:
   • Header Name: Content-Security-Policy
   • Value: Your CSP string

The advantage of Cloudflare’s approach is that you can easily update your CSP without redeploying your site.

Read Also

• Frontend Security Checklist
• MDN Web Docs: Content Security Policy