Picture a normal sprint. A developer asks an AI assistant for a login endpoint with JWT support. Thirty seconds later the code compiles, the tests pass, and the pull request gets merged before lunch. Nobody stops to ask the uncomfortable question: does this code actually verify the token, or does it just read it?
That scenario plays out in engineering teams every day. AI coding assistants have made developers dramatically faster, but speed and safety are not the same thing. And when it comes to AI-generated code security, authentication is where small mistakes turn into open doors.
What the research says about AI-generated code
This is not a hunch. In its 2025 GenAI Code Security Report, Veracode tested more than 100 large language models on 80 coding tasks. In 45% of cases, the models produced code containing vulnerabilities from the OWASP Top 10. Java was the worst performer, with a failure rate above 70%.
The human side is just as telling. A Stanford University study found that developers using an AI assistant wrote noticeably less secure code than those working without one, yet they were more likely to believe their code was secure. That gap between confidence and reality is exactly where authentication bugs hide.
Real incidents: when authentication was the weak spot
Two widely reported cases from 2025 show how quickly things go wrong when code works but nobody checks who it lets in.
Base44. In July 2025, researchers at Wiz found a flaw in Base44, a popular AI app-building platform owned by Wix. Two undocumented registration and verification endpoints required no authentication. Anyone with an app's public ID could create a verified account on a private application, bypassing protections including single sign-on. Wix patched it within 24 hours and found no evidence of abuse, but the lesson stands: the feature worked perfectly, and the access check simply was not there.
Lovable (CVE-2025-48757). A researcher scanned 1,645 apps built with the Lovable platform and found 170 of them with missing Row Level Security on their Supabase databases. With only the public key that ships in every browser, anyone could read or write those tables, exposing emails, home addresses and even API keys. The CVE entry is a useful read for any team building on similar stacks.
Neither case involved a sophisticated attacker. Both came down to a basic question that the generated code never answered: who is allowed to do this?
Five authentication flaws AI assistants keep producing
If your team uses AI assistants, these are the patterns worth watching for in code review:
-
Decoding tokens instead of verifying them. A JWT can be read by anyone. If the code calls a decode function without checking the signature, an attacker can forge a token and become any user.
-
No rate limiting on login or OTP endpoints. Generated endpoints rarely include lockouts or throttling, which leaves the door open to brute force and credential stuffing.
-
Outdated password storage. Models learn from years of public code, including plenty that hashes passwords with MD5 or SHA-1. Modern code should use bcrypt, scrypt or Argon2.
-
Hardcoded secrets. A signing key set to "secret" or an API key pasted into a config file is a common shortcut in examples, and it ends up in production more often than anyone admits.
-
Sessions that never really end. Tokens that stay valid after logout or a password reset, or that live for weeks, give stolen credentials a long shelf life.
Here is the first flaw in practice. Both versions run without errors, which is why it slips through review:
// Insecure: reads the token but never checks the signature
const user = jwt.decode(req.headers.authorization);
// Secure: verifies signature, algorithm and expiry
const user = jwt.verify(token, process.env.JWT_SECRET, {
algorithms: ['HS256']
});
How to fix it without slowing your team down
Banning AI tools is not realistic, and it is not necessary. What works is changing how developers treat the output.
-
Review AI code like a junior developer's pull request. It is often correct, sometimes clever, and occasionally dangerous. Authentication and authorization logic deserve a second look every time.
-
Put security requirements in the prompt. The Stanford researchers noticed that participants who questioned the AI more and refined their prompts produced fewer vulnerabilities. Asking explicitly for signature verification, rate limiting and secure hashing changes the result.
-
Automate what you can. Static analysis and secret scanning in the CI pipeline catch hardcoded keys and known insecure functions before they merge.
-
Train the eye, not just the tools. Scanners miss logic flaws like the Base44 bypass. Developers need to recognise them, and the OWASP Authentication Cheat Sheet is a solid reference to build on.
Building the instinct through hands-on practice
Reading about a forged JWT is one thing. Forging one yourself, watching the API accept it, and then writing the fix is what makes the lesson stick. That is the gap most secure coding programs never close.
With Simulations Labs, security and engineering leaders can build hands-on labs and CTF challenges around the exact flaws covered here: broken JWT validation, missing rate limits, exposed endpoints and weak session handling. The Simulations Copilot helps you design challenges quickly, and built-in analytics show which developers have mastered which skills.
If you are planning a wider program, our guide on secure coding training for developers covers what actually works, and our deep dive on broken access control tackles the vulnerability that sits right next to authentication.
The bottom line
AI assistants are not going away, and they should not. But every line of generated authentication code is a decision about who gets in. Give your developers the practice to make that decision well. Start for free or watch the product demo to see how a secure coding lab comes together.
