Reshaping web defenses with strict Content Security Policy

Even with such a helpful tool, building a safe script whitelist for a complex application is often all but impossible due to the number of popular domains with resources that allow CSP to be bypassed. Here’s where the idea of a nonce-based CSP policy comes in. Instead of whitelisting all allowed script locations, it’s often simpler to modify the application to prove that a script is trusted by the developer by giving it a nonce -- an unpredictable, single-use token which has to match a value set in the policy:

Content-Security-Policy: script-src 'nonce-random123'

<script nonce='random123'>alert('This script will run')</script>
<script>alert('Will not run: missing nonce')</script>
<script nonce='bad123'>alert("Won't run: invalid nonce")</script>

With 'strict-dynamic', a part of the upcoming CSP3 specification already supported by Chrome and Opera (and coming soon to Firefox), adopting such policies in complex, modern applications becomes much easier. Developers can now set a single, short policy such as:

script-src 'nonce-random123' 'strict-dynamic'; object-src 'none'

and make sure that all static <script> elements contain a matching nonce attribute — in many cases this is all that’s needed to enjoy added protection against XSS since ‘strict-dynamic’ will take care of loading any trusted scripts added at runtime. This approach allows setting policies which are backwards-compatible with all CSP-aware browsers, and plays well with applications which already use a traditional CSP policy; it also simplifies the process of adopting CSP and doesn’t require changing the policy as the application evolves.

Adopting strict CSP
In the past months we’ve deployed this approach in several large Google applications, including Cloud Console, Photos, History, Careers Search, Maps Timeline, Cultural Institute and are working on many more. We believe this approach can also help other developers so today we’re publishing documentation discussing the best strategies for implementing CSP, including an overview of the benefits of CSP, sample policies, and examples of common code changes.

Further, today we’re releasing CSP Mitigator, a Chrome extension that helps developers review an application for compatibility with nonce-based CSP. The extension can be enabled for any URL prefix and will collect data about any programming patterns that need to be refactored to support CSP. This includes identifying scripts which do not have the correct nonce attribute, detecting inline event handlers, javascript: URIs, and several other more subtle patterns which might need attention.

As with the CSP Evaluator, we use the extension with our applications to help speed up the process of adopting nonce-based CSP policies nonce-based policies across Google.

Encouraging broader use of strict CSP
Finally, today we’re including CSP adoption efforts in the scope of the Patch Reward Program; proactive work to help make popular open-source web frameworks compatible with nonce-based CSP can qualify for rewards (but please read the program rules and CSP refactoring tips first). We hope that increased attention to this area will also encourage researchers to find new, creative ways to circumvent CSP restrictions, and help us further improve the mechanism so that we can better protect Internet users from web threats.

To reach out to us, email [email protected].