One of the most common misconceptions we encounter during web application and API testing is the assumption that if a user can’t see a function in the interface, they can’t access it.
From a security standpoint, that assumption is dangerous.
A button being hidden doesn’t mean the underlying functionality is protected.
A menu item being disabled doesn’t mean the API behind it is inaccessible.
And removing an administrative option from the UI doesn’t necessarily prevent a lower-privileged user from calling the same endpoint directly.
That’s why authorization testing happens at the request level, not just through the browser interface.
The browser is only the front end
Modern applications often have a web or mobile interface sitting on top of one or more APIs.
When a user clicks a button, the application may send a request such as
POST /api/users/123/disable
The UI may only display that button to administrators.
But an attacker doesn’t have to use the UI.
They can intercept the request, modify it, replay it, or construct the request themselves.
The important security question isn’t “Can this user see the button?”
It’s “Does the server verify that this user is authorized to perform the action?”
If the answer is no, hiding the function in the UI provides very little protection.
We see this in several forms
Sometimes it’s straightforward.
A normal user changes an object ID and gains access to another user’s record.
Other times, it’s less obvious.
An application may correctly restrict a management page while leaving the API endpoint behind it accessible to lower-privileged users.
A read-only role may be able to send a POST, PUT, or DELETE request directly even though the interface only allows them to view data.
An application might prevent a user from changing sensitive fields in the browser while the backend still accepts those fields when they’re manually added to the request.
That last scenario can lead to issues such as mass assignment, where an application accepts parameters the user was never supposed to control.
For example, the application may legitimately allow a user to update name, email, and phone, while the backend also accepts values such as isAdmin=true or role=administrator.
If authorization is enforced only through what the UI chooses to display, the application is trusting the client to behave.
An attacker won’t.
Multi-role applications are where this gets interesting
This is why we often ask clients for multiple accounts when testing a web application or API.
A single account tells us whether authentication works.
Multiple roles let us test authorization boundaries.
We want to understand what happens when
- A regular user requests an administrator endpoint
- One customer accesses another customer’s objects
- A manager attempts an owner-level action
- One tenant changes another tenant’s identifiers
- A disabled feature is called directly through the API
- A mobile or web client sends parameters the UI normally prevents
These are frequently business logic problems rather than traditional software vulnerabilities.
There may be no outdated library.
No CVE.
No scanner finding.
The application simply trusts the wrong user to perform the wrong action.
The API has to enforce the rule
The safest model is simple.
The client requests an action.
The server independently determines whether the authenticated identity is allowed to perform it.
Every time.
That authorization decision should not depend on whether a button was hidden, JavaScript prevented the request, or the mobile application removed an option from the menu.
Those are usability controls.
They are not security boundaries.
This is also why API testing has become such an important part of modern application security.
As more business logic moves into APIs, the backend increasingly becomes the place where authorization has to be enforced correctly.
When I’m testing an application, I’m not just asking “What does the application let me do?”
I’m also asking “What happens when I ignore the application and talk directly to the backend?”
That’s often where the more interesting findings show up.