Will It Vibe?CORS policy combines AllowAnyOrigin() with AllowCredentials()
Part of Security, which counts for 30% of the overall score. When this check fires it deducts 15 points from that category, once per scan, no matter how many places it turns up.
What it detects
A CORS builder chain calls both AllowAnyOrigin() and AllowCredentials(). Browsers reject this combination for the credentialed case, but the same builder pattern (or an older client) can still end up sending credentials to any origin, and the config itself suggests a misunderstanding of CORS that often ships with other over-broad settings.
Why it matters
AllowAnyOrigin() combined with AllowCredentials() asks ASP.NET Core CORS to accept credentialed requests (cookies, Authorization headers) from literally any origin. Modern browsers refuse to honor this exact combination and the framework itself throws at startup in many configurations, but the presence of this pattern points to a CORS policy that was configured without understanding the credentials implications, and equivalent misconfigurations (a wildcard reflected as the specific origin, an older client, a custom CORS middleware) can still let any website make authenticated requests as your users.
How to fix it
Replace AllowAnyOrigin() with an explicit WithOrigins(...) allow-list of the specific frontend origins that need credentialed access. If you truly need to allow arbitrary origins, drop AllowCredentials() and only serve non-credentialed, public responses to those requests.
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