Logged In Is Not the Same as Allowed In

You log in to your bank's website and open a statement. The address bar ends in …/statements/1042. Out of curiosity, you change it to 1043. Should you see a stranger's bank statement?

Obviously not. Yet this is one of the most common security failures on the web.

The issue: being logged in is not the same as being allowed

A web application has to answer two different questions. Authentication asks who are you? That is the login screen. Authorization, or access control, asks are you allowed to see or do this?

Broken access control happens when an application answers the first question but forgets the second. It checks that you are logged in, but not whether record 1043 belongs to you. It mainly affects web applications. OWASP, a non-profit security community, ranks it the number one web application risk in its 2025 Top 10. In OWASP's data, every application tested had some form of it [1].

Why it matters: 885 million documents, one digit apart

A documented incident. In May 2019, security journalist Brian Krebs reported that First American Financial, a major U.S. title-insurance company, had left about 885 million mortgage-related documents open on its website. Anyone with one valid document link could change a single digit in the address and open someone else's file. The files included Social Security numbers, bank statements and driver's license images [3]. In 2021, the U.S. Securities and Exchange Commission found that the company's security staff had spotted the problem months earlier but never fixed or escalated it. The company paid a penalty of $487,616 [4].

A hypothetical example. Imagine a university portal where you download your transcript from …/transcript?id=12345. If the server only checks that you are a logged-in student, a classmate could read everyone's grades by counting upward.

For users, this means identity theft and fraud; for organizations, fines and lost trust, all from one missing check.

Which controls reduce the risk?

The OWASP Top 10 tells us what tends to go wrong. OWASP's Application Security Verification Standard (ASVS) turns that into specific requirements a team can test [1][2]. Three controls matter most here:

Deny by default. Nothing is accessible unless a rule explicitly allows it [1].
Check ownership on the server, for every request. ASVS 5.0 requires that each data item is available only to users with explicit permission (requirement 8.2.2), enforced on the server rather than in code a user can change (8.3.1) [2]. Think of a hotel key card: getting into the building is not enough. It should open only your room.
Write the check once and reuse it. OWASP advises building access control in one place and using it everywhere [1]. Scattered copies are where one gets forgotten.

In my analysis, these fit the risk because the root cause is a missing question: is this yours? Making record numbers random and hard to guess helps a little, but a leaked link still works. Only the ownership check actually closes the hole.

How do we know the controls work?

A rule on paper proves nothing. The simplest method is a two-account test: create two users, Alice and Bob, and try to make Alice reach Bob's data.

The automated row matters most. The First American flaw was found and then left in place [4]; a failing test makes a missing check impossible to ignore. In my view, automated scanners are weak here because they cannot know who owns which record.

My judgment

Access control should be treated as a feature with its own acceptance tests, not as something we hope is there. My recommendation is simple: no page or API that returns personal data should be released without a passing two-account test. Developers should write these tests, and security or QA teams should check that every sensitive endpoint has one.

This has trade-offs. Writing tests for every endpoint takes time, and apps with many roles (student, lecturer, admin) multiply the combinations. Start with the most sensitive endpoints. Tests only prove what they cover, so occasional manual testing still matters. And as First American shows, finding a flaw is not enough: someone must own fixing it.

A login screen proves who you are. Only access control decides what you get to see.

References

OWASP. (2025). OWASP Top 10:2025, A01 Broken Access Control. top10.owasp.org
1. OWASP. (2025). Application Security Verification Standard 5.0.0, V8 Authorization. github.com/OWASP/ASVS
1. Krebs, B. (2019, May 24). First American Financial Corp. Leaked Hundreds of Millions of Title Insurance Records (republished by Security Boulevard). securityboulevard.com
1. FOX 29. (2021, June 15). SEC charges mortgage title issuer First American with cybersecurity vulnerability violation. fox29.com