CentralCSP

Main menu

All articles

Next Article

CSP scanner & evaluator

HTTP Headers vs Meta Tags Implementation

Saturday, November 16, 2024

4 min read

Theotime Quere

Theotime Quere

Content Security Policy helps protect your website from attacks like XSS and code injection. You can add CSP using either HTTP headers or meta tags in your HTML, each method looks the same, but some differences exist and need to be highlighted.

Understanding CSP Basics

A Content Security Policy defines which resources are allowed to be loaded and executed on your webpage. It acts as a whitelist, explicitly stating which sources are trusted.

Learn more about CSP basics

Example of a simple CSP policy

Content-Security-Policy: default-src 'self'; script-src 'self' https://website.com

Implementation Methods

1. HTTP Headers (Recommended)

The most secure and recommended way to implement CSP is through HTTP headers:

Example of a simple CSP policy in HTTP headers

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.com

Here's how to implement CSP in http headers in popular web servers:

Add this to your Nginx server block configuration:

server {
    # ... other configurations ...
    
    add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://trusted.com;";
    
    # For testing with Report-Only mode
    add_header Content-Security-Policy-Report-Only "default-src 'self'; report-uri https://report.centralcsp.com/your-endpoint;";
    
    # ... rest of your configuration ...
}

Best Practice

Using HTTP headers ensures that the CSP is enforced before any content is loaded, providing maximum security coverage.

2. Meta Tags

CSP can also be implemented using HTML meta tags, though this method has limitations:

Example of a simple CSP policy in meta tags

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8">
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
    
        <!-- CSP Meta Tag Implementation -->
        <meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' https://trusted.com">
                    
        <title>Your Website</title>
    </head>
    <body>
        <!-- Your website content -->
    </body>
</html>

Limitations of Meta Tags

  • No Report-Only Mode

    Meta tags don't support Content-Security-Policy-Report-Only, making it impossible to test policies without potentially breaking your site. Learn more about Report-Only mode.

  • Limited Directive Support

    • frame-ancestors

      The frame-ancestors directive is not supported in meta tags.

    • sandbox

      The sandbox directive is not supported in meta tags.

  • JavaScript Execution Timing

    Browsers might execute JavaScript before processing the CSP when using meta tags, as the policy only takes effect after HTML parsing begins.

Security Risk

If an attacker manages to inject JavaScript before the CSP meta tag is processed, they could bypass the policy entirely. This creates a race condition vulnerability that doesn't exist with HTTP headers.

Using Both Methods Together

When both HTTP headers and meta tags are present, browsers will combine both policies using the most restrictive rules from each.

Example of a simple CSP policy in HTTP headers

Content-Security-Policy: default-src 'self';

Example of a simple CSP policy in meta tags

<meta http-equiv="Content-Security-Policy" content="default-src 'self' https://website.com;">

Result

In this example, even though the meta tag allows 'self' and website.com, the final policy will only allow 'self' because the HTTP header is more restrictive. Resources from website.com will be blocked by the policy in the HTTP header.

Best Practices

  • Always prefer HTTP headers for CSP implementation.

  • Use our CSP Scanner to validate your policies.

  • CSP reporting endpoint. Use our CSP reporting endpoint to monitor violations.

  • Only use meta tags when HTTP headers cannot be modified.

  • Test your policies thoroughly using Report-Only mode before enforcement. Learn more about Report-Only mode.

Getting Started with CSP

Follow these steps to implement and monitor your Content Security Policy effectively:

Create your Account

Sign up for a CentralCSP account in a minute. Get 14 days free trial.

Create a Reporting Endpoint

Once logged in, register you application and get your reporting endpoint. You'll receive a unique endpoint URL that looks like: https://report.centralcsp.com/[your-endpoint-id]

Configure Your CSP Headers

Add your new endpoint URL to your CSP configuration using both report-uri and report-to directives for maximum browser compatibility.

Monitor Violations

Access your CentralCSP dashboard to view and analyze any CSP violations in real-time. You'll receive detailed reports about blocked resources and potential security issues.

First Tier Benefits

The first tier includes all essential features: real-time violation reporting, detailed analytics, and support for multiple domains. Upgrade only when you need advanced features like custom alerting, API access, or higher volume reporting.

Conclusion

While meta tags provide an alternative way to implement CSP, HTTP headers remain the recommended approach due to better feature support, earlier policy enforcement, and complete directive coverage. Only use meta tags when technical constraints prevent you from modifying HTTP headers.

Continue Reading

frame-ancestors vs X-Frame-Options

Learn the differences between CSP frame-ancestors directive and X-Frame-Options header, and how to properly protect your site from clickjacking attacks.

2024-02-25

3 min read

Theotime Quere

Theotime Quere

Read more →

CSP enforce & report only

Understanding the difference between enforce and report only modes in Content-Security-Policy implementation.

2024-11-18

5 min read

Theotime Quere

Theotime Quere

Read more →

Docs

CSP ScannerCSP EvaluatorReporting Endpoint

Contact


CentralSaaS © 2025