Permissive CORS Headers on Public Resources So Browser-Based AI Agents Can Reach Them
Without permissive CORS, in-browser AI assistants like ChatGPT and Claude apps cannot fetch your public data at all.
What this signal tests
We check whether the public, agent-relevant resources on your site - openapi.json, /api/* endpoints, /products.json, sitemaps, and /.well-known/* documents - return a permissive Access-Control-Allow-Origin (CORS) header. CORS is a browser security rule that blocks cross-origin requests by default; AI agents running inside a browser need explicit permission to fetch your data.
Why it matters for your visibility in AI
A whole class of AI assistants - ChatGPT.com's browser tools, Claude.ai apps, Edge Copilot, in-browser MCP clients - run inside the user's web browser. They are subject to the browser's same-origin policy, which silently blocks any cross-origin fetch your server does not explicitly allow. From the agent's point of view, your endpoint simply does not respond. The consequence is invisible from your side: your server logs show no failed requests, because the browser cancels them before they leave the user's machine. But the agent quietly skips your site and recommends a competitor whose CORS headers let it through. Setting CORS correctly on truly public resources is a one-line change per endpoint that closes off this silent dropout entirely.
Pass criteria at a glance
| Criterion | Passes when |
|---|---|
| All public agent-relevant endpoints return permissive CORS. |
How we test it
Our scanner sends an OPTIONS preflight request to each public, agent-relevant endpoint with an Origin header set to a synthetic agent domain. It passes the endpoint if the response includes Access-Control-Allow-Origin set to * or echoing back the origin, and Access-Control-Allow-Methods includes GET. Every public endpoint in the scan set must satisfy this for the signal to pass overall.
Show technical detection method
OPTIONS preflight with Origin: https://example-agent.test; pass if Access-Control-Allow-Origin is * or echoes origin AND Allow-Methods includes GET.
If your site fails: how to fix it
- List the resources on your site that should be reachable from any browser-based agent: OpenAPI documents, public catalogs, sitemaps, /.well-known/* files, and read-only public API endpoints.
- On each of those resources, configure the response to include Access-Control-Allow-Origin: * - the wildcard is the right answer for genuinely public data and is widely understood by every agent framework.
- For endpoints that require authentication or cookies, do not use the wildcard; instead allow a specific origin allowlist combined with Access-Control-Allow-Credentials: true, which the work is best done by a developer familiar with the CORS specification.
- Make sure Access-Control-Allow-Methods includes at least GET and OPTIONS for read endpoints, and POST where the endpoint accepts submissions like quote requests or webhooks.
- Test the change from a real cross-origin browser context, not just with curl, because some misconfigurations only surface when a real browser enforces the preflight.
Quick facts
| Maturity | ESTABLISHED |
|---|---|
| Weight | high |
| Category | Agent Actions |
Primary sources
Related signals
Frequently asked questions
Is opening CORS a security risk?
Not for genuinely public data. CORS controls only browser fetches; an attacker with curl can read public endpoints regardless. CORS becomes risky only when combined with credentials - for credentialed endpoints, use a strict origin allowlist rather than the wildcard.
How do I know if my customers' AI agents will visit my site?
If your customers use ChatGPT.com, Claude.ai, or Edge Copilot, they are already using browser-resident agents. Those agents follow the same CORS rules as any web page. Endpoints with restrictive CORS are simply invisible to that traffic, which means lost discovery.
Does this cost anything to implement?
Setting CORS headers is configuration - usually one line in your web server, CDN, or framework. There are no licensing fees and no performance impact. The cost is purely engineering time to identify which endpoints should be public and apply the headers.
What about endpoints I want to keep private?
Do not set permissive CORS on private endpoints. The signal only requires permissive CORS on public, agent-relevant resources. Internal APIs, admin endpoints, and authenticated user routes should continue to use restrictive CORS or none at all.
Run your own scan
Run a free scan and see how your site grades across all 155 AI-readiness signals.