CSP is an HTTP header that blocks unauthorized scripts and resources, preventing XSS, clickjacking, and data injection attacks by allowing only trusted sources. 2. Implement it via the Content-Security-Policy header with directives like script-src, style-src, and img-src to restrict resource loading. 3. Avoid 'unsafe-inline' and 'unsafe-eval', use nonces or hashes for inline scripts, and explicitly allow trusted third-party domains without wildcards. 4. Test using Report-Only mode with a report-uri to monitor violations before enforcement. 5. Fix common issues like blocked inline scripts by moving to external files or using unique nonces per request. 6. Adopt a zero-trust baseline with default-src 'none' and explicitly permit required sources. 7. Monitor violation reports for blocked resources and refine the policy until stable. 8. Deploy a strong, tailored policy that balances security and functionality, ensuring continuous monitoring and updates as dependencies evolve.

Content Security Policy (CSP) is one of the most effective tools for mitigating common web vulnerabilities like cross-site scripting (XSS), clickjacking, and data injection attacks. It works by allowing developers to define exactly which resources the browser can load — such as scripts, styles, images, and fonts — and from where. If implemented correctly, CSP can drastically reduce the risk of malicious code execution.

But despite its power, CSP is often misunderstood or poorly configured. This guide breaks down CSP into practical steps, helping you implement a strong policy without breaking your site.

What CSP Actually Does

At its core, CSP is an HTTP response header that tells the browser:
"Only run scripts or load assets from these trusted sources — and nowhere else."

For example, if an attacker injects a malicious script into your page (via XSS), but that script isn’t hosted on one of your approved domains, CSP blocks it from executing.

Common threats CSP helps prevent:

• XSS attacks (reflected, stored, DOM-based)
• Insecure inline scripts and event handlers
• Untrusted third-party resource loading
• Data exfiltration via unauthorized endpoints

CSP doesn’t replace input validation or secure coding practices — it adds a strong safety net.

How to Implement a Basic CSP Header

Start by adding the Content-Security-Policy header to your server responses. Here's a minimal but practical example:

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

Let’s break down what each part means:

• default-src 'self' – Fallback: only allow resources from the same origin.
• script-src 'self' – Only load JavaScript from your own domain.
• style-src 'self' 'unsafe-inline' – Allow CSS from your domain and inline <style> tags (commonly needed).
• img-src 'self' data: – Allow images from your domain and embedded data URLs.

? Tip: Avoid 'unsafe-inline' and 'unsafe-eval' when possible. They weaken security significantly.

You can test your policy using the Content-Security-Policy-Report-Only header first — it won’t block anything but reports violations.

Example:

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

This lets you monitor issues before enforcing the policy.

Common Pitfalls and How to Avoid Them

Even with good intentions, CSP setups often fail due to real-world complexity. Here are frequent issues and how to handle them:

1. Blocking legitimate inline scripts

Many sites rely on inline <script> tags or onclick="" handlers. CSP blocks these by default.

? Fix:

• Move scripts to external files.
• Use nonce or hash attributes for allowed inline scripts.

Example with nonce:

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

Then in CSP:

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

The server must generate a unique nonce per request — never reuse.

2. Third-party dependencies (analytics, widgets, CDNs)

Tools like Google Analytics, Facebook SDKs, or Cloudflare fonts require external domains.

? Fix: Explicitly allow trusted domains:

script-src 'self' https://www.google-analytics.com https://apis.google.com;
font-src 'self' https://fonts.gstatic.com;

Only allow specific hosts — avoid wildcards like *.com.

3. Dynamic scripts or JSONP

Some legacy code builds script URLs dynamically or uses eval().

? Problem: These often trigger CSP violations and indicate insecure patterns.

? Fix:

• Refactor to use modules or safe APIs.
• Use strict-dynamic for modern setups:

  script-src 'self' 'unsafe-inline' 'strict-dynamic' https:;

  This allows scripts to load other scripts if initiated by trusted sources.

?? Note: strict-dynamic improves compatibility but reduces protection if the initial script is compromised.

Testing and Monitoring Your CSP

A misconfigured CSP can break your site. Always test carefully.

Steps to test:

• Use Report-Only mode first.
• Set up a report endpoint to collect violations:

  Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://yourdomain.com/csp-reports

• Use tools like Report URI or self-hosted loggers.
• Monitor logs for blocked resources — they’ll show what’s breaking.

Common violation examples in reports:

• Blocked inline script from 'unsafe-inline'
• Script loaded from cdnjs.cloudflare.com not in allowlist
• Base64-encoded image blocked due to data: not in img-src

Once reports are clean, switch to enforcing mode.

A Realistic Strong CSP Example

Here’s a balanced, secure policy for a typical modern web app using Google Fonts and Analytics:

Content-Security-Policy: 
  default-src 'none';
  script-src 'self' 'nonce-random123' https://www.google-analytics.com;
  style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
  img-src 'self' data: https:;
  font-src 'self' https://fonts.gstatic.com;
  connect-src 'self' https://api.yoursite.com;
  frame-src 'none';
  object-src 'none';
  base-uri 'self';
  form-action 'self';
  report-uri /csp-violation-report

Key improvements:

• default-src 'none' starts with zero trust.
• Explicitly allows only what’s needed.
• Blocks <object></object>, <embed></embed>, and untrusted frames.
• Uses nonce for inline scripts.
• Reports violations for monitoring.

Generate the nonce server-side per request.

Final Thoughts

CSP isn’t a one-size-fits-all solution, but it’s one of the best defenses against client-side attacks. Start small, use Report-Only mode, fix breakages, then enforce.

Remember:

• Avoid 'unsafe-inline' and 'unsafe-eval'.
• Use nonces or hashes for necessary inline scripts.
• Only allow third-party domains you trust.
• Monitor reports continuously.

With careful tuning, CSP can make your site far more resilient — without sacrificing functionality.

Basically, it’s not magic, but done right, it’s one of the smartest moves you can make for web security.

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