Content Security Policy Builder

What a Content-Security-Policy does

A Content-Security-Policy (CSP) is a response header that tells the browser which sources of content — scripts, styles, images, fonts, frames, and more — are allowed to load or execute on a page, directive by directive. It's a defence-in-depth measure against cross-site scripting (XSS): even if an attacker manages to inject a <script> tag into your page through an unescaped input, a policy that only allows scripts from 'self' stops the browser from executing anything the attacker injected inline or from a third-party domain. A CSP doesn't prevent the injection itself — proper output escaping and validation still matter — but it limits the blast radius when something slips through.

Reading the directives

default-src is the fallback any unspecified directive inherits from, so setting it to 'self' gives you a reasonably safe baseline. script-src and style-src control JavaScript and CSS specifically and are usually the most consequential — leaving 'unsafe-inline' out of script-src is one of the single biggest wins against XSS, though it does mean every inline <script> block and inline event handler in your HTML has to move to an external file or use a nonce/hash instead. frame-ancestors controls who can embed your page in an iframe (the modern replacement for the old X-Frame-Options header) and is your clickjacking defence. object-src 'none' blocks Flash/plugin content almost nobody needs anymore. base-uri and form-action are easy to forget but matter: an unrestricted base-uri lets an injected <base> tag silently redirect all your relative URLs, and an unrestricted form-action lets an injected form submit credentials to an attacker's domain.

Start in report-only mode

Rolling out a strict CSP directly as an enforced header on a site with any complexity is a reliable way to break something you didn't anticipate — a third-party analytics script, a CDN font, an inline style your CSS framework injects. Ship it first as Content-Security-Policy-Report-Only instead of Content-Security-Policy, paired with a report-uri or report-to directive, so violations are logged without actually blocking anything, then tighten and switch to enforcement once the reports settle down.

Setting the header in Laravel

The cleanest place to attach this header is a small piece of middleware that runs on every response:

// app/Http/Middleware/AddCspHeader.php
public function handle($request, Closure $next)
{
    return $next($request)->header(
        'Content-Security-Policy',
        "default-src 'self'; script-src 'self'; style-src 'self'"
    );
}

Register it in your HTTP kernel's global middleware stack so it applies uniformly, rather than adding the header ad hoc in individual controllers.

Setting the header in Nginx

If you'd rather set it at the web server layer instead of (or in addition to) the application, Nginx can add it directly — see the Nginx config tool for building out the surrounding server block:

add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self'" always;

The trailing always flag matters — without it, Nginx only attaches the header on certain response codes (2xx/3xx), silently omitting it on 4xx/5xx error pages where you'd still want the protection.