Today I'm really excited to announce one of the first big steps that Report URI is taking towards making CSP even easier to use, deploy and maintain. With the introduction of the CSP Wizard, it's never been easier to create a CSP for your site.


Setting up a CSP

Until today there was pretty much only one way to setup a CSP on your site, you needed to know where you load content from so that you can whitelist those sources in the CSP. For small sites this isn't so hard but as soon as you have a few pages or sections on your site, it can become quite difficult. My blog isn't particularly large or complex in nature but I still have a few edge cases here and there for my CSP. There are one or two articles where I embed Google Fusion Tables, some where I frame YouTube and others where I include libraries only on those specific pages. I have a diverse set of pages and each one could have its own unique requirements for the CSP. This means that I slowly built my policy, manually, by inspecting incoming reports from the policy I crafted with what I knew at the time. This is a very noisy process, generates a lot of traffic and means we're collecting heaps of data that simply isn't needed. I thought to myself there had to be a better way, so we built one.

The CSP Wizard

The Wizard works on a simple premise, it's often really hard to know exactly what content you load on your site. With that in mind, there is one reliable entity that we can ask that knows exactly what's on each and every one of your pages, the browser. Not just one browser though, every browser. Every single browser that ever visits your website. We're going to ask them to help us build our CSP because they are the single most reliable source of information out there. They will navigate every page, use every different language and version of your site, exercise all possible workflows and navigate to places you've long forgotten even exist. The superset of all of your visitors are omniscient.

For this to work we simply ask the browser to tell us about every piece of content it encounters on our site. To do that, we must block every piece of content of on our site, but of course we must do it safely, we will do it in Report Only mode. The CSP required to do this would look like this:

Content-Security-Policy-Report-Only: default-src 'none'; form-action 'none'; frame-ancestors 'none'; report-uri https://{subdomain}

With that CSP deployed onto your site the browser will fire a report for everything on the page. Any asset that it loads, form that it POSTs, XHR request made and everything else in-between. These reports will be sent and from them you will have visibility of everything that is happening on your site. For those that have used CSP reporting before, either independently or through Report URI, you will know that this is going to produce a lot of data. So much so that under the current paradigm of sifting through reports to extract the information it'd be close to impossible.

Simplifying reporting

The CSP Wizard doesn't handle reports in the traditional way. You don't end up with a table of reports to view and inspect because you're not interested in most of what the report has to say. What we're trying to do now is get a fairly robust policy together to deploy to our site and have it be at least mostly accurate. This is why the Wizard has its own, simpler interface.


When the Wizard is monitoring your CSP reports, all it will look at is the directive that was applied in the policy and the site that was blocked. It will then populate this list with each unique combination for your analysis. If you want to allow a particular action, let's say a script-src of, you simply click the Allow button and it will be added to your policy. Once that has happened it will be removed from the main screen and you won't need to think of it again. Exactly the same process applies to things that you don't want to allow into your CSP too. We have an entry for a script-src loading from, you simply hit the Block button and the item will be removed, never to be thought of again.

Throughout this process you may, of course, need to check if certain sources should be whitelisted or not. There will be obvious ones to Allow and obvious ones to Block, but some thought will always be required about what you want to allow into your CSP. Each item only requires your attention once and while you may end up with a big list at the start, it will quickly be reduced and your policy will start to mature. Trough out the process you can also keep track of which items you have Allowed and Blocked on each of the respective lists.



My Policies

When using the Wizard it will generate a policy for you that is stored in the new Policies section of the CSP menu. You can now store your policies here and the Wizard will work with one of the policies you have created.


For now, the policy objects can be stored here and viewed or modified using the Wizard. You can also select which policy is currently active with the Wizard so you can develop and store multiple policies for different sites and applications.

In future releases these policies will become more and more useful as we expand the ways in which you can interact with them. You will be able to import them into the CSP Builder for manual editing and tweaking, there will be an API endpoint where you can fetch your policy string in a variety of formats for use in server config or application code and there's even going to be some surprises with regards to integrations too. Check back for those in the coming weeks and months.

We're going to be rich!!!

Some of you reading along may already have a few questions about exactly how the Wizard is going to work. The policy suggested above is going to generate a lot of reports, and by a lot, I really do mean a lot. As a service with volume based pricing this is of course favorable to us and the Wizard is probably the best money making scheme in existence.

Evil Plan:

  1. Create feature that causes customers to send millions of reports.
  2. Charge customers for millions of reports.

It sounds like a match made in heaven for us! Before I go any further though, let me take a little trip down memory lane. Way back in May 2015 I launched what was back then and it was a free service for all to use. I built it and ran it with the costs being paid out of my own pocket because I wanted to help sites better deploy features like CSP. Since then it has grown, a lot, I've asked for support and released countless updates 1 2 3 4 5 and eventually I couldn't support the service any longer. In late 2017 the service moved from being a free service to being a commercial service so that it could survive. My options were to charge for usage or close it down because I simply couldn't afford the running costs. I announced the commercial launch and things went incredibly well, with everything from small blogs to large enterprise sites signing up. The money wasn't to make profit, Report URI was never about that, it was to make the service sustainable so that it could continue and grow, and that hasn't changed.

We built the CSP Wizard to help sites that have never had a CSP to build a pretty reliable policy with minimal effort, but the way in which we have to do that will generate a large volume of reports by nature. That's the reason I'm making the following commitments:

  1. Reports sent to the CSP Wizard will receive a 99% discount when billed.
  2. The CSP Wizard will be available to all users, even free accounts.
  3. We will help customers minimise the impact of using the Wizard on their quota.

Report URI became a commercial service but our mission never changed, we're here to help everyone make the web more secure. I believe that helping sites to deploy a strong CSP perfectly aligns with that mission and that's exactly what the Wizard does. Most of the reports sent to the Wizard will have minimal processing and storage overheads compared to a standard report, which covers us for most of the billing discount, and the rest comes straight from us. I will follow up with a technical blog on how we're planning to handle the volume of traffic this will generate at a later date.

Minimising volume

Before you get started with the Wizard if you are worried about volume here are a couple of tips on how to reduce and manage the volume of reports.

Downsample the policy

When you set the policy on your site you don't have to set it on every page all of the time. Perhaps you only set the header on 1/100 responses, only on certain sections of your site or only for an hour a day during peak times. The Wizard policy doesn't have to be deployed 24/7 using your quota. Deploy it for short periods and deal with the reports that are generated in batches.

Update the Wizard policy

As you're updating your policy with entries being Allowed and Blocked in the Wizard, you can deploy this new policy and still have it report to the Wizard. This will massively reduce the volume of reports being sent and quickly bring your usage under control. Getting the largest offenders covered in the policy will make a big difference.


I wanted to quickly address this point because some people may be wondering if using the CSP Wizard, or even CSP reporting at all, will have a performance impact on their site. Whilst using the Wizard will result in extra requests being sent on the network, it won't have a negative effect on the performance of your pages as CSP reports are sent asynchronously and with a low priority. If you check the waterfall network view in Chrome you will see that CSP reports might not even be sent if there's low throughput on the network. Our service is designed to complete the connection as quickly as possible and for valid reports we don't return any content in the response to further minimise the impact. Overall I'm pretty happy to say there won't be any performance impact felt by your visitors.

Open Beta

From the publication of this blog post the CSP Wizard is now in open Beta for all customers. We've trialled it, we've tested it, but nothing will put it through its paces quite like all of you giving it a go! I've long been a believer in shipping something when it's useful and not when it's ready. Besides, if we shipped it when I thought it was ready, it'd never ship!