# Login Security Best Practices for AI-Built Apps > Source: > Published: 2026-11-03 11:02:52+00:00 “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](https://app.base44.com/) 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: 1. Ask for deny-by-default routes, 2. Ask for a test that calls every route without a session 3. 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](https://www.getastra.com/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](https://www.getastra.com/reports/vibe-coding-security-risks-study) covers each of these authentication best practices.