Your security policy may be hiding your revenue

Security work is usually described as keeping bad things out. In the first month of our current engagement, two of the most expensive findings were about the opposite: a policy that kept good things out, and a visitor that should have been stopped long ago.

Finding 1: the site was blocking its own tracking

Modern sites can tell the browser which outside services a page is allowed to load: a content security policy. It is a good defence. It is also easy to get wrong. On this site, the policy was blocking its own analytics and ad tracking.

Nothing looked broken, so nobody went looking. But measurement that is blocked never arrives, and decisions were being made on numbers with pieces missing.

The tempting fix is to loosen the policy until the errors stop. The right one is to allow exactly the services the site uses, and nothing else, so tracking works and the protection stays.

Finding 2: one bot was out-crawling Google

One automated visitor was making 331,829 requests a day, more than Google’s crawler and three other major crawlers combined. It added load, slowed pages for real visitors, and polluted the analytics.

We blocked it: 100% of its requests stopped, 0% of Google’s. The second number matters as much as the first. Before blocking anything that calls itself a crawler, verify it by its network address, not by the name it sends.

Check your own site

1. Open your key pages with the browser’s developer console visible. Security-policy errors appear there, in red.
2. Compare the clicks your partners report with the clicks your own tracking records. A gap is a clue.
3. Look at your server logs by visitor, not by page. One name making a large share of requests deserves a look.
4. When something is exposed, report it privately to the people who can fix it. We never describe security exposures in public, and neither should you.