Security Headers Guide

• Start in report-only. Ship Content-Security-Policy-Report-Only with the policy you eventually want. It blocks nothing and reports everything, so production traffic tells you what would have broken.
• Collect reports for a full business cycle. A fortnight catches the weekly batch job, the monthly invoice run, and the marketing tag someone adds on a Friday. A day catches your own testing.
• Fix the violations, do not widen the policy. Every report is either a dependency you forgot about or inline code that should move to a file. Adding the offending origin to the allow-list is how policies decay into permitting everything.
• Use nonces rather than 'unsafe-inline'. Generate a random nonce per response, put it on your own script tags and in the policy. Inline script injected by an attacker will not carry it.
• Set base-uri and object-src. Without base-uri 'self' an injected <base> tag re-points every relative script URL at the attacker. It is the most commonly missed directive in an otherwise decent policy.
• Enforce, then keep the report endpoint.Move the header to the enforcing name and leave reporting on. It is how you find out that last week's deploy is now silently blocked.

Content-Security-Policy-Report-Only:
  default-src 'self';
  script-src 'self' 'nonce-{RANDOM_PER_RESPONSE}';
  style-src 'self' 'nonce-{RANDOM_PER_RESPONSE}';
  img-src 'self' data:;
  connect-src 'self';
  frame-ancestors 'none';
  base-uri 'self';
  object-src 'none';
  form-action 'self';
  report-uri /csp-report

Tighten from here rather than loosening towards here. If a directive has to be relaxed, relax that one directive instead of falling back on default-src.