Of the OWASP Top 10, the group of vulnerabilities that keeps me up most at night (and likely every other CISO) is broken access control. It’s at the top of the OWASP Top 10 for a reason.

Broken access control describes a group of vulnerabilities that allow an attacker to access data, move laterally, and escalate privileges. The ability to execute those actions can, in turn, facilitate large-scale data exfiltration and even allow the execution of a successful ransomware attack.

Let’s dive in starting with a top-down view of what broken access control is, why it keeps me up at night, and some of the strategic priorities your organization can pursue to address and mitigate broken access control threats.

What is Broken Access Control?

As a CISO, my approach to broken access control is mainly strategic, as opposed to tactical. I support my team in providing standards and the ability to enforce those standards.

When conceptualizing access control vulnerabilities, I examine the main components, how they interact, and where they can fail. Breaking it down in that way allows for a more robust baselining exercise and helps me focus my security team’s efforts, as well as where they should coordinate with peer teams in the organization.

The components of access control I primarily focus on are authentication, permissions, and session management. In the following sections, I’ll dive into each and highlight how control deficiencies can result in broken access control.

Authentication

The OWASP page describing broken access control highlights a couple of simple examples of authentication deficiencies leading to broken access control. Both involve brute-forcing limited-access pages of a website where access shouldn’t be permitted. If it is, that’s a broken authentication control.

There are other causes of broken authentication controls, of course, but the primary focus of broken access control vulnerabilities is what an attacker does after they’ve hijacked access.

For more about the differences between authentication and authorization, go here.

Permissions

Once authenticated, permissions dictate what you can do, when, and where. I don’t infantilize my users, but I do liken permissions to a toddler’s playpen. You may decide to put a toddler in a playpen if you don’t want them to have free reign of the house. You want to keep them safe but can’t watch their every move. If your playpen is scalable, you can increase or decrease the space to which they have access. You can put things in the playpen if you want the toddler to have access to them and you can remove them if you want to revoke access.

At some point, your toddler will break out of the playpen. Or, if you have older children, one of them might come by and modify the playpen, open the playpen, or change what’s accessible from the playpen.

In this analogy, the toddler and older children are analogous to internal and external threat actors. Once authenticated, a user account (the playpen) can be manipulated to increase or modify access in unanticipated and unauthorized ways. The employee or threat actor can then do things they otherwise aren’t authorized to do.

That extension of agency within the target environment can impact applications, cloud infrastructure, and other corporate infrastructure. The easier it is to jump from one environment to another, the more agency an individual can obtain. The unauthorized expansion of agency in an environment is broken access control.

Elevated permissions

There are numerous mechanisms for a threat actor to obtain elevated permissions. The most common for web apps, both by execution and documentation, are injection flaws. Injection flaws allow the injection of untrusted and unverified user input into an application, resulting in unwanted (and likely unanticipated) behavior. This can result in the elevation of user privileges even when the user has correctly authenticated with the application’s identity provider.

Regardless of how it was obtained, the elevation of user privileges is encountered when the application relies on the caller (most likely a script on a web page) to pass "correct" parameters, such as a user ID and/or resource ID. A threat actor can send the wrong parameters as part of the payload and, if the application isn't checking the input but simply trusting it, be able to access or even update information they shouldn’t have access to. They could also impersonate a user with higher permissions.

To shield your organization from these vulnerabilities, your applications must explicitly ensure that the user has permissions to perform an operation on the resource prior to performing that operation.

Session management

Taking the playpen analogy a step further, session management is the toddler playing in their playpen. If they play with the toys they have access to the entire time, then the session is valid and appropriate. If they start playing with other toys they ought not to, doing things that they ought not to, or if they break out of the playpen, then the session is invalid and inappropriate.

Session management is about enforcing and constraining desired behavior. If someone is able to navigate to a restricted webpage from a public page, traverse environment levels when they shouldn’t be able to, or delete or encrypt large swaths of data in an environment, then appropriate session management is lacking.

My expectation is that once access is granted around a set of permissions, user behavior will expand to fill the volume provided by both. Users tend to not behave erratically but over a long enough timeline will do anything and everything permitted to them. Not being able to stop unwanted or unanticipated behaviors–or at least see and evaluate those things–is broken access control.

One of the most common broken access control issues results from applications that rely on the integrity of the session to ensure that users don't have undesired privileges, rather than checking for valid permissions before accessing any protected resource during that session. If an application relies on permissions being encoded in an access token, as scopes in a JWT for example, then the user will have those permissions for as long as that token is valid (hours or days). This can lead to users continuing to have privileges that were already revoked. For more about this attack vector, go here.

Why Broken Access Control keeps me up at night

As a CISO, my responsibility is to the organization and its customers’ information. I am tasked with developing conditions to nurture an environment conducive to maintaining the confidentiality, integrity, and availability of information.

Broken access controls thwart that development. They provide an unknown and likely unmonitored avenue of threat ingress. Once in an environment, a threat actor can move laterally or vertically and wreak havoc. In a very real way, broken access controls fuel what is soon expected to be a multi-trillion-dollar-per-year ransomware threat industry.

