A Secure Login Doesn’t Mean a Secure Application

Picture this. You log into your online banking account, and you notice something odd in the address bar: a number. Out of curiosity, you change it, and suddenly you're looking at another customer's transactions. Your password was correct. The site accepted your login. And someone else's private data is right there in front of you.

That's Broken Access Control, and it happens when an application doesn't properly limit what users can see or do. Authentication checks who you are. Authorization decides what you're allowed to touch. Mix those two up, and sensitive information can leak even when the login system works perfectly.

What broken access control looks like

Most web apps have different kinds of users: customers, employees, administrators. Each group should have its own permissions. Customers can see their own invoices, while administrators might manage customer accounts.

Things go wrong when the app checks that you're logged in but never checks whether you're allowed to open the specific thing you asked for.

Here's an illustrative example. A customer on an online shop opens an invoice at example.com/invoice/1042. They change the number to 1043 and see someone else's invoice. If the server never verifies who owns that invoice, the app has just exposed private data.

This kind of flaw is often called an insecure direct object reference, or IDOR. The problem isn't that invoice numbers are easy to guess. The problem is that the app trusts whatever identifier it receives without asking whether this user should see it.

Why it matters

The consequences can include leaked data, tampered accounts, financial losses, and privacy violations. Depending on the app, an attacker might read personal records, change orders, or carry out admin actions they were never meant to have.

It's serious enough that OWASP still lists Broken Access Control as the first category in its Top 10:2025 for web application security risks (OWASP, 2025). Authentication alone isn't enough protection, and the ranking says as much.

To be clear, the invoice scenario above is hypothetical. It isn't about any specific company or documented incident. But it's a realistic failure. The same flaw in a healthcare portal could expose medical records, and in a financial app it could reveal transaction details.

How to reduce the risk

The most important rule is to do authorization checks on the server. Hiding an admin button or disabling a feature with JavaScript doesn't protect anything, because users can skip your interface and send requests straight to the server.

The OWASP Application Security Verification Standard (ASVS) backs this up. Its access control guidance stresses enforcing permissions in trusted server-side services and following the principle of least privilege, meaning people get only the access they need to do their jobs (OWASP, n.d.).

In practice, when a customer asks for an invoice, the server should confirm two things: that they're logged in, and that the invoice actually belongs to them (or is otherwise something they can access). That goes for every operation, whether it's viewing, editing, or deleting.

A few other habits help too. Deny access by default. Define permissions in one central place where you can. Keep security logs so suspicious access attempts get noticed. All of this cuts down on inconsistent checks scattered across different features.

None of it is a silver bullet, though. Centralized authorization can still have logic errors, and logs might spot suspicious behavior without stopping it. That's why you have to keep testing.

How to check that your controls actually work

Turn your authorization rules into explicit tests you can run again and again.

Set up test accounts. Create accounts with different permissions, like two ordinary customers and one administrator, and give each customer their own test records.

Test the boundaries between users. Check that Customer A can view and edit their own records but can't touch Customer B's. Try different record IDs and the relevant API operations. Unauthorized requests should be denied without leaking anything protected.

Test the boundaries between roles. An ordinary customer shouldn't be able to reach admin functions, even by sending requests directly to the server instead of clicking through the website.

Automate it. Make these checks part of your development pipeline so they run again whenever someone adds a feature or changes permissions. OWASP's Authorization Testing Automation Cheat Sheet recommends this because changes can quietly introduce permission gaps (OWASP, n.d.).

Do periodic assessments. Use the OWASP Web Security Testing Guide for regular reviews. Automated tests give you consistency, while manual testing is better at catching overlooked business rules and odd combinations of permissions.

This takes development time and upkeep. But if you focus on the most sensitive operations first and automate the common permission checks, it becomes much more manageable.

Final thoughts

A successful login only proves the app recognized you. It doesn't prove that everything you do afterward is allowed. Broken Access Control shows how one small oversight can undermine an otherwise working application.

I think organizations should treat authorization as a core security requirement, not an extra feature. Enforce permissions on the server, define clear access rules, and keep verifying them with both automated and manual testing. A trustworthy application isn't one that just recognizes its users. It's one that consistently protects what each user is allowed to access.

References

OWASP Foundation. (2025). A01:2025 — Broken Access Control. https://top10.owasp.org/2025/A01_2025-Broken_Access_Control/
OWASP Foundation. (n.d.). Application Security Verification Standard (ASVS). https://owasp.org/www-project-application-security-verification-standard/
OWASP Foundation. (n.d.). Authorization Testing Automation Cheat Sheet. https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Testing_Automation_Cheat_Sheet.html
OWASP Foundation. (n.d.). Web Security Testing Guide: Authorization Testing. https://owasp.org/www-project-web-security-testing-guide/