{"id":131077,"date":"2025-11-07T15:55:31","date_gmt":"2025-11-07T20:55:31","guid":{"rendered":"https:\/\/www.inmotionhosting.com\/support\/?p=131077"},"modified":"2025-11-07T15:56:29","modified_gmt":"2025-11-07T20:56:29","slug":"content-security-policy-csp-headers","status":"publish","type":"post","link":"https:\/\/www.inmotionhosting.com\/support\/website\/content-security-policy-csp-headers\/","title":{"rendered":"Content Security Policy (CSP) Headers – Complete Reference Guide"},"content":{"rendered":"\n

Web security isn’t optional anymore. If you’re running a website in 2025, you absolutely need Content Security Policy headers configured. CSP is your first line of defense against cross-site scripting (XSS) attacks, code injection, and a host of other threats that can compromise your site and your users’ data.<\/p>\n\n\n\n

This guide walks you through everything you need to know about CSP: what it is, why you need it, every directive available, and how to implement it correctly on your server.<\/p>\n\n\n\n

What Is Content Security Policy?<\/h2>\n\n\n\n

Content Security Policy (CSP)<\/strong> is an HTTP response header that tells browsers exactly which resources they’re allowed to load on your web page. Think of it as a whitelist for your website\u2014you explicitly define where scripts, styles, images, fonts, and other resources can come from.<\/p>\n\n\n\n

When a browser receives a page with a CSP header, it checks every resource against your policy before loading it. If something doesn’t match your rules, the browser blocks it and logs a violation. This prevents attackers from injecting malicious code into your site, even if they find a vulnerability in your application.<\/p>\n\n\n\n

CSP was introduced in 2004 and became a W3C recommendation in 2012. Today, all modern browsers support CSP Level 2, and CSP Level 3 features are widely adopted. It’s not bleeding-edge tech, it’s a proven security standard you should’ve implemented yesterday.<\/p>\n\n\n\n

Why You Need CSP Headers<\/h2>\n\n\n\n

Cross-site scripting remains one of the most common and dangerous web vulnerabilities. According to security research, nearly 20% of cyberattacks use XSS<\/a> or similar injection techniques. Without CSP, your site is vulnerable.<\/p>\n\n\n\n

Here’s what CSP protects against:<\/p>\n\n\n\n

Cross-Site Scripting (XSS)<\/strong>: The primary threat CSP was designed to combat. If an attacker manages to inject a <script><\/code> tag into your page, CSP blocks it from executing unless it comes from an approved source.<\/p>\n\n\n\n

Data Injection Attacks<\/strong>: Prevents unauthorized code from being loaded into your pages through compromised third-party resources or injection points.<\/p>\n\n\n\n

Clickjacking<\/strong>: Using the frame-ancestors<\/code> directive, you can control which sites can embed your pages in iframes, preventing clickjacking attacks.<\/p>\n\n\n\n

Mixed Content<\/strong>: Force all resources to load over HTTPS, preventing man-in-the-middle attacks on HTTP resources.<\/p>\n\n\n\n

Compromised CDNs<\/strong>: If a CDN you use gets compromised, CSP limits what malicious scripts can do since they won’t have the necessary permissions.<\/p>\n\n\n\n

Beyond security, CSP is increasingly required for compliance with security frameworks like ISO 27001. Not having a CSP can be a compliance risk.<\/p>\n\n\n\n

Complete CSP Directives Reference<\/h2>\n\n\n\n

CSP policies are built from directives. Each directive controls a specific type of resource or behavior. Multiple directives are separated by semicolons, and each directive has a name followed by allowed source values.<\/p>\n\n\n\n

Fetch Directives<\/h3>\n\n\n\n

Fetch directives control where resources can be loaded from. These are the workhorses of your CSP configuration.<\/p>\n\n\n\n

default-src<\/strong>: The fallback for all other fetch directives. If you don’t specify a directive like script-src<\/code>, the browser uses default-src<\/code>. Set this first.<\/p>\n\n\n\n