Will It Vibe?No CORS configuration for a public JSON API
Part of Architecture & Best Practices, which counts for 15% of the overall score. When this check fires it deducts 4 points from that category, once per scan, no matter how many places it turns up.
What it detects
The app registers a real /api/ route surface but nothing in the repo configures CORS: no cors-family dependency and no Access-Control-Allow-Origin header anywhere. Browsers enforce the same-origin policy by default, so any browser-based client on another origin will have its requests to this API blocked. This is a heuristic: a same-origin-only or server-to-server API does not need CORS at all, so treat this as a prompt to confirm the intent rather than a defect.
Why it matters
An API with a real /api/ surface and no CORS configuration anywhere cannot be called directly from a browser-based client on another origin: the browser blocks the response under the default same-origin policy before your JavaScript ever sees it. If a web frontend, a partner integration, or your own dashboard hosted on a different domain is supposed to call this API, that integration will fail with a CORS error the first time someone tries it from a browser, even though a server-to-server call or a mobile app would work fine.
How to fix it
If the API is meant to be called from browser-based clients on other origins, add the cors middleware (or your framework equivalent) and configure an explicit allow-list of trusted origins rather than a wildcard. If the API is intentionally same-origin or server-to-server only, no change is needed; just confirm that is the actual intent.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo