AI Coding Agents
Security
CSP testing for coding agent web changes
September 29, 2026 - 2 minute read
Content Security Policy testing checks whether a page loads its intended resources while blocking unapproved ones. A coding agent may add an analytics script, embedded frame, worker, or inline style that conflicts with the current policy. Broadening a directive until the page renders can remove protection from unrelated routes.
Content Security Policy Level 3 defines directives that control resource loading and other browser behavior. A useful test suite checks the effective browser policy, including headers from the application, proxy, and content delivery network.
Start CSP testing with the existing policy
Capture the policy for representative routes before changing it. Record each directive, its source list, and whether the header enforces or only reports violations. A report-only policy produces useful observations but does not block a resource.
Identify the smallest directive affected by the feature. A new image host belongs in img-src, while an embedded application may need frame-src. Adding a domain to default-src can grant access to several resource types that lack a more specific directive.
Keep development behavior separate. Hot reload, source maps, and local tooling often need allowances that production pages should not inherit.
Test allowed and blocked browser behavior
Load a page that exercises the changed feature and inspect console violations and network requests. Confirm that approved scripts, styles, images, connections, frames, fonts, and workers behave as expected. Then attempt a controlled resource from a host that the policy should reject.
Inline scripts need focused coverage. If the application uses nonces, confirm that each response creates an unpredictable value, applies it only to intended elements, and sends the matching value in the policy. A static nonce reused across responses defeats its purpose.
Test error and authentication routes too. Framework fallbacks or proxy-generated pages can carry a different header from the main application. Multiple CSP headers combine as additional restrictions, so inspect every header the browser receives rather than only application configuration.
Give a coding agent bounded CSP work
Specify the route, resource type, approved host, and current policy owner. Require a focused diff and browser evidence for both the intended resource and a blocked control. Reject blanket wildcards or unsafe inline execution unless an existing, documented policy explicitly requires them.
Factory’s Permission rules let teams define command boundaries for Droid. Keep browser tests in an isolated environment and restrict any local server commands to the known project workflow.
The task should preserve deployment headers outside its scope. A page-level fix must not silently change a global reverse-proxy policy.
Review CSP test evidence
Capture the final response headers, tested route, browser console result, and blocked-control outcome. Redact tokens and avoid saving authenticated response bodies. A clean console alone is insufficient because the test may not exercise the new resource.
Deploy report-only changes with a defined observation period when the application needs telemetry before enforcement. Review the reports for affected routes, remove obsolete allowances, then rerun the enforcing browser test.
Repeat this evidence check after proxy or content delivery configuration changes, even when application code stays unchanged.
