This article is part of our AI-Built Site Rescue hub. Want help applying it? Talk to eSEOspace.
Yes, one user can see another user's data if your app doesn't check ownership on the server or in the database. That flaw is called broken access control, and hiding a button does not fix it.
OWASP, a nonprofit that publishes a list of web app risks, ranks it first in its 2025 Top 10. This guide explains it in plain terms and shows how to check your own app. It is part of our AI-Built Site Rescue hub, and was checked against OWASP's and vendors' documentation on 9 November 2026.
The issue is unreviewed software, whoever wrote it. A person can make these mistakes as easily as an AI tool.
Key Takeaways
- Access control means users can't act outside their intended permissions.
- OWASP lists Broken Access Control as A01, the top entry in its 2025 Top 10.
- OWASP says access control only works in trusted server-side code or serverless APIs.
- Front-end checks can be skipped, because an attacker can call the address directly.
- In a database like Supabase, row-level security can do this job.
- Only test apps you own or have written permission to test. eSEOspace does not do penetration testing.
What access control means
Logging in answers one question: who are you? Access control answers another: what are you allowed to do?
OWASP's A01 page defines the term. "Access control enforces policy such that users cannot act outside of their intended permissions." It adds that failures can lead to unauthorized disclosure, modification or destruction of data.
An app can have a perfect login screen and still fail this. A logged-in customer might reach another customer's invoice just by changing a number in the address.
How it shows up
OWASP lists many forms. These are the ones a business owner can picture.
Changing an ID
OWASP describes "Permitting viewing or editing someone else's account by providing its unique identifier." Picture an address ending in /invoices/1042. If changing it to 1043 shows someone else's invoice, the server isn't checking ownership.
Hidden pages that aren't protected
OWASP calls this force browsing, meaning guessing URLs to reach pages you shouldn't. If a regular user can open an admin page by typing its address, that is a flaw.
Checks that live only in the browser
OWASP's third example describes an app with all its access control in the front end. The browser's code blocks the admin page, but an attacker can send a direct request from the command line.
This is the one to take seriously in generated apps. A page that hides a button has not protected the data behind it.
API actions with no checks
OWASP also lists this form. "An accessible API with missing access controls for POST, PUT, and DELETE." Those are the request types that create, change and delete records. Reading might be protected while deleting is not.
Trusting values the user can change
OWASP lists cookies or hidden fields manipulated to raise privileges. If your app reads role=admin from something the user controls, they can change it.
When the browser talks straight to the database
Some apps talk from the browser straight to a hosted database. In that design, the database rules do the protecting.
Supabase's row-level security guide is direct. "A table in an exposed schema without RLS is readable and writable by any role with a grant on it." RLS, or row-level security, is the database rule that limits each user to their own rows.
Its API keys guide says the publishable key is safe to expose, but only reaches what row-level security allows. So the visible key is fine only if the rules are right.
Supabase's Security Advisor gives this warning. "Anyone with your project URL can read, edit, and delete all data in this table because Row-Level Security is not enabled." We cover the details in row-level security explained.
Don't rely on one layer
Layers fail. In 2025, a flaw in Next.js showed why a single checkpoint is risky.
CVE-2025-29927, published 21 March 2025, said authorization checks could be bypassed in a Next.js app if the check occurred in middleware. Middleware is code that runs before a page loads.
It was fixed in versions 12.3.5, 13.5.9, 14.2.25 and 15.2.3. If you run Next.js, confirm you're on a fixed version.
The lesson is broader than one bug. Check permissions close to the data as well.
How to check your own app
You don't need attack tools for a first pass. You need two test accounts and a list.
Only do this on an app you own, or one whose owner has given you written permission. Don't try it on anyone else's site. Unauthorized testing can create legal exposure.
- Create two ordinary test users, A and B, and give each some records.
- Sign in as A and copy the address of one of A's records.
- Sign in as B and open that address. B should be refused.
- Repeat for edit and delete actions, not just viewing.
- Sign out completely and try the same addresses.
- Sign in as a non-admin and try your admin pages by address.
- If you use Supabase, open the Security Advisor and read every warning.
Write down what each kind of user should reach. Without that list, you can't tell a bug from a feature.
A clean result reduces risk, but it does not prove your app is safe. eSEOspace does not do penetration testing. If your app holds sensitive data, hire a qualified firm for that.
How to fix it
OWASP's prevention list gives the main principles.
| OWASP guidance | What it means for you |
|---|---|
| "Except for public resources, deny by default." | New pages and tables start closed |
| Enforce record ownership | Every query checks who owns the row |
| Implement access control once and reuse it | One shared check, not one per page |
| Log access control failures | You can see repeated refused attempts |
| Rate limit API access | Automated guessing gets slowed down |
| Include access control in tests | Regressions get caught before release |
The core rule is this OWASP sentence. "Access control is only effective when implemented in trusted server-side code or serverless APIs, where the attacker cannot modify the access control check or metadata."
In Supabase, that means row-level security policies on every exposed table. Supabase adds "On projects that still grant anon and authenticated by default, revoke those grants. Adding policies doesn't remove them."
Prompting an AI tool to fix it
You can ask a coding tool to add these checks. Ask it to list each table and route, and state who can reach each one. Then have a person read that list against your business rules.
The tool doesn't know that a manager may see one branch but not another. Only you do.
Next step
Run the two-account test this week. Then work through the AI-built app security checklist.
If you'd like outside help, our website security consulting covers assessments of your setup. It reduces risk, but it cannot certify an app as safe, and we do not do penetration testing.
Frequently asked questions
What is an example of broken access control?
A logged-in user changes a number in a web address and sees another customer's invoice. OWASP calls this viewing someone else's account by providing its unique identifier.
Is hiding the admin button enough?
No. OWASP's example shows that a check in the browser can be skipped with a direct request. Access must be checked on the server or in the database.
Is this the same as a login problem?
No. Login confirms who someone is. Access control decides what that person may reach, and you need both.
Does row-level security solve this?
It can, for database rows, when the policies are correct and existing grants are dealt with. You still need checks for server actions and admin functions.
Can I test my competitor's site for this?
No. Only test systems you own or have written permission to test. Testing someone else's site can create legal exposure.
Do you offer penetration testing?
No. eSEOspace does not do penetration testing. If you need one, hire a qualified firm.
