CSP and CORS: different browser boundaries, not security certificates

Roll out CSP from explicit requirements

Allow only the resource sources the application actually needs. Broad wildcards and unsafe-inline or unsafe-eval can undo important restrictions. Report-Only observes violations but does not block them; an enforcing header has a different effect. Test normal pages, errors, third-party integrations and browser support before promotion.

A nonce placeholder needs server integration: generate a fresh unpredictable value for every response and apply the matching nonce to intended elements. The CSP specification recommends at least 128 bits before encoding. Do not paste a fixed demo nonce into production or let untrusted markup acquire it. A policy cannot replace correct output escaping or authorization.

CORS is about sharing a response

For credentialed cross-origin reads, Access-Control-Allow-Origin must match the serialized origin and Access-Control-Allow-Credentials must be the case-sensitive value true. A wildcard origin is not sufficient. A successful preflight does not excuse a missing final-response CORS header.

Authorization must be explicitly allowed rather than covered by Access-Control-Allow-Headers: *. Method and header safelists, credential mode and supplied values affect preflight. A blocked read does not mean the server was never contacted or that a state-changing request had no effect. CORS is not CSRF protection or an API access-control system.

Keep simulation and live verification distinct

The tools process only supplied settings. They do not contact a server, follow redirects or inspect TLS, cookie policy, browser extensions or preflight-cache state. An apparent mismatch may require checking the actual network trace and deployment configuration, not broadening a policy until a warning disappears.