An Overview of Content Security Policy

Content Security Policy (CSP) is an added layer of security that helps detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement or distribution of malware. CSP provides a set of standard HTTP headers that allow website owners to declare approved sources of content that browsers should be allowed to load on that page — covered types are JavaScript, CSS, HTML frames, fonts, images and more.

How CSP Works

The CSP works by whitelisting approved content sources. All resources not explicitly allowed will be blocked. This way you have a tighter control over what gets loaded on your website. For example, if myCSP is defined as:


Content-Security-Policy: default-src 'self'; script-src 'self' cdn.example.com;


This will allow scripts from the current host and from cdn.example.com to be loaded, but not from any other sources. Something to note is that CSP gets applied to a page ahead of any other code, so inline scripts and events are also subject to whitelist restrictions.

Advantages of Using CSP

Here are some benefits of using a content security policy:

• Prevents broad classes of attacks like XSS and data injection by whitelisting sources of script, styles, fonts etc
• Defends against attacks like clickjacking by whitelisting allowed frames
• Mitigates aftermath of code injection by restricting connections
• Makes it easier to identify code injection issues during development
• Helps prevent some cross-site request forgery attacks when used with nonces

Implementing an Effective CSP

To make use of CSP, you need to configure your web server to return the Content-Security-Policy HTTP header. Alternatively the tag can be used. Start by setting a policy with only ‘self’ allowed, then add external sources as required. It’s also recommended to implement a report-only policy first, which will log CSP violations without blocking. This helps identify any unintended breakage before enforcing the restrictions.

CSP is a simple but powerful tool to restrict untrusted resources and help prevent and mitigate the impact of code injection issues in your application. With some smart configuration, it can significantly boost your site’s security posture.

Setting Up a Content Security Policy

To implement a CSP, you first need to determine what sources your web application requires content from. This will be specific to your architecture and dependencies. Some common sources are:

• ‘self’ for content from same origin
• CDN domains for external libraries
• APIs or external services interacting with AJAX requests
• Third party widgets and embeds

You then construct a policy defining the approved sources for content types like scripts, images, styles etc. For example:


Content-Security-Policy:
default-src 'self';
script-src 'self' cdn.example.com;
style-src 'self' cdn.example.com;
img-src 'self' data: cdn.example.com;


This allows content from same origin and cdn.example.com. The data: source allows inline images like Base64 encoded ones. You can further tighten policies by disallowing ‘unsafe-inline’ which blocks inline scripts and style attributes.

Policy Application

There are two main ways to apply the policy:

• HTTP Header – Configured on the server to send as a header for each page
• HTML meta tag – Placed in the HTML to apply policy to that page

The HTTP header method ensures the policy is present on every page. The meta tag way allows setting different policies for different pages.

Reporting and Logging

It’s recommended to first deploy a report-only policy to log violations before enforcing restrictions. This is done by specifying:


Content-Security-Policy-Report-Only:
default-src 'self';
...


With reporting enabled, violations will get logged but not blocked. Access these reports to find any unintended breakage before deploying full enforcement.

Other CSP Capabilities

Some other useful CSP features are:

• Nonces – Adds randomness to inline scripts/styles to whitelist them
• Hashes – Allows whitelisting inline scripts/styles by sha hash
• Directives like upgrade-insecure-requests and block-all-mixed-content to enforce HTTPS

Content Security Policy is a powerful protection. With smart policy tuning and testing, it can significantly lock down websites from different code injection risks.