Broken access controls also provide an unmonitored avenue of information egress. While your organization may have monitoring in place for large-scale data movement–and may even automate halting those movements–that monitoring may be thwarted with the appropriate permissions or session expectations. Additionally, a threat actor may not need a large quantity of data and instead opt for small quantities of high-value data.

In both cases, the costs to an organization are significant. The loss of large swaths of Protected Health Information, Personally Identifiable Information, sensitive financial information, or other regulatorily protected information can cost an organization dearly. Add to that loss of profits from reputational damage or misappropriation of intellectual property and it’s easy to see why the average cost of a breach for a company now sits in the high millions of dollars to low tens of millions of dollars.

Those costs don’t account for potentially significant collateral damage to other organizations. Where broken access controls are exposed at common service providers, their impact can be substantially amplified. For example, one misconfigured Microsoft server in October 2022 was responsible for the leak of over 65,000 customer files, including orders of magnitude more employee data. Two years ago, access to the Solarwinds development pipeline impacted and compromised the networks of tens of thousands of organizations worldwide.

Those are two of the most significant compromises of broken access controls in recent years. They’re certainly not the only ones. The ease with which access controls can be broken, the focus on those weaknesses as an avenue for entry by threat actors, and the significance of the impact of broken access control really make me worry as a security practitioner. Especially where I can’t manage my vendors’ security environments and many vendors refuse to provide assurances about their controls or address deficiencies when identified.

Strategic priorities that address Broken Access Controls

By identifying the components of access control, organizations can strategically plan how to address broken access controls in manageable increments. There are some large-scale strategic objectives that span access control as a domain, but others can be adopted piecemeal.

Let’s examine each component and some of the strategic foci that can benefit prioritization.

Authentication

When I look at authentication, I think about:

• How is authentication handled?
• How is identity validated?
• Are authentication mechanisms designed to verify and deny by default?

With respect to authentication handling, I’d recommend thinking about what you do to authenticate. Passwords, a security mainstay for decades, are now falling out of favor and being replaced by passphrases. Passphrases are great because they use more characters, tend to have more complexity, and are easy for individuals to remember.

Alternatively, you could look to identity validation mechanisms to mitigate complexity. Tokenized authentication and multifactor authentication go a long way toward reducing complexity. Online shopping and banking are dominated by multifactor authentication as a way to authenticate access. Many people who work in an office are accustomed to RFID or biometric locks. While a password may not be secure, those authentication mechanisms can be.

On top of that, when designing website or application authentication, OWASP recommends leveraging some kind of access control verification layer. Routing all access through that layer provides a solid defense against unanticipated, unauthorized access. Combining that with deny-by-default application logic ensures that access is forbidden unless actively provided. While that can have draconian results, it will also prevent unanticipated access and privilege modification.

Permissions

When evaluating permissions controls, some questions you can ask yourself are:

• Do you enforce the principle of least privilege?
• How do you handle roles?
• Are you logging unexpected permissions events?

The principle of least privilege is one of the cornerstones of information security. All forms of access should be configured with the least possible access to accomplish the goals provided by that access. If you’re building an eCommerce site, visitors to the site shouldn’t be admins. If you’re provisioning a cloud environment, you shouldn’t provide every developer unfettered access to the entire environment.

One way you can accomplish that permissions control is through an authorization model, such as role-based access control, attribute-based access control, or relationship-based access control. What you choose depends on the prominence of attributes or roles for your specific needs. Whichever you choose should enforce both vertical and horizontal controls and ensure that movement outside of vertical and horizontal access permissions is respected. It also should never result in hardcoding entitlement logic in applications.

Input validation is another critical control that bolsters permissions controls and reduces resultant broken access controls. Injection-type attacks can be thwarted by validating every input. Invalid or unexpected inputs should fail closed by denying by default and result in an error instead of access.

Input validation should also validate permissions. Inputs should only be valid when done by someone with permissions to create the input. If an input attempts to subvert the permission controls in place and exceed allowed permissions, a deny-by-default model should halt that subversion.

Lastly, where unexpected or infrequent activity can occur, evaluate monitoring for those events. Sometimes, users will need elevated permissions, administrative roles will be created, or broad lateral movement is desirable. Security monitoring can capture those events and alert them. Given the potential criticality of those events, it’s a small increased work volume that can prevent substantial organizational damage.

Session management

Session management builds on that logging and addresses managing behavior to occur within expected ranges. Much of this domain involves addressing unanticipated access events and preventing things like impossible travel access, leveraging unprotected functionality, or taking advantage of misconfiguration.

Log monitoring and event alerting can help address this. Code reviews incorporating security considerations can also help. Key to addressing session management vulnerabilities is having visibility into development, access management processes, and typical avenues of access to identify divergent and unexpected behavior.

Also critical is disallowing caching of permissions for an extended period of time, which can thwart other session management and permission controls. By limiting what permission information is attributed to a specific user and not enabling the caching of those permissions via tokenized credentials or other means, websites and apps can significantly decrease broken session management controls.

Conclusion

Broken access control is the single most significant class of vulnerability in existence today. Gaps in authentication, permission management, and session management can result in significant costs and problems for an organization.

There are ways to address that which fall short of enterprise-wide security-office defining projects. You can block and tackle broken access control vulnerabilities. That being said, if your organization has the appetite for taking on access control and identity governance projects, then it can also benefit greatly from those.