On this page
Think a lower-privileged user can reach too much? Run the free scan at scan.sumrite.com, then talk to our team about a manual assessment to verify it.
Most applications start simple. There are a handful of users, everyone is trusted, and access control is a problem for later. Then the application grows: customers, staff, admins, partners, an API. If “later” never came, what you have is an application where authentication proves who you are but nothing properly decides what you are allowed to do. That gap is the absence of RBAC, and it is where some of the most serious findings in any test live.
What role-based access control is meant to do
RBAC attaches permissions to roles rather than to individuals. A viewer can read; an editor can change their own content; an admin can manage users and settings. Each user holds a role, and on every sensitive action the application asks a single question on the server: is this user’s role allowed to do this? If the answer is no, the action is refused, whether it arrived through a button, a typed URL or a direct API call.
When that question is never asked, or is asked only in the browser, the model collapses into “anyone logged in can do anything they can reach”.
What its absence looks like in practice
Admin functions open to all
User management, configuration and reporting pages work for any logged-in account, because the server never checks the role behind the request.
Other users' data reachable
Changing an identifier in a URL or API call returns someone else's record, because ownership is never verified.
Privileged API endpoints exposed
The mobile app or front end hides an action, but the API endpoint behind it accepts the call from anyone.
Self-promotion to admin
A profile-update request that includes a role field is accepted, letting a user raise their own privileges.
The common thread is that the server trusts the request. The interface may only offer safe actions, but the server will perform any action it receives, regardless of who sent it.
Why hiding the button is not access control
The most frequent mistake is enforcing access only in the user interface: a menu item is hidden, a button is greyed out, a route is removed from the front-end app. All of that changes what an ordinary user sees. None of it changes what the server accepts. Anyone can observe the requests their own browser makes, and send the same request again with different values. If the only thing protecting an admin action was that the button was hidden, the action is effectively public.
Access control has to be decided where the request is handled, on the server, every time. The interface should reflect those rules, but it can never be the thing that enforces them.
Verifying an RBAC failure needs care
Confirming that a lower-privileged account really can reach a privileged action means doing it with test accounts, against a safe target, without reading or changing real users’ data. That is deliberate, careful work. Do not probe a live production system casually to “check”, because you risk exposing or altering genuine customer data in the process. This is exactly the kind of verification to hand to a tester.
Missing RBAC and IDOR are cousins
Two related findings both fall under broken access control:
- Absence of RBAC usually means there is no proper check on whether a role may perform an action, so privileged functions are open to lower-privileged users.
- IDOR (insecure direct object reference) means a user can reach another user’s specific record by changing an identifier that the application does not check ownership of.
They overlap and often appear together. Our case study on how an IDOR exposed customer records shows the second kind in action; the underlying lesson is the same, which is that the server must check both the role and the ownership on every request.
Why a scanner cannot settle this for you
Automated tools can flag some obvious cases, such as an admin path that returns a page without a login. What they cannot do is understand your application’s roles and rules: which roles exist, what each one should and should not be able to do, and whether the server enforces that for every action and every object. Answering those questions means testing with several accounts of different privilege levels and comparing what each can actually reach. That is why access control findings nearly always come out of manual testing, and why they are often the highest-severity items in the report.
How to build and check access control
- Define roles and permissions. Write down the roles and exactly what each may do. You cannot enforce rules you have not stated.
- Enforce on the server, every time. Check the user’s role and the object’s ownership at the point the request is handled, for web pages and API endpoints alike. Deny by default.
- Never trust client-supplied role data. Ignore role or permission fields sent in a request body; derive them from the authenticated session on the server.
- Keep the interface in step. Hide actions a user cannot take, but treat that as usability, not security.
- Scan for the obvious. Run the free scan at scan.sumrite.com to catch the issues a tool can see.
- Verify by hand. Have testers confirm, with multiple accounts, that no role can step outside its boundaries, then retest after fixes.
How Summit helps
Access control is one of the first things we test, because it is where the serious findings usually are. Summit’s web application VAPT and API security testing work through your application with accounts at every privilege level, checking whether the server really enforces who may do what and who may see which records. Source code review finds the places where the check is missing in the first place. Every finding is confirmed by hand, with a fix and a retest.
Scan now, then let us verify it by hand
Run the free scan at scan.sumrite.com for the issues a scanner can catch, then reach out to our team for a manual assessment to verify an RBAC failure safely.
Related reading: How an IDOR exposed 12,000 customer records · Host header injection and open redirection · What is a VAPT assessment?
Frequently asked questions
What is role-based access control (RBAC)?
A model where permissions are attached to roles, such as viewer, editor or admin, and users get a role. The application checks, on every sensitive action, whether the current user's role is allowed to perform it. Access control that enforces this on the server is what stands between an ordinary user and an admin function.
What does the absence of RBAC lead to?
Broken access control: any authenticated user can reach actions and data meant for other roles or other users. That includes admin pages, other customers' records, and privileged API endpoints. It is consistently one of the most common and most serious classes of web application finding.
Is hiding the admin button enough?
No. Hiding a button or a menu item only changes what the interface shows. If the server still accepts the request when it is sent directly, the function is open to anyone who knows or guesses the URL or API call. Access control has to be enforced on the server, not in the interface.
What is the difference between missing RBAC and IDOR?
Missing RBAC usually means there is no proper check on whether a role may perform an action, so privileged functions are open. IDOR (insecure direct object reference) means a user can reach another user's specific record by changing an identifier. They overlap: both are broken access control, and a test looks for both.
Can an automated scan find missing access control?
Only partly. A scanner can flag some obvious cases, but understanding which roles exist, what each should be allowed to do, and whether the server enforces it needs a person testing with multiple accounts. This is why access control findings almost always come from manual testing.
How do I get our access control checked?
Run Summit's free scan at scan.sumrite.com for the issues a scanner can see, then reach out to our team for a manual assessment to verify an RBAC failure. Confirming one safely, without touching real data, is expert work.
Faisal Khan is a Director at Summit, where he oversees penetration testing, risk assessment and compliance engagements for SaaS and enterprise clients. Case studies are anonymised and published with client permission.
