, 1 min read

On the Brittleness of Content Security Policy

I explored the possibility of employing Content Security Policy for this very blog. I succeeded in enforcing a couple of URL whitelists. But that showed that whenever the referring websites change anything on their end, I am cooked.

Below is an NGINX configuration to allow for JavaScript libraries like

  1. MathJax
  2. DataTables
  3. TikTok
  4. WordPress
  5. CodePen
  6. Ahrefs Analystics
  7. X/Twitter
add_header Content-Security-Policy "
    script-src 'self' 'unsafe-inline'
        https://cdn.datatables.net
        https://cdn.jsdelivr.net
        https://code.jquery.com
        https://platform.twitter.com
        https://s0.wp.com
        https://www.tiktok.com
        https://*.ttwstatic.com
        https://*.codepen.io
        https://public.codepenassets.com
        https://analytics.ahrefs.com;
    worker-src 'self' blob:;
" always;

Because I have inline JavaScript I need unsafe-inline.

For CodePen we explicitly need to whitelist public.codepenassets.com.

For TikTok we have to whitelist *.ttwstatic.com and worker-src 'self' blob:.

Obviously, if anything of those things change slightly, my blog is no longer fully functional.

Also see Mitigate cross-site scripting (XSS) with a strict Content Security Policy (CSP).

Frederik Braun notes on CSP:

Despite 15 years of work on CSP and similar technologies, I personally consider it to be a failure in solving XSS for the masses. According to the Web Almanac, less than 20% of websites have a CSP that even controls scripts. What's worse is that 90% of the CSPs out there still allow inline JavaScript. Essentially, providing no protection against XSS at all.