{"id":49957,"date":"2026-11-03T16:32:52","date_gmt":"2026-11-03T11:02:52","guid":{"rendered":"https:\/\/www.getastra.com\/blog\/?p=49957"},"modified":"2026-11-03T19:02:38","modified_gmt":"2026-11-03T13:32:38","slug":"login-security-best-practices","status":"publish","type":"post","link":"https:\/\/www.getastra.com\/blog\/ai-security\/login-security-best-practices\/","title":{"rendered":"Login Security Best Practices for AI-Built Apps"},"content":{"rendered":"\n

\u201cBuild me a secure login with JWT authentication.\u201d 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.<\/p>\n\n\n\n

We picked apart the tossing.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Even though AI can write authentication code, \u201csecure\u201d is still a requirement you need to neatly define, very neatly.<\/p>\n\n\n\n

<\/span>What \u201csecure login\u201d leaves unsaid<\/strong><\/span><\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

\n\n\n\n\t\n\n\t\n\t\n\t\n\t\n\t
What you might ask for<\/th>What to specify instead<\/th>What we found<\/th>\n<\/tr>\n<\/thead>\n
Secure login<\/td>Rate limit every authentication endpoint and block repeated failures<\/td>Missing or weak rate limiting in all four apps (11 findings)<\/td>\n<\/tr>\n
Clear error messages<\/td>Return one identical message for unknown emails and wrong passwords<\/td>User enumeration in three apps (8 findings)<\/td>\n<\/tr>\n
JWT authentication<\/td>Expire access tokens in minutes, rotate refresh tokens, and revoke both on logout<\/td>JWT session and revocation issues in three apps (12 findings)<\/td>\n<\/tr>\n
Store the token safely<\/td>Use HttpOnly, Secure, and SameSite cookies, never localStorage<\/td>Insecure token or cookie storage in three apps (8 findings)<\/td>\n<\/tr>\n
Protect the API<\/td>Require authentication on every route by default and name the public routes<\/td>Missing or bypassed authentication in all four apps (17 findings)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n\n\n\n\n

Each row is a gap you can close by just adding a sentence to your prompt.<\/p>\n\n\n\n

<\/span>When an explicit instruction still fails<\/strong><\/span><\/h2>\n\n\n\n

A clear instruction doesn\u2019t guarantee a safe result. Our prompt required authentication on every endpoint by default. The Base44 app<\/a> still let an attacker forge admin invitations, delete audit logs, and change another user\u2019s password without logging in at all. That\u2019s broken authentication in its plainest form: the app promised protection on paper and delivered none in code.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

The lesson here is that asking for a control isn\u2019t the same as getting one.<\/p>\n\n\n\n

<\/span>Write the spec, then test it<\/strong><\/span><\/h2>\n\n\n\n

A good spec is boring and specific, but turns every rule into something you can check.<\/p>\n\n\n\n

That\u2019s the idea behind the corrected prompt in our report:<\/p>\n\n\n\n

    \n
  1. Ask for deny-by-default routes,<\/li>\n\n\n\n
  2. Ask for a test that calls every route without a session<\/li>\n\n\n\n
  3. Verify the result yourself with three quick authentication best practices checks:<\/li>\n<\/ol>\n\n\n\n