Security and trust boundaries
CSPresso runs real website code. Understand what is trusted, what is contained and what still needs review.
Process sandbox and CSP: different protections
Chromium’s process sandbox is enabled by default. It limits what browser processes can do to the host; it does not filter normal script/style origins or prevent the observations needed to draft a CSP. Use a non-root account with OS sandbox support.
--bypass-csp removes existing CSP response headers from same-origin HTML so they do not hide loads during discovery or evaluation. It does not disable Chromium’s sandbox or remove meta CSP. Remaining meta CSP is disclosed and makes evaluation incomplete.
--no-sandbox is an explicit compatibility override for suitably isolated, trusted workloads. It is not required for CSP discovery, and launch failures never turn it on automatically.
What needs protecting
| Boundary | Realistic risk | Controls and limits |
|---|---|---|
| Website → runner | Compromised pages or third-party assets may exploit browser vulnerabilities. | Sandbox enabled; fresh non-persistent context; run non-root without credentials or sensitive mounts. Keep browser dependencies updated. |
| Runner → internal network | Pages and subresources may contact private, loopback or link-local services. | Crawl scope is not an egress firewall. Apply network controls outside the process when needed; private development targets remain supported. |
| Scan → target application | Scripts can POST and links can invoke state-changing GET endpoints. | Use staging/test accounts and explicit exclusions. A scan is active, not read-only; non-GET redirects are not replayed. |
| Observed content → policy | Compromised code may be recommended as allowed. Malformed metadata must not become CSP syntax. | Validated origins/tokens, permission provenance and source maps as metadata only. Review every suggestion; a hash can still authorise malicious observed code. |
| Scan status → CI decision | Incomplete injection or coverage can look like a pass. | Per-document injection confirmation and exit 2 for incomplete/error scans. A hostile page can manipulate its own behavior; this is not a tamper-proof verifier. |
| Local user → browser cache | Shared directories permit executable substitution or file manipulation. | Owned cache checks, rejection of unsafe/symlink paths, no shared temporary fallback and OS-released installation locks. |
| Page → resources | Large bodies, request storms and scripts can exhaust CPU, memory or bandwidth. | Time/request/observation limits and disabled accepted downloads. These do not replace OS memory/disk/network quotas; interception can buffer responses. |
| Output → readers | URLs, query tokens, internal hosts and violation records may be sensitive. | Restrict access and retention. Human diagnostics escape control characters; URL secrets are not automatically redacted. |
Know what the scan cannot establish
The tool does not prove that a site is free of XSS or compromised dependencies. It observes attempted loads and a settled DOM over finite selected coverage, not every user interaction or successful response. Report-Only cannot reproduce all effects of enforcement.
Service workers are blocked for deterministic interception. Worker-internal loads, CSS data URLs, shadow DOM, removed early scripts, authenticated flows and other engines need separate testing. Ambiguous WebSocket frame ownership is reported as incomplete. Redirect hops are navigated explicitly, which can change timing/history and trigger aborted-load events.
Fresh browser contexts do not import your normal browser profile, but cookies set during a scan can affect subsequent pages. Do not automatically deploy generated output. Review and tighten it, then test real application flows in staging.
Operating safely
For untrusted content, use disposable non-root execution, Chromium sandboxing, minimal filesystem access, appropriate network egress restrictions and external resource limits. CI alone is not isolation: avoid exposing deployment keys, cloud credentials or host mounts to the scan.
The project’s Docker CI explicitly disables the sandbox only for trusted loopback test fixtures on its existing root runner. That test-only setting is not read by the production CLI. A non-root sandbox-capable runner is preferable.
Verify release signatures with the mig5 GPG key, fingerprint 54A91143AE0AB4F7743B01FE888ED1B423A3BC99. Runtime containment does not establish package or build-chain trust.