CSP IN A NUTSHELLIn a typical XSS attack, the attacker injects arbitrary Javascript into a page, which is then executed by an end-user. When a website enables CSP, the browser ignores inline Javascript and only loads external assets from a set of whitelisted sites. Enabling CSP on our site was simply a matter of including the policy in the returned headers under the CSP defined key, ‘X-Content-Security-Policy’.The policy also contains a ‘reporting URI’ to which the browser sends JSON reports of any violations. This feature not only assists debugging of the CSP rules, it also has the potential to alert a site’s owner to emerging threats.[...]Our initial trials revealed that some libraries were evaluating strings of Javascript and triggering a violation, most notably jQuery 1.4, which tests the ‘eval’ function after load. This wasn’t totally unexpected and we modified some of the libraries to get them to pass. Since jQuery fixed this in 1.5, it is no longer an issue.
INITIAL RESULTS
After a soft launch, we ran into some unexpected issues. Several common Firefox extensions insert Javascript on page load, thereby triggering a report. However, even more surprising were the number of ISPs who were inadvertently inserting Javascript or altering image tags to point to their caching servers. It was the first example of how CSP gave us visibility into what was happening on the user’s end. We addressed this problem by mandating SSL for Firefox 4 users, which prevents any alteration of our content.Today CSP is one hundred percent live on mobile.twitter.com and we are logging and evaluating incoming violation reports.
This report was recommended by https://web.dev/articles/csp#real_world_usage.
The injection of scripts by ISPs part was the most interesting. Good example why (authenticated) encryption is important.