AI Coding Agents
Security
CORS checks for agent-generated web services
September 29, 2026 - 2 minute read
CORS testing verifies which browser origins may read a web service’s responses. A coding agent can make a local integration work by widening an origin rule, reflecting request headers, or enabling credentials. The change may solve the immediate error while exposing authenticated responses to an unintended site.
The Fetch Standard defines the CORS protocol and the response headers browsers evaluate. Test the browser-visible contract rather than treating CORS as a single server flag.
Build CORS tests from an origin policy
List each allowed scheme, host, and port. Origins that look similar are still distinct. https://app.example.com, http://app.example.com, and https://app.example.com:8443 must be evaluated independently.
Create fixtures for approved origins, an unrelated public origin, a sibling subdomain, null, and malformed values. If the service supports customer-configured origins, test normalization and exact matching. Suffix checks can accidentally accept a hostname controlled by someone else.
Decide which routes accept credentials and which request methods or headers require preflight. Public, unauthenticated resources may use a broader policy than account or administrative endpoints. Keep those policies separate in both configuration and tests.
Exercise preflight and actual requests
Send an OPTIONS preflight with the intended method and non-simple headers. Verify the allowed origin, methods, headers, credential setting, and cache duration. Then send the actual request. A passing preflight does not prove the response carries the right CORS headers.
Test denied origins the same way. The server may return an application response, but it must not grant browser access through Access-Control-Allow-Origin. Avoid assertions that depend only on status code because CORS enforcement happens in the browser.
Credentialed requests need a specific allowed origin. The Fetch Standard does not permit the wildcard origin with credentials. Confirm that origin reflection occurs only after an allowlist match and that the response varies by Origin when a cache can serve multiple callers.
Give a coding agent precise CORS acceptance criteria
Provide the approved origin matrix, protected routes, credential rules, and deployment environments. Include focused server tests and one browser-level test that proves JavaScript from an allowed origin can read the response while a denied origin cannot.
Factory’s Droid Exec runs non-interactive tasks in CI. Teams can use it to execute the repository’s CORS checks against an isolated service and return the same evidence reviewers expect locally.
Do not give an agent production session cookies for this test. Use synthetic accounts and an isolated origin so failure cannot expose real data.
Review CORS test evidence
Record the request origin, route, credential mode, preflight result, and readable response outcome. Inspect redirects too, especially when an API sends unauthenticated callers to a different host.
Keep CORS separate from server-side authorization. A command-line client ignores browser CORS rules, and an allowed browser origin still needs identity and permission checks. The suite should prove both controls without confusing one for the other.
Recheck the matrix whenever a new application host, proxy, or credentialed route joins the service boundary.
