Avoiding Death by a Thousand Scripts: Using Automated Content Security Policies

Businesses know they need to secure their client-side scripts. Content security policies (CSPs) are a great way to do that. But CSPs are cumbersome. One mistake and you have a potentially significant client-side security gap. Finding those gaps means long and tedious hours (or days) in manual code reviews through thousands of lines of script on your web applications. Automated content security policies can help streamline the code review process by first identifying all first- and third-party scripts and the assets they access, and then generating an appropriate content security policy to help better secure the client-side attack surface.

There are few developers or AppSec professionals who claim to enjoy deploying CSPs. First, the CSP has to work for the specific web application. Then the team needs to make sure it provides the appropriate level of protection. The CSP also can’t conflict with any existing widgets or plugins (or the decision must be made to not deploy the CSP or deactivate those plugins, which can cause problems in other areas, such as customer engagement, marketing, and sales).

And then, when a CSP fails, there is the dreaded audit to determine the why and where.

The CSP-audit-avoidance problem (aka avoiding manual code reviews or death by a thousand scripts) is fairly common. Today, client-side web applications contain thousands of scripts, assembled from multiple open-source libraries or other third- and fourth-party repositories. Few development or security teams take the time to maintain a detailed record of all the scripts used in web application assembly, including their functions, their sources, and whether they’ve been updated or patched to address any known security issues.