Access control: the evolving security challenge that never fails to cause anguish for those battling to keep their assets secure. This vital, yet easily overlooked, area of security is a hot topic in the world of application security.

The stakes are high. Failing to uphold access control can have catastrophic consequences. Broken access control remains the most serious security issue – ranked #1 in the OWASP Top 10 list of web application vulnerabilities. It is a gift to threat actors due to the significant impact it causes, and combatting such issues with sound access control continues to require unwavering diligence.

The severity of broken access control is also ascribed to its systemic tendency. Rather than attributing it to a simple, isolated incident, role-based access control (RBAC) often lends itself to a more far-reaching problem causing site-wide outcomes. After all, if one user role contains a broken access control vulnerability, this quickly translates to every user account assigned to that same role. This is music to an attacker’s ears, resulting in unauthorised access to an array of functionality and datasets that would have otherwise been inaccessible.

The monetary impact reflects the risk. On popular bug bounty platforms such as HackerOne, broken access control findings continue to command high payouts. Organisations are eager to identify whether one of these issues affects their respective assets, and the need for sound access control is paramount to their wider security posture.

 

More than just ‘admin access’

Access control is often oversimplified. When you hear ‘broken access control’, you might picture a lower-privileged user performing administrative tasks, or even an escalation in role. Many assume that broken access control is associated with textbook examples of dramatic compromises, full account takeovers or blatant privilege jumps. While this remains true, broken access control can be far more nuanced. It can manifest in many intricate and innovative ways that you haven’t considered.

Below are subtle, less obvious broken access control issues that I have identified during web application penetration tests:

 

  1. Frontend and backend misalignment: Don’t believe what you’re told

I have often seen an elusive disconnect between frontend and backend enforcement of access controls. It’s easy to become distracted by the efficiently mapped user interfaces, the fancy drop-down menus and the pretty dashboards. Besides, why would the frontend lie? The content that is visually displayed post-login is not necessarily the full picture. Despite the overwhelming feeling that what you see is what you get, it’s often not the case when you remember you’re interacting with a deployed technology stack. The user interface may be hiding buttons, masking functionality and greying out text fields. However, if the backend rules enforcing the access controls do not align with the user’s frontend, it’s often possible to directly call unrestricted endpoints, initialise forbidden functionality or gain access to content intended for privileged users.

I was conducting a web application penetration test for a client where a direct download was possible. I was logged in as a ‘standard’ user, noticed a pattern in the way PDF files were being called, and could manipulate HTTP requests to call a PDF file from an admin-only repository. I spotted an easily guessable pattern of formatted strings, and I exploited it. Before I knew it, the file had downloaded successfully while I had remained authenticated as a standard user, proceeding to access the restricted information.

When successfully exploited, it often renders other mitigating controls, such as MFA (multifactor authentication), redundant. If I can download an admin-only document as a standard user, no amount of authentication safeguards will stop me.

This form of ‘pseudo’ access control gives users the illusion of security. In reality, the true state of their access can be radically different.

 

  1. Insecure direct object references: The single point of failure

One of the more insidious forms of broken access control is IDOR (insecure direct object reference) vulnerabilities. These occur when manipulating request parameters that contain either a numeric value or string to a direct resource. This includes, but is not limited to, URL parameters and HTTP body parameters. User IDs, file names, and anything directly associated to an object when calling it can be arbitrarily amended in a way that allows a user to attempt calls outside of the immediate remit. It can lead to unauthorised viewing or manipulation of data by exploiting predictable identifiers or inadequate backend validation.

Despite the user’s role being unquestionably defined with certain boundaries inside the web application, a simple oversight such as a direct object reference can render the rules redundant if unaligned with the wider ruleset. I see this issue come up repeatedly, and it is alarming how significant these vulnerabilities can be if exploited successfully.

 

  1. Application logic flaws: Why human intervention is key

Broken access control is not always binary: sometimes it’s tied to business logic. Application logic flaws exist due to flawed assumptions about how users interact with features, resulting in applications behaving in unexpected ways. This is still broken access control – just delivered through business logic rather than direct permissions. Such logical flaws still result in accessing information that shouldn’t be accessed in a certain way or using application functions in an illogical manner that could cause backend complications.

