From feba218b229a9f2f899c7b359d82fc1f31f4afb9 Mon Sep 17 00:00:00 2001 From: wbamberg Date: Fri, 18 Oct 2024 15:04:40 -0700 Subject: [PATCH] Update files/en-us/web/http/csp/index.md Co-authored-by: Hamish Willee --- files/en-us/web/http/csp/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/files/en-us/web/http/csp/index.md b/files/en-us/web/http/csp/index.md index a10c2713ecab680..cf75d7da97c7e38 100644 --- a/files/en-us/web/http/csp/index.md +++ b/files/en-us/web/http/csp/index.md @@ -328,7 +328,7 @@ Unlike `unsafe-inline`, the `unsafe-eval` keyword does still work in a directive To control script loading as a mitigation against XSS, recommended practice is to use nonce- or hash- based fetch directives. This is called a _strict CSP_. This type of CSP has two main advantages over a location-based CSP (usually called an _allowlist CSP_): - Allowlist CSPs are hard to get right and often policies inadvertently whitelist unsafe domains, and hence don't provide effective protection against XSS (see [CSP Is Dead, Long Live CSP! On the Insecurity of Whitelists and the Future of Content Security Policy](https://dl.acm.org/doi/pdf/10.1145/2976749.2978363)). -- Allowlist CSPs can be very large and hard to maintain. According to [How I learned to stop worrying and love the Content Security Policy](https://www.netlify.com/blog/general-availability-content-security-policy-csp-nonce-integration/), just to integrate Google Analytics, a developer is asked to add 187 Google domains to the allowlist. +- Allowlist CSPs can be very large and hard to maintain, in particular when using scripts that are outside of your control. According to [How I learned to stop worrying and love the Content Security Policy](https://www.netlify.com/blog/general-availability-content-security-policy-csp-nonce-integration/), just to integrate Google Analytics, a developer is asked to add 187 Google domains to the allowlist. A nonce-based strict CSP looks like this: