Research

Evidence, not assertion

Original data on what the web actually does about client-side security.

We help organisations see and control what runs in their users' browsers. This section is the evidence behind that. We crawl the top million sites, and we read the live policies of the organisations getting client-side security right, so what we build and what we recommend come from what's measurably working rather than from what sounds sensible.

The Crawl
Updated daily · snapshot 13 June 2026

10 years of watching the web

The top 1 million sites, crawled every day since 2016. Ten years of that data shows a consistent split: the controls an infrastructure provider can switch on for you improved steadily, and the ones needing somebody to go back and finish the configuration did not. CSP adoption grew more than 12,000% over the decade — and 46.8% of those policies still carry unsafe-inline.

Read the findings →
Download the PDF →

The Evidence
Read from live response headers

Google chose CSP, and you should too

Gmail, YouTube, Cloud Console, Google Drive, Adyen, PayPal, American Express and GitHub all enforce a Content Security Policy. This is what their live headers say, how to re-check them yourself, and what the migration did to Google's XSS rate — from 30% of vulnerability reward payouts in 2018 to 4.1% in 2023.

Read the evidence →

The Evidence
Read from live response headers

Dropbox wrote down how they did it

Four posts from a Dropbox security engineer in 2015 on getting a Content Security Policy into production — including the report noise that nearly stopped them, and the three-stage filter they had to build before the reports were readable. The policy is still in their headers to this very day.

Read the evidence →

The Evidence
Read from live response headers

GitHub allows script from one hostname

Their first policy, in 2013, contained default-src * — and GitHub still credit it with substantially reducing XSS risk. Three years of public tightening later they removed even their own origin from script-src, then published a whole post on what CSP could not stop, closed those gaps, and kept the policy.

Read the evidence →

The Evidence
Read from live response headers

Twitter said their site was too old for CSP

In 2013 they published why the policy was running on every property except the front page: a wealth of inline JavaScript in one of their oldest projects. That is the objection most teams stop at. Today x.com sends a nonce and forbids inline event handlers outright — the exact thing that was blocking them.

Read the evidence →

The Evidence
Read from live response headers

GOV.UK ran report-only for years

The only rollout in this research carried out entirely in public: the decision record that proposed it, the developer manual, the shared library the policy lives in, and the header it produces. They moved to enforce in Summer 2023 — and wrote down that the volume of false positives nearly cost them the reporting.

Read the evidence →

The Evidence
Read from live response headers

login.gov publishes its policy as code

The single sign-on service for US federal services runs the cleanest policy in this research — no unsafe-inline, no unsafe-eval, nonces on both scripts and styles. And because it is built in the open, you can read the policy source and every change ever made to it rather than inferring it from a header.

Read the evidence →

Why We Publish It

The data says the same thing our product does

The work here keeps arriving at the same finding from different directions: a security control is only worth what you know about it once it is live. Deploying one is the easy half, and the half most of the web has done. Knowing it is still doing its job — that nothing changed, that nothing new appeared, that the policy still says what you think it says — is the half that needs somebody watching.

That watching is what we run. See how CSP reporting works →

Start 30-Day Free Trial PCI DSS guide →