I discovered such an application logic flaw when assessing an application workflow tailored to a specific user type. The workflow moved a record through a five-step process, and it was vital that each step was followed in logical order, with the intended functionality to allow the user to sequentially progress from steps 1 to 5, with each being a prerequisite of the step before. It was possible to amend requests to skip steps 1 and 4 and continue straight to step 5 without having entered any input beforehand. Beyond step 5, I could continue to submit the record and exit the workflow successfully. This allowed a user to submit partially completed records that the application did not expect. These records were being processed within the backend in a way that threw error messages server-side. As the checking rules were not enforcing the logic of the journey, broken access control issues permitted unauthorised access to data. This type of real-world scenario exemplifies the ability to access something (step 5) directly without the intended access to do so.

These scenarios are challenging to catch with automated tooling, as they depend heavily on understanding the context and design of the application. This is where experienced human testers come in. The reality is that no automated scanner can fully grasp naming conventions unique to each organisation, nor interpret unintended consequences from a sequence of frontend interactions misaligned with backend controls. Understanding the intended function of an application is key here. A human tester’s wider knowledge and experience of how the application should and shouldn’t behave can result in catching anomalies in its logic.

 

  1. Forced browsing and hidden endpoints: “Was I supposed to see this?”

Forced browsing and hidden endpoints represent a subtle yet critical vector for broken access control that is often overlooked. These vulnerabilities arise when attackers manually or programmatically access URLs or endpoints that are not linked in the user interface but still exist on the server – relying on obscurity rather than proper authorisation checking rules. Since these endpoints are ‘hidden’, they’re frequently assumed to be secure or are simply forgotten during security reviews, allowing unauthorised users to perform actions or view data intended for privileged users only. This technique is hazardous because it bypasses typical user flow validation and can be used to access admin panels, configuration files or sensitive operations that should be protected by strict access controls.

Administrative login portals, specifically, are frequently discovered during web application tests. The absence of robust authorisation logic, not just visible protections, makes forced browsing a quiet but potent tool for attackers.

 

  1. JWT role tampering and client-side role enforcement: Proof that encoded session IDs are not secure

JWT (JSON Web Token) manipulation is another route an attacker could use to assess the access control of an asset. This is a fantastic way to achieve privilege escalation. By altering claims within the JWT’s payload such as the user role, an attacker seeking to escalate their privileges can attempt to change their role from, for example, a visitor to an application administrator.

This common method remains a significant security concern that stems from improper implementation rather than flaws in the JWT standard itself. In these scenarios, an attacker decodes a JWT string, modifies a claim (e.g. changing “role”: “user” to “role”: “admin”) and re-encodes the token. If the server fails to properly validate the token’s signature (often due to misconfigurations, such as accepting unsigned tokens (all: none) or using a public key as a secret), the forged token may be accepted, which then grants elevated privileges.

While such issues are relatively rare in mature applications, the widespread use of JWT for authentication procedures (particularly now with the mainstream option of SSO (single sign-on)) has made them an attractive target. The assumption that JWTs are secure ‘out of the box’ can lead to dangerous oversights if their configuration has not been considered during deployment. Developers may mistakenly trust the contents of a token without rigorous validation, exposing the application to privilege escalation or unauthorised access vulnerabilities. Careful attention to signature verification, claim validation and encrypted payloads (JWE), and the avoidance of sensitive information, remain critical to maintaining access control integrity.

 

  1. Race conditions and considerations for Cloud adoption

Race conditions are a subtle and often overlooked category of broken access control and broader application logic flaws, typically arising in multi-threaded or concurrent environments. Have you ever accidentally double-clicked a button when signed in to your dashboard? Perhaps you wondered what happens now or which click registered.

In a web context, a race condition occurs when two or more requests are processed simultaneously in a way that leads to unexpected behaviour which goes on to bypass intended restrictions. For example, an attacker might submit multiple rapid requests to update a user’s role, transfer funds or redeem a discount code. This inevitably exploits timing gaps in how the server validates and processes each action. If the application doesn’t implement proper locking, atomic operations or order-of-execution guarantees, this can result in privilege escalation, resource overloads or unauthorised actions being performed.

