How Response-Header CSP Works in AstroWEBTheme

A Content Security Policy only protects a page if the browser receives it before parsing. AstroWEBTheme sends the policy as a real response header and builds it from the same configuration that decides which scripts the site uses.

From config to header

1. src/site/config/security.mjs collects the allowed origins. It reads the analytics, advertising, captcha and function settings, so enabling a provider adds exactly the origins that provider needs and nothing else.
2. On server-rendered routes, src/middleware.ts creates a random nonce for each request, builds the policy for that path and sends it as the content-security-policy header.
3. Scripts the theme controls receive the same nonce, so inline code runs only when the page that carries it was served by you.
4. For static deployments, the build writes a _headers file instead. The generator aborts if the file is missing a policy, so a deployment cannot silently ship without one.

Reports

cspReportHandler in functions.mjs points violation reports to a separate Worker. Reports show what a policy blocked in real traffic before you tighten it further.

Why not a meta tag

A <meta http-equiv> policy applies only after the browser has begun parsing, and it cannot express every directive. Header delivery avoids both limits.

Check it yourself

curl -sI https://astrowebtheme.com/ | grep -i content-security-policy

Related: Response-Header CSP for Client Sites and Security Architecture by Default.