Content Security Policy: The Easy Way to Prevent Mixed Content

I recently learned about a browser feature where, if you provide a special HTTP header, it will automatically post to a URL with a report of any non-HTTPS content. This would be a great thing to do when transitioning a site to HTTPS, for example, to root out any mixed content warnings. In this article, we’ll implement this feature via a small WordPress plugin.

What is mixed content?

“Mixed content” means you’re loading a page over HTTPS page, but some of the assets on that page (images, videos, CSS, scripts, scripts called by scripts, etc) are loaded via plain HTTP.

I’m going to assume that we’re all too familiar with this warning and refer the reader to this excellent primer for more background on mixed content.

What is Content Security Policy?

A Content Security Policy (CSP) is a browser feature that gives us a way to instruct the browser on how to handle mixed content errors. By including special HTTP headers in our pages, we can tell the browser to block, upgrade, or report on mixed content. This article focuses on reporting because it gives us a simple and useful entry point into CSP’s in general.

CSP is an oddly opaque name. Don’t let it spook you, as it’s very simple to work with. It seems to have terrific support per caniuse. Here’s how the outgoing report is shaped in Chrome:

{
    "csp-report": {
        "document-uri":"http://localhost/wp/2017/03/21/godaddys-micro-dollars/",
        "referrer":"http://localhost/wp/",
        "violated-directive":"style-src",
        "effective-directive":"style-src",
        "original-policy":"default-src https: 'unsafe-inline' 'unsafe-eval'; report-uri http://localhost/wp/wp-json/csst_consecpol/v1/incidents",
        "disposition":"report",
        "blocked-uri":"http://localhost/wp/wp-includes/css/dashicons.min.css?ver=4.8.2",
        "status-code":200,
        "script-sample":""
    }
}

Here’s what it looks like in its natural habitat:

What do I do with this?

What you’re going to have to do, is tell the browser what URL to send that report to, and then have some logic on your server to listen for it. From there, you can have it write to a log file, a database table, an email, whatever. Just be aware that you will likely generate an overwhelming amount of reports. Be very much on guard against self-DOSing!

Can I just see an example?

You may! I made a small WordPress plugin to show you. The plugin has no UI, just activate it and go. You could peel most of this out and use it in a non-WordPress environment rather directly, and this article does not assume any particular WordPress knowledge beyond activating a plugin and navigating the file system a bit. We’ll spend the rest of this article digging into said plugin.

---

Sending the headers

Our first step will be to include our content security policy as an HTTP header. Check out this file from the plugin. It’s quite short, and I think you’ll be delighted to see how simple it is.

The relevant bit is this line:

header( "Content-Security-Policy-Report-Only: default-src https: 'unsafe-inline' 'unsafe-eval'; report-uri $rest_url" );

There a lot of args we can play around with there.

• With the Content-Security-Policy-Report-Only arg, we’re saying that we want a report of the assets that violate our policy, but we don’t want to actually block or otherwise affect them.
• With the default-src arg, we’re saying that we’re on the lookout for all types of assets, as opposed to just images or fonts or scripts, say.
• With the https arg, we’re saying that our policy is to only approve of assets that get loaded via https.
• With the unsafe-inline and unsafe-eval args, we’re saying we care about both inline resources like a normal image tag, and various methods for concocting code from strings, like JavaScripts eval() function.
• Finally, most interestingly, with the report-uri $rest_url arg, we’re giving the browser a URL to which it should send the report.

If you want more details about the args, there is an excellent doc on Mozilla.org. It’s also worth noting that we could instead send our CSP as a meta tag although I find the syntax awkward and Google notes that it is not their preferred method.

This article will only utilize the HTTP header technique, and you’ll notice that in my header, I’m doing some work to build the report URL. It happens to be a WP API URL. We’ll dig into that next.

Registering an endpoint

