{"slug": "cors-misconfiguration-was-the-1-mistake-in-every-app-we-tested", "title": "CORS Misconfiguration Was the #1 Mistake in Every App We Tested", "summary": "Astra Security found a CORS misconfiguration in all four AI-built applications it tested — Emergent, Replit, Lovable and Base44 — after giving each tool an identical prompt and running autonomous pentest agents against the results, which surfaced 137 confirmed vulnerabilities in total. The misconfigurations took the form of wildcard origins, reflected origins or loose subdomain matching, and become exploitable when an API also accepts cookies or auth headers, letting an attacker's page make authenticated requests and read the responses. Astra said every finding was reproduced by a validator agent and reviewed by a human security engineer before counting, and recommends explicitly defining allowed origins, credentials, methods and headers in AI coding prompts.", "body_md": "## Key Takeaways\n\n- The Security Risks with Vibe Coding: A study by Astra Security found CORS misconfiguration across all four AI-built applications tested.\n- Permissive CORS settings can let malicious websites read sensitive data from authenticated users.\n- Explicitly define allowed origins, credentials, methods, and headers in your AI coding prompts.\n- Astra’s autonomous pentesting helps identify and validate security misconfigurations before attackers exploit them.\n\nWe gave four AI coding tools the same prompt and asked each one to build the same application. Emergent, Replit, Lovable, and Base44 all shipped something that ran, and none of them knew a pentest was coming. We then pointed our [autonomous pentest agents at all four builds, and 137 confirmed vulnerabilities](https://www.getastra.com/reports/vibe-coding-security-cost-study) came back.\n\nOne finding turned up in every app, which is a CORS misconfiguration. The builds looked fine from the outside, in the sense that they loaded, they logged users in, and they returned data on request. They were also telling browsers that other websites were welcome to read that data.\n\n## What is CORS, and what counts as a misconfiguration?\n\nBy default, your browser stops a script on one site from reading responses from another. That rule is the same-origin policy, and it is why a random page you open cannot quietly read your webmail in the next tab.\n\nCORS is how a server opts out of that rule for specific sites, by returning a header called [Access-Control-Allow-Origin](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin) that names who is allowed to read its responses. Used properly, it is how your frontend on `app.example.com` talks to your API on api[.]example[.]com.\n\nA misconfiguration is when permission is handed out too widely, and it usually takes one of three forms. The first is a wildcard, where `Access-Control-Allow-Origin: *` tells the browser that every site on the internet qualifies.\n\nThe second is a reflected origin, where the server reads whatever Origin the request arrived with and echoes it back as approved, which is a wildcard with extra steps. The third is loose subdomain matching, where a regex meant to allow `*.example.com` can be satisfied by an attacker who registers something like `notexample[.]com`.\n\nAny of these becomes dangerous once credentials are in play. If your API accepts cookies or auth headers and also tells the browser that the requesting origin is approved, you have handed an attacker’s page the ability to make authenticated requests as your logged-in user and read whatever comes back.\n\nOWASP files this under [security misconfiguration](https://owasp.org/API-Security/editions/2023/en/0xa8-security-misconfiguration/) in its API Top 10, which is roughly where it belongs, since it is a setting rather than a bug.\n\n```\n# Bad\nAccess-Control-Allow-Origin: *\nAccess-Control-Allow-Credentials: true\n\n# Good\nAccess-Control-Allow-Origin: https://app.example.com\nAccess-Control-Allow-Credentials: true\n```\n\n## What we found across the four apps\n\nAll four tools received an identical prompt, with no advance notice, no vendor relationship, and no hint that anyone would be testing the output. Each of them built a working application, which is the part that makes this worth writing about. Nobody shipped something broken, and nobody would have caught this by using the app.\n\nEvery finding went through the same pipeline before it counted. Two autonomous pentest agents worked the apps independently, one mapping the application and building attack chains, the other going in cold the way an unbriefed attacker would.\n\nA validator agent then tried to reproduce every finding from scratch, and a human security engineer reviewed what survived, so anything nobody could reproduce was cut before analysis. 137 findings made it through that process.\n\nWhat makes this the most common finding in the study is that nobody wrote bad code to produce it. CORS is a configuration default, and the permissive setting is the one that makes development errors disappear fastest. Our prompt asked for a working API, said nothing about an origin allowlist, and so none of the four tools wrote one.\n\n## What an attacker does with it\n\nThe attack is quieter than it sounds, which is part of why it ships. Your user is logged into your app in one tab, and in another tab they open a page the attacker controls, reached from an email, a comment, or an ad. Nothing about that page looks unusual to them.\n\nThat page makes a request to your API in the background. Because the user has an active session, the browser attaches their cookies automatically. Your server checks the origin, decides it is allowed, and responds. The attacker’s script reads the response and sends it wherever it likes, with nothing brute-forced and no password changing hands, because the browser did exactly what your server told it was acceptable.\n\nHow bad this gets depends on what those endpoints return. Chained with [broken access control](https://www.getastra.com/blog/api-security/broken-object-level-authorization-bola/), which was consistently the most severe failure in this study whenever it appeared, it stops being a configuration issue and becomes account-level data exposure. That combination is why we rated it the way we did rather than filing it as a hygiene problem.\n\n## How to fix it\n\nList your origins explicitly and never pair a wildcard with credentials. If you need to support more than one frontend, check the incoming origin against a hardcoded list and echo it back only on a match, and skip the clever regex, since most subdomain bypasses start with one.\n\nLimit your allowed methods and headers to what the frontend uses, and treat Origin as a browser-supplied hint rather than authentication, because anything outside a browser can set it to whatever it wants. The same thinking applies across the rest of your endpoints, which we covered in more depth in our guide to [API security risks](https://www.getastra.com/blog/api-security/api-security-risks-and-how-to-mitigate-them/).\n\nIf you are building with an AI tool, the fix happens in the prompt. Asking it to “set up CORS securely” gets you nothing, because that is an adjective and the tool will read it as a feature request.\n\nTell it exactly what you want, which is to allow requests only from app.example.com, allow credentials, and reject everything else. Specific requirements separated the better builds from the worse ones across the whole study.\n\nThen check it yourself, which takes about thirty seconds. Send a request to your API with an Origin header you invented and look at what comes back in the response headers.\n\n`curl -I -H \"Origin: https://evil-test.example\" https://your-api.example.com/api/account`\n\nIf the response echoes that origin back in `Access-Control-Allow-Origin`, or returns `*` alongside `Access-Control-Allow-Credentials: true`, you have the finding. Run it against every endpoint that returns user data, not only the one you remember configuring. That is one check out of the ten-minute version in the report.\n\n## Final thoughts\n\nCORS is not an exotic vulnerability. It is a default that nobody changed, in four applications built by tools that did what they were asked to do. AI coding tools ship what you specify, and security tends to be the thing nobody specified.\n\nIf you want this run against a real application instead of a demo build, that is what [Astra’s autonomous pentest](https://www.getastra.com/autonomous-pentesting) does, using the validation pipeline described above. \n\nThe other eight weak points, the full findings, and the hardened prompt are all in the [free report](https://www.getastra.com/reports/vibe-coding-security-cost-study). There is also a ten-minute checklist in there for testing something you have already shipped.", "url": "https://wpnews.pro/news/cors-misconfiguration-was-the-1-mistake-in-every-app-we-tested", "canonical_source": "https://www.getastra.com/blog/security-audit/cors-misconfiguration/", "published_at": "2026-10-27 05:45:51+00:00", "updated_at": "2026-10-27 10:14:18.416663+00:00", "lang": "en", "topics": ["ai-safety", "ai-tools", "ai-products"], "entities": ["Astra Security", "Emergent", "Replit", "Lovable", "Base44", "OWASP"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/cors-misconfiguration-was-the-1-mistake-in-every-app-we-tested", "markdown": "https://wpnews.pro/news/cors-misconfiguration-was-the-1-mistake-in-every-app-we-tested.md", "text": "https://wpnews.pro/news/cors-misconfiguration-was-the-1-mistake-in-every-app-we-tested.txt", "jsonld": "https://wpnews.pro/news/cors-misconfiguration-was-the-1-mistake-in-every-app-we-tested.jsonld"}}