Start with a basic CSP in report-only mode using Content-Security-Policy-Report-Only to avoid breaking functionality. 2. Set up a report endpoint to collect violation data and identify unauthorized resources. 3. Iterate by tightening directives—use 'self', specific domains, nonces, or hashes instead of 'unsafe-inline' or *. 4. Apply key directives like script-src, style-src, img-src, and connect-src to restrict resource loading. 5. Avoid common pitfalls by testing thoroughly, handling dynamic content, and preventing data exfiltration via connect-src. 6. Automate monitoring with tools like Sentry or Report URI and integrate CSP checks into CI/CD. Implementing CSP correctly significantly reduces XSS and injection risks by enforcing strict content source controls.

Securing Your Frontend: A Guide to Content Security Policy (CSP)

If you're building a modern web application, you’re likely pulling in scripts, styles, images, and other resources from various sources. But every external resource is a potential attack vector—especially for cross-site scripting (XSS) and data injection attacks. That’s where Content Security Policy (CSP) comes in. It’s not a magic bullet, but it’s one of the most effective frontend security controls you can implement.

CSP helps you define which sources of content are trusted, reducing the risk of malicious code execution. Let’s break down how it works and how to implement it effectively.

What Is Content Security Policy?

CSP is an HTTP response header (Content-Security-Policy) that allows you to declare approved sources of content for your web page. Browsers enforce this policy, blocking anything that doesn’t match the rules. Think of it as a whitelist for where your site can load scripts, styles, fonts, images, and more.

Without CSP, if an attacker manages to inject a script (e.g., via a comment form), the browser will execute it. With a strong CSP, that injected script won’t run—even if it gets into the page.

Example CSP header:

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; img-src *; style-src 'self' 'unsafe-inline'

This tells the browser:

• Load resources only from the same origin by default
• Allow scripts from the same origin and https://trusted.cdn.com
• Allow images from any domain
• Allow styles from the same origin and inline styles (though 'unsafe-inline' weakens security)

Key CSP Directives You Should Know

Each directive controls a different type of resource. Here are the most important ones:

• default-src – Fallback for most other directives if they’re not explicitly set
• script-src – Controls where JavaScript can be loaded from (critical for XSS protection)
• style-src – Defines valid sources for CSS
• img-src – Restricts image loading origins
• font-src – Specifies allowed font sources
• connect-src – Limits URLs that can be loaded via AJAX, WebSockets, etc.
• frame-src – Controls which sites can be embedded in iframes
• object-src – For plugins like Flash (should be restricted)
• base-uri – Prevents <base> tag hijacking
• form-action – Restricts URLs that can be used as form targets

Avoid using unsafe options like 'unsafe-inline' or 'unsafe-eval' in script-src unless absolutely necessary—and even then, consider alternatives.

How to Implement CSP Effectively

Implementing CSP can be tricky because it can break your site if not done carefully. Here’s a practical approach:

1. Start in Report-Only Mode Use Content-Security-Policy-Report-Only to test your policy without enforcing it. This lets you catch violations without breaking functionality.

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

2. Collect and Analyze Violations Set up a report endpoint (e.g., /csp-report-endpoint) to collect violation reports. These JSON payloads will show you what's being blocked and help refine your policy.

3. Iterate and Tighten Based on reports, adjust your policy. For example, if your app loads Google Fonts, add fonts.googleapis.com to font-src.

4. Avoid Overly Permissive Rules Don’t use * or 'unsafe-inline' unless you have no alternative. Instead:

   • Use nonces or hashes for inline scripts
   • Host third-party libraries locally when possible
   • Use strict dynamic for modern script loading

5. Use Nonces or Hashes for Inline Scripts If you must use inline scripts (e.g., for analytics), use a unique cryptographic nonce:

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

   And in your CSP:

   script-src 'nonce-2726c7f26c'

   Alternatively, use a hash of the script content:

   script-src 'sha256-0qz8rOZ9fJ5z3k3F5...'

   ---

   Common Pitfalls and How to Avoid Them

   • Breaking the site with strict policies → Always test in report-only mode first.
   • Using unsafe-inline for styles/scripts → This defeats the purpose of CSP. Use nonces or migrate to external files.
   • Forgetting about dynamic content → AJAX, WebSockets, and redirects are controlled by connect-src and frame-src.
   • Not protecting against data exfiltration → Even with CSP, a compromised script could send data via connect-src. Restrict this directive carefully.

   ---

   Bonus: Automate and Monitor

   • Use tools like Report URI or Sentry to collect and analyze CSP violations.
   • Integrate CSP checks into your CI/CD pipeline.
   • Monitor for sudden spikes in violations—they could indicate an attempted attack.

   ---

   CSP isn’t hard to start with, but getting it right takes attention. Begin with a basic policy, use reporting to guide improvements, and gradually lock things down. The payoff? A much stronger defense against XSS and content injection attacks.

   Basically, if you're not using CSP, you're leaving a critical door unlocked. Close it.

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