You are likely familiar with the WP API. In the old days before we had the WP API, when I needed some arbitrary URL to listen for a form submission, I would often make a page, or a post of a custom post type. This was annoying and fragile because it was too easy to delete the page in wp-admin without realizing what it was for. With the WP API, we have a much more stable way to register a listener, and I do so in this class. There are three points of interest in this class.

In the first function, after checking to make sure my log is not getting too big, I make a call to register_rest_route(), which is a WordPress core function for registering a listener:

function rest_api_init() {

    $check_log_file_size = $this -> check_log_file_size();
    if( ! $check_log_file_size ) { return FALSE; }

    ...                

    register_rest_route(
        CSST_CONSECPOL . '/' . $rest_version,
        '/' . $rest_ep . '/',
        array(
           'methods'  => 'POST',
           'callback' => array( $this, 'cb' ),
        )
    );

}

That function also allows me to register a callback function, which handles the posted CSP report:

function cb( \WP_REST_Request $request ) {

    $body = $request -> get_body();
    $body = json_decode( $body, TRUE );
    $csp_report = $body['csp-report'];

    ...

    $record = new Record( $args );
    $out = $record -> get_log_entry();

}

In that function, I massage the report in it’s raw format, into a PHP array that my logging class will handle.

Creating a log file

In this class, I create a directory in the wp-content folder where my log file will live. I’m not a big fan of checking for stuff like this on every single page load, so notice that this function first checks to see if this is the first page load since a plugin update, before bothering to make the directory.

function make_directory() {

    $out = NULL;

    $update = new Update;
    if( ! $update -> get_is_update() ) { return FALSE; }

    $log_dir_path = $this -> meta -> get_log_dir_path();
    $file_exists = file_exists( $log_dir_path );

    if( $file_exists ) { return FALSE; }

    $out = mkdir( $log_dir_path, 0775, TRUE );

    return $out;

}

That update logic is in a different class and is wildly useful for lots of things, but not of special interest for this article.

Logging mixed content

Now that we have CSP reports getting posted, and we have a directory to log them to, let’s look at how to actually convert a report into a log entry,

In this class I have a function for adding new records to our log file. It’s interesting that much of the heavy lifting is simply a matter of providing the a arg to the fopen() function:

function add_row( $array ) {

    // Open for writing only; place the file pointer at the end of the file. If the file does not exist, attempt to create it.
    $mode = 'a';

    // Open the file.
    $path   = $this -> meta -> get_log_file_path();
    $handle = fopen( $path, $mode );

    // Add the row to the spreadsheet.
    fputcsv( $handle, $array );

    // Close the file.
    fclose( $handle );

    return TRUE;

}

Nothing particular to WordPress here, just a dude adding a row to a csv in a normal-ish PHP manner. Again, if you don’t care for the idea of having a log file, you could have it send an email or write to the database, or whatever seems best.

Caveats

At this point we’ve covered all of the interesting highlights from my plugin, and I’d advice on offer a couple of pitfalls to watch out for.

First, be aware that CSP reports, like any browser feature, are subject to cross-browser differences. Look at this shockingly, painstakingly detailed report on such differences.

Second, be aware that if you have a server configuration that prevents mixed content from being requested, then the browser will never get a chance to report on it. In such a scenario, CSP reports are more useful as a way to prepare for a migration to https, rather than a way to monitor https compliance. An example of this configuration is Cloudflare’s “Always Use HTTPS“.

Finally, the self-DOS issue bears repeating. It’s completely reasonable to assume that a popular site will rack up millions of reports per month. Therefore, rather than track the reports on your own server or database, consider outsourcing this to a service such as httpschecker.net.

Next steps

Some next steps specific to WordPress would be to add a UI for downloading the report file. You could also store the reports in the database instead of in a file. This would make it economical to, say, determine if a new record already exists before adding it as a duplicate.

More generally, I would encourage the curious reader to experiment with the many possible args for the CSP header. It’s impressive that so much power is packed into such a terse syntax. It’s possible to handle requests by asset type, domain, protocol — really almost any combination imaginable.