We security audit applications for a living, and lately a lot of them arrive the same way: built quickly with AI tools, working perfectly in the demo, and wide open underneath. The login page is where it shows first.
AI coding tools are genuinely good at producing a login page that works. Email field, password field, a session that persists, redirect to the dashboard. Ship it. The problem is that "works" and "secure" are different finish lines, and the model was only ever racing to the first one.
Here are the five holes we find again and again in AI-built authentication, why each one matters, and how to check your own app for them.
1. No rate limiting on login attempts
Ask an AI for a login endpoint and you will almost never get one that limits attempts. That means an attacker can throw thousands of password guesses per minute at your users' accounts, and nothing stops them. This is called brute forcing, and against an unprotected endpoint it is not clever hacking, it is a for-loop.
Check: try logging into your own app with the wrong password 25 times in a row. If nothing slows you down, locks the account, or challenges you, you have this hole.
2. No email verification on signup
Without verification, anyone can register with any address, including addresses that belong to other people. You end up with fake accounts, spam signups, and in the worst case a stranger holding an account tied to a real customer's email before that customer ever registers.
Check: sign up with a made-up address. If the account is fully active without you ever clicking a confirmation link, that is the hole.
3. Weak or missing password hashing
This is the one that turns a breach into a catastrophe. We have reviewed AI-generated code that stored passwords in plain text, and plenty more that used MD5 or SHA-1, which were broken for password storage years ago. If your database ever leaks, every one of those passwords is readable, and your users reuse them everywhere.
The correct answer is a slow, salted algorithm built for the job: bcrypt, scrypt or Argon2. Frameworks like Django do this properly by default, which is one of the reasons we build our backends on it.
Check: look at the users table in your database. If you can read anything that resembles the actual password, stop and fix it today.
4. No real session management
AI-built apps often mint a token at login and then never think about it again. Tokens that never expire, no rotation, no way to log a device out remotely. If one token leaks, whoever holds it has permanent access, and neither you nor the user can revoke it.
Check: log in, then change your password from another browser. If the first session still works afterwards, your sessions are not being managed.
5. No input sanitisation
The login form is still a form, and everything typed into it reaches your code. Without proper parameterised queries you are open to SQL injection, where a crafted "email address" reads your database instead of matching against it. Without output encoding you are open to XSS on the same form. Both featured in the OWASP Top 10 long before AI tools existed, and both keep appearing in generated code.
Check: this one genuinely needs a professional. Injection testing done wrong against a live system can damage data. It is a core part of every audit we run.
What a proper implementation actually looks like
For contrast, here is what authentication looks like when it is engineered rather than generated. None of this is exotic. It is just the checklist that never makes it into a prompt.
- Rate limiting at two levels: per account and per IP address, with increasing delays after repeated failures. Five wrong passwords should feel very different from five hundred.
- Verified email before an active account: a signed, expiring confirmation link, and a resend flow that does not reveal whether an address is already registered.
- Argon2 or bcrypt for storage: with a work factor tuned so that hashing is deliberately slow. Slow for you at login is slow for an attacker times a billion guesses.
- Sessions with a lifecycle: expiry, rotation on privilege change, revocation when the password changes, and a way for a user to see and end their other sessions.
- Parameterised queries everywhere: not just on the login form. The form is where attackers try first, not where they stop.
- Sensible failure messages: "wrong email or password", never "wrong password", because the second one confirms the email exists and hands an attacker half the answer.
- Logging that notices: failed attempts recorded and alerting on patterns, so a slow, patient attack shows up in week one rather than in the breach report.
A framework with strong defaults gets you a surprising amount of this for free, which is exactly why default-heavy tools beat hand-rolled cleverness for anything that touches accounts and money.
Why this keeps happening
None of this is the model being stupid. It is the model doing exactly what was asked: make a login page. Security is what nobody asked for, and it does not show up in a demo. It shows up eighteen months later in an incident email.
That is also why every application we build at Eclypso goes through in-house penetration testing before delivery, aligned with the OWASP Top 10 and the Web Security Testing Guide. Not a scanner run. A person whose whole job is breaking what we just built, before anyone else can. You can read about where that sits in our development process.
If you have an AI-built app right now
Run the four checks above that you can do yourself. If any of them fail, or if the app handles payments, personal data or anything you would not want leaked, get it audited before it grows any bigger. We do this for applications we did not build, and finding the holes now is a far cheaper conversation than the one after a breach.