Opens in a new tabSkip to content
Agent LighthouseAgent Lighthouse

    Searches the text of every published page. The evidence sources themselves are not in this index — search all of them on the trusted sources page.

    GitHub ↗
    Browse checks and page contents
    agent-interfaces/cors-api-routes

    CORS on declared API routes

    What it checks

    CORS matters for one class of AI consumer: agent code running inside a browser origin, such as an MCP App or an OpenAI Apps SDK widget in an isolated iframe under a strict CSP. Server-side crawlers and MCP clients are not browsers and are unaffected. The audit reads the endpoints out of the published OpenAPI document, probes those, and applies only to sites that publish one.

    It probes at most two declared endpoints. Access-Control-Allow-Origin: * passes. A named origin, or no header at all, warns. The audit never fails, and a site with no usable /openapi.json is not applicable.

    A missing header does not block AI agents in general. Crawlers such as GPTBot and ClaudeBot, and server-side agent backends, do not enforce the same-origin policy, so they read the endpoint either way.

    Why it matters

    The claim under test: serving Access-Control-Allow-Origin (typically ‘*’) on llms.txt, .md mirrors, feeds and public JSON endpoints is required for AI agents to fetch and use them.

    Evidence

    CORS headers on public AI files and API routes

    The mechanism is real but its scope is much narrower than the audit implies. CORS matters only for code running inside a browser origin: MDN states ‘browsers restrict cross-origin HTTP requests initiated from scripts’, and the server merely opts in via ACAO. The genuine AI consumer class is browser-sandboxed agent code. OpenAI’s Apps SDK widgets run in an isolated iframe under a strict CSP, and must declare connect_domains — mapped to connect-src — for every origin they will fetch from. Such a widget fetching a publisher’s JSON or llms.txt cross-origin will be blocked without ACAO. That class is small today but growing.

    MCP Apps run in a sandboxed iframe, and the MCP Apps documentation states that an API answering Access-Control-Allow-Origin: * works without further configuration (apps.extensions.modelcontextprotocol.io/…/csp-and-c…, verified 2026-10-18). That covers apps whose author calls this API. No source documents an agent calling a site’s declared API from a browser on its own.

    Limits

    Decisive counter-evidence for the general case: GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot and every server-side agent backend are non-browser HTTP clients. MDN states that browsers restrict cross-origin requests from scripts; it is this project’s inference, not MDN’s statement, that these clients therefore do not implement the same-origin policy and are completely unaffected by a missing Access-Control-Allow-Origin header. Browser extensions with host permissions (the Claude-in-Chrome / sidebar class) also bypass CORS. No AI vendor doc requires CORS on publisher resources, and the llms.txt spec says nothing about it. Therefore ‘missing CORS blocks AI agents’ is false as a general claim. Recommend rewording the audit to target only browser-embedded agent consumption and demoting it out of the score.

    Sources