Analyzing secure vibe coding prompts is crucial as AI adoption grows. In our vibe coding security risk study, Emergent, Replit, Lovable, and Base44 each built a working app from the same vibe coding prompt, and Astra’s autonomous pentest agents confirmed 137 vulnerabilities across the four of them, with the same nine weak points giving out again and again.
If these tools build what you ask for, the obvious follow-up is what happens when you ask for something different. Section 9 of the report is that different ask: a hardened build prompt rewritten line by line against the findings. This post covers how the hardened version differs, which findings the study’s own data traces back to the prompt, and where vibe coding prompts stop helping you achieve secure vibe coding.
What the original prompt asked for #
The original prompt was not naive. It named real controls, including bcrypt hashing with a cost factor of at least 12, 15-minute access tokens, and parameterized queries only. When the prompt was that specific, the builds largely held, and SQL injection didn’t appear among the nine shared weak points.
Other lines stayed general, and those are the ones that gave out. “CORS enabled for mobile clients” says nothing about which origins to allow, and “rate limiting on auth endpoints” names a mechanism without a threshold. The report found that each of the five weak points in all four apps traces to a security requirement missing from the prompt or stated only in general terms.
The tools read those lines as feature requests and built the feature, which is why the report warns against assuming a platform knows what “secure login” means.
Writing secure vibe coding prompts: What we changed #
The rewrite followed one rule, which was to replace every adjective with a number or a named control. Vibe coding prompt engineering here came down to editing. A good vibe coding prompt template reads like a spec, and each line names something a tester can check.
Here are three vibe coding prompt examples, before and after, condensed from the report.
-
Before: CORS enabled for mobile clients.
-
After: Accept requests only from an explicit allowlist of origins. Never reflect the request Origin header, and never combine a wildcard with credentials.
-
Before: Rate limiting on auth endpoints.
-
After: Max 5 failed login attempts per account per 15 minutes, 10 per IP per hour. Return HTTP 429 with a Retry-After header.
-
Before: (nothing about a default)
-
After: Every endpoint requires an authenticated session by default. Public endpoints are a named list. Write a test that calls every other route and expects a 401.
Each “after” line gives the tool something to build and gives you something to test.
What the hardened prompt closes #
The five universal weak points account for 66 of the 137 confirmed findings, with CORS misconfiguration alone the most common category in the dataset at 16 confirmed instances. The report classifies all five as low-complexity, config-level fixes with a single root cause: a prompt that under-specified a known control, and calls a more specific prompt a direct fix.
Count the severity before counting the findings, though. Those 66 sit mostly at Medium and Low. All 13 Critical findings in the study cluster in authentication and authorisation on a single app, and most of the 14 High findings are broken access control. The hardened prompt closes the broadest category of findings, while the most severe category lives elsewhere.
What a better prompt can’t fix #
The other four weak points, i.e., the 39 confirmed findings across JWT session handling, broken access control, token storage, and user enumeration, each appeared in three of the four apps and come from platform implementation choices. Some of their fixes reach into the data layer or the token lifecycle, where one prompt line no longer maps to one setting.
Access control makes the limit concrete. The original prompt spelled out a four-tier role model with per-endpoint scopes, and one app still shipped admin actions reachable without any login. As the report puts it, “an explicit instruction was not the same as an enforced one.”
You also can’t prompt your way to knowing whether the prompt worked, because the only check is to test the running app. A rough version takes ten minutes.
Log in eight times with the wrong password and confirm a 429 appears around attempt six; check any response in DevTools for a Content-Security-Policy header; then reset a password with a fake email and a real one and confirm the response, wording, and timing match either way.
Final thoughts #
Vibe coding tools build what you ask for and miss what you forgot to ask. Writing your vibe coding prompts like a spec is a cheap fix that closes real ground, since nearly half the confirmed findings in the study trace back to under-specified prompt lines, and it is where secure vibe coding starts. The full report ships the hardened prompt in Section 9, ready to paste before your first feature request.
For everything a prompt can’t reach, Astra’s autonomous pentest tests the running app the way an attacker would. The numbers behind every pattern are in the full Vibe Coding Security Risks Study.