Content Security Policy meta http-equiv

Content Security Policy is a browser-enforced policy that restricts which resources a page can load and execute. It is the strongest defense against Cross-Site Scripting: even if an attacker injects a <script> tag, the browser refuses to run it unless the policy allows.

CSP can be sent as an HTTP response header (Content-Security-Policy: ...) or as a meta tag in HTML: <meta http-equiv="Content-Security-Policy" content="...">. The header is preferred; the meta tag is useful when you cannot control the server.

default-src is the fallback for unspecified resource types. script-src, style-src, img-src, connect-src (XHR/fetch), font-src, frame-src each restrict their kind. Whitelist specific origins or use 'self' for same-origin only.

'self' (quoted) refers to the page's own origin. script-src 'self' means "only run scripts hosted on the same origin as the page". This is the baseline for most policies; add specific external CDNs as needed.

By default, CSP blocks all inline <script> tags and event-handler attributes (onclick). This is the strongest XSS protection: an injected <script> cannot run because it is inline. Move all scripts to external files referenced by src.

For necessary inline scripts, use a nonce: server generates a random token per request, sets it as script-src 'nonce-RANDOM' in CSP, and adds nonce="RANDOM" to legitimate <script> tags. Injected scripts lack the nonce and are blocked.

'unsafe-inline' re-allows inline scripts and styles. 'unsafe-eval' re-allows eval() and new Function(). Both severely weaken CSP — use only as last resort during a migration, plan to remove them.

CSP delivered via meta tag cannot use the report-uri directive (or other reporting features). It also takes effect later than a header — anything before the meta tag is unprotected. Headers are strictly better; use meta only as a fallback.

Test a new policy without breaking the site: Content-Security-Policy-Report-Only: .... The browser reports violations without blocking them, so you can refine the policy until it allows all legitimate resources before flipping to enforcement.

Forgetting style-src 'unsafe-inline' blocks inline styles (often produced by frameworks). Forgetting connect-src blocks AJAX to APIs. Always test the policy in report-only mode first and review the console for blocked resources.

Strict CSP combines script-src 'nonce-RANDOM' 'strict-dynamic' for scripts plus a tight allow-list for everything else. 'strict-dynamic' lets nonced scripts load further scripts without listing each one — much easier to maintain than per-origin allow-lists.

How does CSP defend against XSS attacks even when an attacker successfully injects a script tag?

CSP is browser-enforced policy restricting which scripts, styles, images and other resources can load. Deliver via response header (preferred) or meta tag. Use nonces for needed inline scripts, avoid unsafe-inline/unsafe-eval, test in report-only mode first. Strict CSP with 'nonce-X' 'strict-dynamic' is the modern baseline.