CSP: Report-Only Mode, Common Directives & Migration

Testing Safely With Report-Only Mode

Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-violations

# Violations are logged/reported but NOT actually enforced --
# lets a team catch legitimate resources a policy would
# incorrectly block, before switching to full enforcement

Other Common Directives

• frame-ancestors -- controls which sites can embed this page in an iframe, defending against clickjacking.

• object-src 'none' -- blocks legacy plugin content (Flash, Java applets) with a history of vulnerabilities.

• upgrade-insecure-requests -- rewrites plain-HTTP resource URLs to HTTPS automatically.

Why Wildcards Defeat the Purpose

A directive like script-src * allows scripts from literally any origin, undermining CSP's entire premise as an allowlist-based defense -- an attacker's injected script from any external domain would still be permitted to run.

Retrofitting CSP on an Existing App

Mature codebases often accumulate inline scripts, inline event handlers, or third-party integrations a strict policy would block by default. Auditing and refactoring these -- validated via report-only mode first -- is a common, non-trivial migration step.

CSP Is Defense in Depth, Not a Substitute

Proper input sanitization and output encoding prevent a malicious script from ever being injected in the first place. CSP is a secondary safety net limiting the damage IF that primary defense fails -- neither replaces the need for the other.