Sun Jul 26, 2015
FYI: this post is an artifact of the Dark Ages when my blog was self-hosted WordPress. Let us not speak of that time.
This lil’ blog is hosted by the MIT Student Information Processing Board and runs on a fairly-uncustomized WordPress 4.x installation. Although I could have enabled CSP by modifying my .htaccess file, I chose to use HTML tags instead so that these instructions would work for people who don’t have shell access to their WordPress host. Unfortunately, CSP using hasn’t landed in Firefox yet (tracking bug) so I should probably do the .htaccess thing anyway.
It’s pretty easy to turn on CSP in WordPress from the dashboard:
- Go to
/wp-admin/theme-editor.php. Note that this isn’t available for WordPress-hosted blogs (*.wordpress.com).
- Click on Header (header.php) in the sidebar to edit the header HTML.
- At the start of the HTML
<head>element, add a CSP meta tag with your CSP policy. This blog uses
<meta http-equiv="Content-Security-Policy" content="script-src 'self'">which disallows all scripts except from its own origin (including inline scripts). As far as I can tell, this blocks a few inline scripts but doesn’t impede any functionality on a vanilla WordPress instance. You might want a more permissive policy if you use fancy widgets and plugins.
<noscript>element to your header.
A fun fact I discovered during this process is that embedding a SoundCloud iframe will include tracking scripts from Google Analytics and scorecardresearch.com. Unfortunately CSP on the embedding page (my blog) doesn’t extend to embedded contexts (soundcloud.com iframe), so those scripts will still run unless you’ve disabled JS.
That’s all. I might do more posts on WordPress hardening later or even write a WP plugin (*shudders at the thought of writing PHP*). More tips are welcome too.
UPDATE (8/24/15): CSP is temporarily disabled on this blog because Google Analytics uses an inline script. I’ll nonce-whitelist it later and turn CSP back on.