OWASP Top 10 2025 — A01: Broken Access Control
Access control determines who can access which resources and what actions they are allowed to perform. A secure system ensures that users can only view and modify data that belongs to them and cannot access restricted functionality.
When this control is missing or poorly implemented, attackers can bypass restrictions, access sensitive data, and escalate their privileges. This is what OWASP classifies as Broken Access Control.
In many real-world attacks, systems are not compromised through advanced exploits. Instead, attackers take advantage of weak authorization logic and gain access to areas they were never meant to see.
In this article, I will share how I exploited this exact issue in Hack The Box's OWASP Top 10 2025 track, in a challenge called CriticalOps, and how a simple design flaw led to full administrative access.
Challenge Overview: CriticalOps
The CriticalOps challenge simulates a web application used to monitor critical infrastructure in a fictional region. Users can submit tickets to report unusual activity, and administrators manage and monitor these reports.
The objective of the challenge was to analyze the application, find potential vulnerabilities, and retrieve a hidden flag.
I started by visiting the website and registering a new user account. After logging in, I was redirected to a simple dashboard. From there, I could submit tickets and view only my own reports. Everything appeared properly restricted at first.
While reviewing my profile, I noticed that my account role was displayed as "user." This immediately caught my attention. Whenever roles are exposed to the client, it is worth investigating how the application uses them.
Initial Testing and Observations
My first instinct was to try modifying the role value directly in the browser. I changed it from "user" to "admin" using developer tools. However, this had no effect. The interface did not change, and no new features appeared.
This confirmed that the frontend alone was not responsible for access control. The real logic was likely happening on the backend.
At this point, I decided to inspect the authentication process more closely.
Intercepting the Login Process
I logged out of the application and set up Burp Suite to intercept traffic. Then, I logged in again while capturing the request and response.
The login request itself was standard and did not reveal anything interesting. It contained the username and password.
The response, however, was more revealing.
Inside the server's response, I noticed a parameter indicating my role:
This suggested that the server was sending the role information directly to the client during the authentication process. More importantly, it suggested that the application might be trusting this value for authorization.
This was a strong indicator of a potential access control flaw.
Exploiting the Vulnerability
Instead of forwarding the response as it was, I modified it.
I changed the role value from "user" to "admin" and then allowed the response to reach my browser.
The application detected no issues. It accepted the modified response without verification.
After refreshing the page, new options appeared on the dashboard. An administrative panel was now accessible.
Inside this panel, I found additional management features and, ultimately, the hidden flag.
The application had granted me full administrative privileges simply because I altered a value in the response.
What Went Wrong
This was a textbook example of Broken Access Control through role tampering.
The application trusted data that was sent to the client and reused it for authorization decisions. Instead of validating the user's role on the server using secure session data or database records, it relied on a modifiable parameter.
In simple terms, the system believed whatever role the client claimed to have.
Vulnerability Classification
This issue falls under OWASP A01: Broken Access Control. More specifically, it is a case of privilege escalation through client-side role manipulation.
By modifying the role parameter, a normal user was able to gain administrative access without proper authorization.
Real-World Impact
If this vulnerability existed in a real critical infrastructure monitoring system, the consequences would be severe.
An attacker could access confidential operational data, modify reports, hide real incidents, create false alerts, and potentially disrupt emergency responses. In regulated industries, this could result in major financial losses, legal consequences, and risks to public safety.
All of this could happen without exploiting any complex technical weakness. A simple logic flaw would be enough.
Why This Happens So Often
Many developers assume that values sent to the client will not be modified. They rely on frontend controls or hidden fields and believe that users will not tamper with them.
In reality, every value sent to the browser is under the attacker's control. Tools like Burp Suite make modification trivial.
When authorization logic is built on top of untrusted data, vulnerabilities like this become inevitable.
How to Prevent This Vulnerability
The most important rule is to never trust client-side input for authorization.
All access control decisions must be enforced on the server. The server should verify a user's role using secure session data or database records, not values sent by the client.
Roles and permissions should be stored in server-managed sessions or securely signed tokens. Sensitive information should never be passed in plain responses where it can be modified.
Applications should also implement centralized authorization mechanisms so that every protected route is validated consistently.
Regular security testing, including manual reviews and penetration testing, can help identify these issues early. Finally, organizations should follow the principle of least privilege and ensure that users only receive the permissions they truly need.
Key Takeaway
This challenge demonstrates how dangerous simple logic flaws can be.
There was no advanced exploit involved. No complex payloads. No obscure vulnerability.
One unchecked parameter was enough to compromise the entire system.
For anyone preparing for certifications, working in application security, or participating in bug bounty programs, mastering access control testing is essential. Broken Access Control remains at the top of the OWASP list because it continues to be one of the most exploited weaknesses in real applications.
Final Thoughts
CriticalOps may be a learning challenge, but the vulnerability it demonstrates is very real. Similar issues have been responsible for major security breaches in production systems. See how I got Super Admin privileges in the real target.