Csp on Commentary of Takao

Designing Modern Content Security Policies for Hugo blogs

Fri, 05 Jun 2026 00:00:00 +0900

Why CSP Matters for Static Sites

Static sites built with Hugo are inherently more secure than dynamic applications, but they still execute third-party scripts for analytics, ads, and embeds. A Content Security Policy (CSP) protects your visitors from XSS, data injection, and malicious script execution by controlling which resources can load.

Setting CSP via Cloudflare Pages

Cloudflare Pages supports custom _headers files for controlling HTTP response headers:

# static/_headers
/*
 Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'

For Hugo, place the _headers file in your static/ directory so it gets copied to the output:

Testing CSP Rules Safely with Content-Security-Policy-Report-Only

Fri, 15 May 2026 00:00:00 +0900

Deploying a Content Security Policy is one of the strongest defenses against XSS attacks. But a single misconfigured directive can silently break inline scripts, block CDN resources, or disable analytics. If you apply CSP directly via the Content-Security-Policy header and a critical script gets blocked, your production site breaks—often without an obvious error console notification.

This is where Report-Only mode saves the day.

Report-Only vs Enforced Mode

CSP supports two headers:

Why and How to Adopt 'strict-dynamic' in CSP

Sun, 15 Jun 2025 00:00:00 +0900

Introduction

Implementing a Content Security Policy (CSP) is a highly effective way to mitigate Cross-Site Scripting (XSS) risks. However, configuring and maintaining the policy can become a major headache.

For websites utilizing third-party SDKs (such as Google Tag Manager, analytics beacons, payment widgets, or social sharing buttons), these scripts often dynamically load (inject) additional scripts from nested domains. This forces developers to maintain a long, fragile whitelist of external domains in the script-src directive.