CSP Quality: Tighten Resource Loading Without Breaking the Page

Content Security Policy quality is not just about having a Content-Security-Policy header present. It is about whether the policy is strict enough to reduce risk while still matching how the site actually loads resources.

What This Check Looks For

  • Whether a CSP header exists.
  • Whether the policy relies on weak allowances such as unsafe-inline or overly broad wildcards.
  • Whether important directives are missing for scripts, styles, frames, images, and other external resources.
  • Whether the policy appears deliberate instead of a placeholder that offers little real protection.

Why It Matters

A strong CSP reduces the chance that injected scripts or unexpected third-party resources can execute in the browser. That matters for user trust, security posture, and technical launch quality.

For launch readiness, a weak policy often signals that frontend dependencies, tag managers, or inline code were added without a clear security model.

Common CSP Problems

unsafe-inline in script rules

Allowing inline scripts makes cross-site scripting attacks easier to exploit. Prefer nonces or hashes when inline code is unavoidable.

Overly broad wildcards

Policies like script-src * or permissive host patterns reduce the practical value of CSP. Limit sources to the exact domains you control or explicitly trust.

Missing fallback directives

A policy is easier to reason about when default-src is defined and more specific directives override it where needed.

Stale third-party domains

Old analytics, chat, or CDN domains often remain in CSP long after they are no longer used. Remove them to reduce unnecessary exposure.

Practical Best Practices

  • Start with a clear default-src 'self' baseline where possible.
  • Use script-src nonces or hashes instead of unsafe-inline.
  • Keep third-party domains narrowly scoped and reviewed.
  • Add report-to or report-uri only if you will actually monitor violations.
  • Re-test the policy after product, marketing, or tag-manager changes.

Example Policies

Minimal baseline

Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'

Policy with external assets

Content-Security-Policy: default-src 'self'; script-src 'self' https://www.googletagmanager.com 'nonce-r4nd0m'; style-src 'self' 'unsafe-inline'; img-src 'self' https: data:; font-src 'self' https://fonts.gstatic.com; connect-src 'self' https://region1.analytics.google.com; object-src 'none'; base-uri 'self'; frame-ancestors 'self'

Express nonce example

import crypto from 'node:crypto';

app.use((req, res, next) => {
    const nonce = crypto.randomBytes(16).toString('base64');

    res.locals.cspNonce = nonce;
    res.setHeader(
        'Content-Security-Policy',
        `default-src 'self'; script-src 'self' 'nonce-${nonce}'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'`
    );

    next();
});

Quick Check

curl -I https://example.com

Then inspect the Content-Security-Policy header and confirm it is both present and intentional.

curl -I https://example.com | rg -i "content-security-policy"

Review the policy for broad wildcards, unsafe-inline, and stale third-party domains.

Final Takeaway

Good CSP quality means the policy is specific, maintained, and aligned with the page's real resource loading behavior. A weak CSP may look compliant at a glance while still leaving major gaps.