Visual CSP Builder

You should absolutely set up a CSP if your website handles user authentication, accepts text inputs, or loads third-party scripts. A CSP is your most effective frontend defense against Cross-Site Scripting (XSS) attacks. By explicitly defining which domains are allowed to load resources and execute scripts, you prevent malicious actors from injecting their own code (like session-stealing scripts in a comment section). While a purely static, read-only portfolio might not strictly need one, any modern SaaS, e-commerce, or CMS-driven site should consider a strict CSP a mandatory security requirement.

A highly secure CSP strictly limits where resources can be loaded from and explicitly blocks the execution of inline scripts and evaluations. The ideal baseline sets default-src 'none', explicitly allows script-src 'self' without 'unsafe-inline' or 'unsafe-eval', and mandates object-src 'none' to prevent legacy plugin exploits.

Modern third-party tools inject scripts, track requests, and embed hidden iframes (like Stripe's fraud detection). If your CSP is set to default-src 'self', the browser will instantly block these external domains. You must explicitly whitelist their required domains in script-src, connect-src, and frame-src.

Whenever possible, you should deploy your CSP via the server's HTTP Header. The <meta http-equiv> tag is a helpful fallback for statically hosted sites where you cannot modify server headers, but it lacks support for certain advanced directives (like frame-ancestors and report-uri).

The 'unsafe-inline' keyword allows the execution of inline scripts (like <script>console.log('hi')</script>) and inline event handlers (like onclick="..."). It is considered dangerous because it entirely defeats the primary purpose of CSP: stopping Cross-Site Scripting (XSS). If you allow inline scripts, an attacker who successfully injects a malicious script tag into your page will have their code executed by the browser.

The 'unsafe-eval' directive permits the use of JavaScript functions that evaluate text as code, such as eval(), setTimeout(String), and new Function(). You should avoid it whenever possible because it creates a massive vulnerability where user input could be tricked into executing as malicious code. However, some older frameworks and bundling tools (like older versions of Webpack during development) unfortunately still require it to run.

These are the fundamental building blocks of a policy. 'self' allows resources to load only if they come from the exact same origin as the document (same scheme, host, and port). 'none' blocks the resource entirely, regardless of where it comes from. The wildcard * allows the resource to load from absolutely anywhere on the internet, which is highly insecure and should generally be avoided.

If you absolutely must use an inline script (for example, to initialize analytics before external files load), you should use a nonce or a hash instead of opening the floodgates with 'unsafe-inline'. A nonce is a random, single-use string generated by your server and added to both your CSP header and the script tag (<script nonce="r@nd0m">). A hash involves taking the exact SHA-256 hash of your inline script's content and putting that hash directly into your CSP header.