User Authentication in Vibe-Coded Apps: The Most Dangerous Gap

Of all the problems in vibe-coded applications, authentication is the one that keeps me up at night. Not because it is the most common failure — database issues and missing error handling are more frequent. But because when authentication fails, the consequences are catastrophic. Unauthorised access to customer data, regulatory fines, legal liability, and the kind of breach headlines that destroy businesses.

AI tools will happily generate a login page. It looks professional. It works in the demo. And underneath that polished surface, the security architecture ranges from “incomplete” to “actively dangerous.”

Passwords Stored in Plain Text

This is the one that makes security professionals physically wince. And it happens more often than you would think.

When you tell an AI tool to “add user registration with email and password,” it generates a form that takes the password, sends it to the server, and stores it in the database. Sometimes it stores it as plain text — the exact characters the user typed, readable by anyone with database access.

If your database is compromised — through a SQL injection, a leaked backup, a misconfigured admin panel — every user’s password is immediately exposed. Not hashed. Not encrypted. Just sitting there in plain view, alongside the same password they probably use for their internet banking.

Proper password handling means hashing with a modern algorithm like bcrypt or Argon2, using unique salts per password, and never storing or logging the original. The application should make it mathematically infeasible to recover the original password, even if the database is fully compromised.

Tokens That Never Expire

JSON Web Tokens (JWTs) are the standard way modern web apps handle authentication. After login, the server issues a token the client includes with every request. It is a solid pattern — when implemented correctly.

AI-generated code consistently creates JWTs with no expiry, or with absurd durations like 365 days. Once a token is issued, it is valid effectively forever. If it is stolen — from a compromised browser, a leaked log file, or an insecure network — the attacker has permanent access.

Production implementations use short-lived access tokens (15 to 60 minutes) paired with longer-lived refresh tokens that can be revoked. When an employee leaves, when a user reports a suspicious login, you need to invalidate tokens immediately. Tokens that never expire cannot be invalidated.

No Session Management

Session management tracks who is logged in, from where, and controls how those sessions behave. In AI-generated code, it usually amounts to storing a token in the browser and checking if it exists.

What is missing: no way to see active sessions, no way to force a logout on all devices, no session timeout after inactivity, no limit on concurrent sessions. A user can be logged in on a hundred devices simultaneously with no mechanism to detect or prevent it.

For business applications, this matters. When an employee leaves, you need to revoke their access immediately. When a user reports a compromise, you need to kill all sessions instantly. None of this is possible without proper session management.

No Role-Based Access Control

In a demo, every user can see everything and do everything. In a real application, different users have different permissions. An admin creates users. A manager views reports. A customer sees only their own invoices.

AI-generated code rarely implements any access control beyond the login itself. Once authenticated, you have access to everything. The “admin” page is only hidden in the navigation — the actual route is unprotected and accessible to anyone who types the URL.

This is not a convenience problem. It is a data breach waiting to happen. A customer who discovers they can access the admin panel now has access to every other customer’s data.

Proper RBAC requires defining roles and permissions, enforcing them on the server side (not just hiding buttons), and checking permissions on every API request. Tedious, unglamorous work that makes the demo zero percent more impressive — and is absolutely essential.

No Brute Force Protection

What happens when someone submits a million login attempts with different passwords? In a vibe-coded app, each attempt is processed as if it is the first. No rate limiting. No account lockout. No CAPTCHA.

An attacker can run a dictionary attack — thousands of common passwords per minute — and your application will obligingly check each one. With no protections, even a strong password can be cracked given enough time.

Production systems implement progressive delays, temporary lockouts, IP-based rate limiting, and monitoring for credential-stuffing attacks. These are the bare minimum for any internet-facing login.

The Authentication Checklist

If your vibe-coded application has user authentication, here is the minimum to verify:

1. Password storage. Hashed with bcrypt, Argon2, or scrypt. Never plain text. Never MD5 or SHA-1.
2. Token lifecycle. Access tokens expire within an hour. Refresh tokens are stored securely and revocable.
3. Session management. Active sessions visible and manageable. Inactive sessions time out. Forced logout possible.
4. Access control. Permissions defined per role, enforced server-side on every request. Hiding a button is not access control.
5. Brute force protection. Rate limiting and account lockout on login endpoints.
6. HTTPS everywhere. All traffic encrypted. Secure flags on cookies. No exceptions.

Why This Is Non-Negotiable

Every other problem in a vibe-coded app costs you time and money. Authentication failures cost you your customers’ trust, your regulatory standing, and potentially your business.

The Australian Privacy Act requires reasonable steps to protect personal information. An authentication system with plain-text passwords and no access control does not meet that standard. If a breach occurs, “the AI built it” is not a defence.

Authentication is not the place to accept “good enough.” If your application handles any user data, this is the one area where professional implementation is not optional.