Start with Content-Security-Policy-Report-Only to monitor violations without enforcement. 2. Set up a report-uri endpoint to collect and analyze CSP violation reports. 3. Build a strict policy using default-src 'none' and explicitly allow only required sources. 4. Eliminate unsafe practices by replacing inline scripts with external files or using nonces/hashes. 5. Deploy the enforced policy and continuously monitor reports to refine directives. CSP must be implemented gradually, avoiding 'unsafe-inline' and 'unsafe-eval', whitelisting only trusted domains, and ensuring compatibility with your site’s functionality, all while maintaining robust reporting to detect issues early.

Content Security Policy (CSP) is a powerful browser feature that helps prevent a wide range of attacks, especially cross-site scripting (XSS) and data injection attacks. By defining which sources of content are allowed to load on a web page, CSP acts as a defense-in-depth mechanism, limiting the damage malicious scripts can cause—even if they somehow get injected.

Here’s how to understand and implement CSP effectively.

What Is Content Security Policy?

CSP is an HTTP response header (Content-Security-Policy) that lets you declare which domains and types of content are permitted to be loaded and executed by the browser. For example, you can specify:

• Where scripts can be loaded from
• Which domains can embed your site in an iframe
• Whether inline scripts or eval() are allowed

Without CSP, browsers will load and execute scripts from any source—including potentially malicious ones injected via vulnerabilities.

CSP works by defining a policy—a string of directives—sent in the HTTP header:

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

Each directive controls a different type of resource.

Key CSP Directives You Should Know

Here are the most commonly used directives:

• default-src: Fallback for most resource types if not explicitly set.
• script-src: Controls where JavaScript can be loaded from (including inline and eval()).
• style-src: Governs CSS sources, including inline styles.
• img-src: Defines valid image sources.
• connect-src: Restricts URLs that can be loaded via script (e.g., fetch, XMLHttpRequest).
• font-src: Specifies allowed font sources.
• frame-ancestors: Controls which sites can embed your page (replaces X-Frame-Options).
• object-src: For plugins like Flash (should be restricted).
• base-uri: Limits the <base> tag to prevent redirection attacks.
• form-action: Restricts URLs that can be used as form targets.

?? Best Practice: Avoid 'unsafe-inline' and 'unsafe-eval'. These defeat the purpose of CSP by allowing dangerous execution patterns.

How to Implement CSP Step-by-Step

Implementing CSP can be tricky because overly strict policies can break your site. Follow these steps:

1. Start in Report-Only Mode

Use Content-Security-Policy-Report-Only to test your policy without enforcing it:

Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report-endpoint

This allows you to collect violations via a reporting endpoint without disrupting users.

2. Set Up a Report Endpoint

Add a report-uri or report-to directive to receive violation reports:

report-uri /csp-violation-capture

Your server should accept POST requests to this endpoint and log the JSON reports. Example report:

{
  "csp-report": {
    "document-uri": "https://example.com/page",
    "violated-directive": "script-src 'self'",
    "blocked-uri": "https://malicious.com/evil.js",
    "original-policy": "script-src 'self'; ..."
  }
}

These reports help identify what needs to be allowed or fixed.

3. Build a Realistic Policy

Start with a restrictive base and allow only what's necessary:

Content-Security-Policy: 
  default-src 'none';
  script-src 'self' https://trusted-cdn.com;
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https://images.example.com;
  font-src 'self';
  connect-src 'self';
  frame-ancestors 'self';
  form-action 'self';
  base-uri 'self';

• Use 'none' as default to block everything unless explicitly allowed.
• Only add third-party domains you truly depend on (e.g., Google Fonts, analytics).

4. Eliminate Unsafe Practices

To strengthen CSP:

• Replace inline scripts with external files.
• Use nonce or hash for unavoidable inline scripts:

<script nonce="2726c7f26c">
  // inline script
</script>

Then in CSP:

script-src 'self' 'nonce-2726c7f26c'

• Avoid eval(); refactor code if needed.

5. Deploy and Monitor

Once testing is complete, switch from Report-Only to full enforcement. Continue monitoring reports to catch edge cases.

Common Pitfalls and Tips

• *Don’t allow `orunsafe-inline` in production.** They undermine security.
• CDNs and external scripts must be explicitly whitelisted.
• Data URLs (data:) should be limited to specific directives like img-src.
• Self includes the same scheme—if your site is HTTPS, 'self' won’t allow HTTP.
• Browser support is excellent, but always test in major browsers.

Final Thoughts

CSP isn’t a silver bullet, but it’s a critical layer in modern web security. Start small, use reporting, and gradually tighten your policy. The goal isn’t perfection on day one—it’s progress toward reducing attack surface.

With careful implementation, CSP can block entire classes of attacks before they execute. It’s not complex, but it does require attention to detail. Get it right, and you’ll make XSS much harder to exploit.

Basically, define what your site needs, block the rest, and keep an eye on the reports.

The above is the detailed content of Understanding and Implementing Content Security Policy (CSP). For more information, please follow other related articles on the PHP Chinese website!