“Build me a secure login with JWT authentication.” sounds reasonable, and every AI coding platform will happily say yes, building something that looks and behaves like a login, but tosses out most login security best practices.
We picked apart the tossing.
We gave 4 AI coding platforms the same detailed, security-explicit prompt, and every app came back vulnerable. 5 requirements were missing or stated only in general terms, and those five failed in all 4 apps.
Even though AI can write authentication code, “secure” is still a requirement you need to neatly define, very neatly.
What “secure login” leaves unsaid #
Secure authentication is a stack of small decisions. When you leave a decision unstated, the model fills it with a default, and defaults favour a working demo over a hardened app.
| What you might ask for | What to specify instead | What we found |
|---|---|---|
| Secure login | Rate limit every authentication endpoint and block repeated failures | Missing or weak rate limiting in all four apps (11 findings) |
| Clear error messages | Return one identical message for unknown emails and wrong passwords | User enumeration in three apps (8 findings) |
| JWT authentication | Expire access tokens in minutes, rotate refresh tokens, and revoke both on logout | JWT session and revocation issues in three apps (12 findings) |
| Store the token safely | Use HttpOnly, Secure, and SameSite cookies, never localStorage | Insecure token or cookie storage in three apps (8 findings) |
| Protect the API | Require authentication on every route by default and name the public routes | Missing or bypassed authentication in all four apps (17 findings) |
Each row is a gap you can close by just adding a sentence to your prompt.
When an explicit instruction still fails #
A clear instruction doesn’t guarantee a safe result. Our prompt required authentication on every endpoint by default. The Base44 app still let an attacker forge admin invitations, delete audit logs, and change another user’s password without logging in at all. That’s broken authentication in its plainest form: the app promised protection on paper and delivered none in code.
Tokens told the same story. We asked for 15-minute access tokens and seven-day refresh tokens, yet the Base44 app also issued tokens that lasted 90 days.
The lesson here is that asking for a control isn’t the same as getting one.
Write the spec, then test it #
A good spec is boring and specific, but turns every rule into something you can check.
That’s the idea behind the corrected prompt in our report:
- Ask for deny-by-default routes,
- Ask for a test that calls every route without a session
- Verify the result yourself with three quick authentication best practices checks:
- Send eight wrong passwords. Attempts six through eight should return a 429 error.
- Log in with a fake email and a real one. Both should return the same message.
- Replay a token after logging out. The server should reject it.
Why one-time checks aren’t enough #
Login security best practices only help if they keep holding, and every new prompt can rewrite your authentication layer, so what stood guard last week may open the gates today.
Autonomous pentesting closes that gap by attacking your login flows, access control, and session handling on a schedule instead of once.
It’s how we confirmed the findings above: autonomous agents attacked the running apps, a Validator agent re-ran each exploit, and a security engineer reviewed the results.
FAQs #
What are login security best practices?
Login security best practices include rate limiting authentication endpoints, returning identical errors for unknown emails and wrong passwords, using short-lived tokens you revoke on logout, and storing tokens in secure cookies.
What is broken authentication?
Broken authentication lets attackers bypass login, take over accounts, or reach protected actions without proper credentials. Common examples include unauthenticated endpoints, tokens that outlive logout, and missing rate limits.
How to test authentication in a vibe-coded app?
Call every endpoint without a session and expect a 401. Then try repeated wrong passwords, compare error messages for real and fake emails, and replay old tokens after logout. Our report’s checklist covers each of these authentication best practices.