Security/CSP/Deploying

In this article, we'll recommend steps that can be taken to modify a web site so that it will support CSP base restrictions. We will also explain how to craft a CSP policy for a site that will provide a maximum amount of protection.

Supporting CSP base restrictions

While restricting content loads by source may help mitigate attacks, there are base restrictions needed to properly avoid more complex XSS script injection attacks. Let's take a look at all of the base restrictions employed by CSP and see how equivalent functionality can be obtained through other techniques.

Until a site has been converted to support these base restrictions, the "inline" and "eval" keywords in the script-src directive can be used to disable them. The effort required to support the base restrictions will vary by site, but we'll provide some guidelines on how to convert sites, one restriction at a time.

Removing Inline Scripts

You can skip this part by adding the inline keyword to the script-src directive in your site's CSP policy definition.

Inline scripts are more easily injected into a site than their externally sourced counterparts. This is a side effect of mixing code and content.

Event handling attributes in HTML tags

There are many HTML event handling attributes (on*) that can contain strings to be evaluated as script.

Removing "eval()"-like features

You can skip this part by adding the eval keyword to the script-src directive in your site's CSP policy definition.

Code generated on the fly can accidentally (or intentionally) contain user-specified content; any strings converted into script code during the run-time of a web application has the potential to be augmented and abused by an attacker. As a result, these must be removed from a site.

Often Misused Feature Clean up

• data: URIs
• XBL bindings