Although race conditions are not as commonly encountered as misconfigured permissions, they are increasingly relevant in high-performance, distributed or Cloud-native applications where concurrency is the norm. Their subtlety makes them hard to detect during routine testing, often requiring a deep understanding of application behaviour with extensive time to test for such disguised flaws. For this very reason, race conditions remain a high-impact, low-visibility threat that security teams must account for.

 

  1. Other techniques to consider

There are many other techniques that fall under the wider umbrella of broken access control:

  • Web applications offer diverse types of HTTP methods that can be used within requests when interacting with the web server. Method-based access control flaws could exist in this scenario, whereby different HTTP methods (PUT, DELETE, PATCH, etc.) may have been configured differently from more conventional methods such as GET and POST. If the application developers did not secure these methods in the same way, there may be exceptions to the main set of access control rules.
  • If the web application is using microservices within its overarching service, access control may apply differently – for example, you are interacting with a subscription dashboard as opposed to a main dashboard. Inconsistent RBAC across microservices could be telling when these interactions occur. Inconsistencies could arise whereby one service could allow actions that other services on the same application correctly deny.
  • CORS (cross-origin resource sharing) policies, which are typical within modern web applications, control which origins (or domains) are allowed to access the resources hosted on the given web server via a web browser. Weak or wildcard (*) configurations could allow untrusted sites to make authenticated requests on behalf of users.
  • Some access control configurations rely on the Referer header to validate request origins. This can be circumvented through a variety of techniques, including spoofing attacks.
  • Some larger applications use APIs (application programming interfaces) to facilitate HTTP requests between the client and the server. Internet-facing APIs can introduce many attack vectors if the service has been deployed without proper access control. Due to the foundations of APIs, it’s tempting for developers to assume security has been addressed through obscurity. This could leave exposed API endpoints.

How to tackle the problem

If you’re concerned about broken access control in your applications – and you should be – the first step is to schedule a web application penetration test from a reputable consultancy.

This type of test will help identify broken access control issues along with any other notable issues. The testers should provide a report that details these vulnerabilities and describes how to remediate them.

How to prepare for a grey-box/white-box web application test

Based on my experience, here’s how clients can get the most value from such a test:

  • Provide multiple accounts for each user role. This allows for realistic cross-account testing to identify inconsistencies within roles.
  • Supply an access control matrix. This helps testers understand what each role should (and should not) be able to do, accelerating the discovery of anomalies without unnecessary back-and-forth.
  • Where possible, conduct testing against a UAT or pre-production environment that mirrors the production environment. It gives testers more freedom to push the boundaries without affecting live users or data.
  • Offer an application demo during a project kick-off call. A walkthrough of each user role’s expected functionality helps testers understand the intended logic and spot deviations more quickly.
  • Share known examples of what users should or shouldn’t be able to access. These can serve as useful benchmarks or highlight areas for focused testing.

Conclusion

Broken access control isn’t a flashy topic, but it’s consistently rated as one of the most critical vulnerabilities in the OWASP Top 10 and regularly earns top payouts on bug bounty platforms.

Because access control mechanisms tend to be systemic, a single flaw often translates across all users with the same role. That means the impact can be widespread, exposing sensitive data, bypassing business processes or allowing unauthorised actions to cascade through the application.

Broken access control remains a potentially high-risk issue that demands ongoing attention. It isn’t always obvious, but its subtle manifestations can be just as impactful across modern web applications.

By approaching your security assessments with these nuances in mind, and by partnering with highly skilled penetration testers who have experience testing for such vulnerability variation, you can identify and address these critical issues before they become business-impacting incidents.

 

GRC Solutions web application pen testing

Our CREST-accredited penetration testers will help you:

  • Gain real-world insight into your vulnerabilities;
  • Keep untrusted data separate from commands and queries;
  • Develop strong authentication and session management controls;
  • Improve access control;
  • Discover the most vulnerable route through which an attack can be made; and
  • Find any loopholes that could lead to the theft of sensitive data.

 

Find out more about our web application penetration testing services

 

About the author

Benjamin Strudwick is a security consultant at GRC Solutions and operates in our security testing team. Benjamin has over seven years’ of security testing experience and has performed numerous public- and private-sector engagements across multiple industries, including telecommunications, finance, government, health and tourism.