Security Guides
Added a login and called it secure? — authentication vs authorization
Authentication (who) vs authorization (what you may do): a login without owner-scoped data means 'logged in = sees all data.' Why it happens and how to defend.
"I added a login, so it's protected now" — that's a dangerous assumption. Login (authentication) and permissions (authorization) are different things, and mixing them up leads to an incident where everyone who logs in can see all the data, including other people's. No attack steps here — just how it happens and how to defend.
Authentication and authorization are different
They're easily conflated, but their roles are completely different.
Authentication only (the common mistake)
- thinking "can log in = safe"
- treating post-login data reads as the same for everyone
- result: everyone who logs in reaches all the data
Authentication + authorization (how it should be)
- authentication confirms "who"
- authorization limits to "only the data they may touch"
- data reads are always scoped to the owner
Authentication is "the ID check at the entrance"; authorization is "controlling which rooms you may enter." A login only guarantees the former. "Who may touch which data" is something you have to write separately.
How "sees all data" happens in real apps
In the field, the same hole turns up repeatedly across independent, self-built systems. A personal task/note app, or a small product/order-management system (with external API integrations) — the cause was the same overlap of two flaws.
① Registration is open (and on two routes)
Auth scaffolds (things like Laravel's Breeze/Jetstream) often ship with the registration page public by default. And when the registration route is duplicated across the UI library and the auth package, closing one still leaves /register. A stranger who knows the URL can sign up.
② Authentication exists but authorization doesn't (missing owner scope)
The data table has no owner column (user_id), or the list/read/update/delete queries aren't narrowed to the current user. Then "logged in = access to all data." If the app auto-logs-in right after sign-up, a stranger lands on someone else's data list the moment they register.
Result: the authn ≠ authz incident
The entrance (login) is there, but the room keys (authorization) aren't. Because the stranger behaves as "a properly logged-in user," there's barely even a trace of unauthorized access.
The blast radius is larger the more business data is involved (customer records, orders, integration API keys can all be affected). And a different system built the same way probably has the same hole.
How to defend
Always scope data to the owner
Limit every read and write to "the logged-in user's own rows." Enforce the owner condition on all of read/update/delete via an ORM global scope or an authorization policy (policy/gate). If the table has no owner column, redesign that first.
Close registration you don't need — and suspect duplicated routes
Disable sign-up on personal/internal apps. Actually measure over HTTP that /register and the like return 404, and check both the UI-library and auth-package registration routes.
Defense-in-depth on admin surfaces
For internal/admin use, don't rely on authentication alone — layer IP restrictions, Basic auth, and the like. If one wall falls, the next one stops it.
Audit and access logs *before* an incident
Without "who, when, from which IP, did what," you can't reconstruct "what was seen" after the fact. At minimum, keep login success/failure audit logs and retain/rotate web access logs.
Detect new sign-ups and anomalies
The core lesson here is "it went unnoticed for a long time." Add ways to notice fast — notifications on new user registration, periodic user/data stock-takes. With no detection, the hole stays quietly open.
This site's view: a library only guarantees 'who'
An auth library takes care of "who" — no further. "What that person may do" doesn't exist unless you, the designer, write it. And — a structural flaw found in one system is probably in other systems built the same way. Don't fix one and stop; audit the same-shape builds across the board. When you can't tell whether something was read, the correct posture is to treat it as read and revoke/rotate any exposed secrets.
Read next
- Glossary: what IDOR (broken access control) is (the classic: pass someone else's ID and reach their data)
- Apply it: security by framework (where to write authorization in each framework)
- Related: keep secrets out of public directories (checking token/credentials/.env exposure)
- Basics: protecting secrets, from scratch / foundation: the minimum security checklist
Sources
- OWASP Top 10 (2021) A01: Broken Access Control: owasp.org
- OWASP Authorization Cheat Sheet: cheatsheetseries.owasp.org
FAQ
QHow are authentication and authorization different?
Authentication verifies who you are (login). Authorization decides what you may do (permissions). As an analogy, authentication is the ID check at the building entrance; authorization controls which rooms you may enter. Adding a login only implements authentication — authorization (who may touch which data) is something you must write separately. Conflate the two and you end up with 'everyone who logs in can see all the data.'
QThere's a login — so why can everyone see all the data?
Because the data query isn't narrowed to 'just the logged-in user's own rows.' Forget the owner (user_id) condition on any of list/read/update/delete, and once someone is logged in, all rows come back — including other people's. It's a design hole independent of whether authentication exists, and it's the classic Broken Access Control that OWASP ranks number one.
QFor a personal tool or internal app, isn't leaving registration open fine?
It's dangerous. Many auth scaffolds ship with registration (e.g. /register) public by default. If a stranger knows the URL they can sign up, and with no authorization they land straight on the data inside. Registration routes are sometimes duplicated (both the UI library and the auth package), so closing one doesn't close it. Disable registration you don't need, and layer defenses like IP restrictions on admin surfaces.