csp.md

September 24, 2024 ยท View on GitHub

A Content Security Policy (CSP) helps prevent a wide range of attacks like cross-site scripting (XSS), clickjacking, and other code injection attacks by controlling the resources a user agent is allowed to load. To check if a URL has a CSP, we can look at the response headers.

Characteristics of a Good CSP:

  • Default self or none: A strong CSP should restrict most sources by default using the default-src 'self'; directive, allowing resources to load only from the same origin.
  • Granular Directives: Good policies use specific directives for different types of content (script-src, style-src, img-src, etc.) rather than relying solely on default-src.
  • Avoidance of unsafe-inline and unsafe-eval: These allow inline scripts and eval() in JavaScript, which makes the policy much weaker. A good CSP avoids these directives.
  • Reporting Mechanism: Policies can specify report-uri or report-to for CSP violations, which helps in monitoring and detecting attempts to bypass the policy.
  • Use of Nonces or Hashes: A strong policy uses nonces (nonce-<random>) or hashes (sha256-<hash>) for inline scripts and styles instead of unsafe-inline.

Characteristics of a Lacking CSP:

  • Allowing Wildcards (*): A policy that allows resources to load from any domain (e.g., script-src *;) is weak and ineffective.
  • Overuse of unsafe-inline and unsafe-eval: This essentially negates many of the protections CSP provides.
  • Over-reliance on default-src: Using default-src for everything without defining specific policies for scripts, styles, etc., can allow for more risk.
  • Lack of Reporting: A CSP without a reporting mechanism loses visibility into possible attacks or misconfigurations.