Authentication is how your app answers one question: are you really who you say you are? It is the front door. When it is weak, an attacker does not need to be clever, because they can simply walk in as one of your users, or as an administrator. This post explains, without the jargon, what authentication actually is, the handful of mistakes that cause most of the trouble, and why apps built quickly tend to get them wrong.
Authentication is not the same as access control
These two get mixed up constantly, so it is worth separating them. Authentication is about proving who you are, usually with a password, a code, or a login link. Access control is about what you are allowed to do once you are in. A strong login with weak access control still lets an ordinary user reach data that is not theirs. Weak login undermines everything, because if an attacker can become a user, the access rules no longer protect anyone. You need both, and this post is about the first one.
The mistakes that let attackers in
Most real-world authentication failures come from a short, familiar list.
- No limit on login attempts. If someone can try passwords thousands of times without being slowed down or locked out, they will. Attackers use lists of passwords leaked from other breaches and simply replay them against your login. Rate limiting and lockouts are what stop this.
- No second factor on the accounts that matter. A password alone is one leak away from being useless. Offering, and for admin accounts requiring, a second step such as an authenticator app dramatically raises the cost of breaking in.
- A password reset flow that leaks or can be guessed. The reset process is a second front door, and it is often weaker than the first. Reset links that never expire, codes that are short and unlimited, or a flow that reveals whether an email address has an account are all common and all exploitable.
- Sessions that never really end. Once you are logged in, your app trusts a token. If that token lives forever, is not invalidated on logout or password change, or travels somewhere it can be read, then stealing it is as good as stealing the password. Session cookies also need the right flags so a browser will not hand them over carelessly.
- The login quietly tells attackers who is real. If a wrong password and a non-existent account produce different messages or response times, an attacker can map out exactly which email addresses are worth targeting before they even start guessing passwords.
- Default or hardcoded credentials. A leftover admin account with a known password, or a login baked into the code, is a skeleton key. This overlaps with a wider problem we have written about separately: secrets and keys left in the wrong place.
Why apps built quickly get this wrong
None of these mistakes come from carelessness. They come from the fact that a login form is easy to build and a safe login system is not. When you scaffold an app with an AI assistant or a starter template, you get a working sign-in in minutes. What you do not get is rate limiting, a hardened reset flow, sensible session expiry, or a second factor, because those are decisions someone has to make on purpose. The result looks finished and behaves finished, which is exactly why the gaps go unnoticed. If your app was assembled this way, our Supabase security checklist and our pre-launch checklist are good companions to this post.
What you can and cannot check from the outside
Some pieces of this are visible from the public internet. A quick Surface Check can tell you whether your session cookies carry the right flags and whether your traffic is properly encrypted, and it takes about thirty seconds. But the parts that matter most here, such as whether your reset flow is safe, whether logins are rate limited, and whether sessions expire, live inside your application logic where a passive external scan cannot see them. That is the honest limit of any outside-in check, and it is exactly the gap we describe in what your Surface Score does and does not mean. If you want a fuller reference on getting authentication right, OWASP maintains a practical authentication cheat sheet.
Next steps
Start with the free Surface Check to clear the parts that are visible from outside, then look hard at the login logic an external tool cannot reach. If you want that done properly, our application security assessment reviews authentication alongside access control, data handling, and configuration, in the round rather than in isolation. We prepare the fixes and hand them to your team to review and deploy, or apply them directly where you have authorised us to do so in writing. You can get in touch through our website.