Content Security Policy (CSP) is the strongest browser-side defence against cross-site scripting. It tells the browser which sources of scripts, styles, images and frames are allowed, and blocks everything else.

A weak CSP, for example one that allows unsafe-inline or any HTTPS host, looks protective but blocks very little.

How it happens

Most sites add CSP late and loosen it until nothing breaks. The result is a policy that allows inline scripts, eval or broad wildcards, which is exactly what an XSS payload needs.

Why it matters

• A strong CSP turns many XSS bugs into harmless, blocked attempts.
• It controls which third parties can run code on your pages.
• frame-ancestors also protects against clickjacking.

How to prevent it

• Start with Content-Security-Policy-Report-Only and collect violation reports.
• Use nonces or hashes instead of unsafe-inline.
• Avoid unsafe-eval and broad wildcards such as https:.
• Set object-src 'none', base-uri 'self' and frame-ancestors.
• Tighten the policy step by step, then switch to enforcing mode.

How Vooki Pro helps

• Detects a missing CSP and flags weak policies separately.
• Tests for XSS in the same scan, so you can see what the CSP is protecting against.
• Flags third-party scripts loaded without Subresource Integrity.
• Rescan after each change to confirm the policy is in place.

Frequently asked questions

What is unsafe-inline in CSP?

unsafe-inline allows inline scripts, which is exactly what most XSS payloads use. Replace it with nonces or hashes.

How do I roll out CSP without breaking my site?

Start with Content-Security-Policy-Report-Only, review the violation reports, fix or allow legitimate sources, then enforce.

Related: HTTP security headers: the essential list · HTTPS done right: HSTS and TLS configuration