The crew over at the Open Web Application Security Project (OWASP) has come out with a surprising winner for their OWASP Top 10 list of web application security problems. Claiming the ignoble #1 spot on the 2021 list is “Broken Access Control”, beating out the old dependable yet terrible stalwart “Injection” for the win.
While OWASP did not go into much detail on why “Injection” dropped in the list, a likely explanation is that it is simply getting harder to produce bad code that contains this level of script kiddie foolishness.
No, developers have not suddenly become more security focused. The more probable case is that developers are depending more on reusable software components like open source that are constantly getting fixed by the community.
Don’t worry though, “Injection” didn’t have too far to fall, coming in at #3.
But let’s not digress too much. Access Control is receiving significant attention from one of the leading bodies in the developer community so it’s worth understanding why and how it applies to IAM security practitioners.
Why the Focus on Access Control?
The OWASP team defines the list leading category of “Broken Access Control as such:
Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user’s limits.
These are all the building blocks of how we think about IAM as security practitioners: managing permissions so that only those who need access and are intended to have access to specific assets should be granted that access.
When this is poorly managed, then we run the risk of data being leaked or otherwise harmed.
Fairly straightforward access security management, right?
A couple things do stand out here though.
First is the decision to focus on access control over authentication as the next major challenge for AppSec folks. To further the point, “Broken Authentication” that was way up in the #2 spot on the 2017 list has been downgraded to the #7 spot and combined with Identification to create “Identification and Authentication Failures” as a new category.
This signifies that the task of identifying who the person trying to authenticate their identity is appears to be less of a challenge than it was in the past. The probable reason being that CIAMs and IDPs like Okta and Ping, as well as AD, have made it much harder to do authentication (authn) badly. Many folks are thankfully using tools from these big players instead of “rolling their own” as it were.
The next step of authorizations (authz) however is a bit trickier to get right since it’s less of a binary about if the user is who they claim to be. Access Control looks to determine that folks only have access to what they need and that that access is at the right level. Setting the right controls to limit that access can be hard to get right.
And for their part, the good folks over at OWASP want to draw attention to the area that they see needs the most eyeballs.
My guess is that as nearly everything and everyone is moving over to cloud computing, there is added pressure on the folks developing web applications to make sure that they are handling the basics of the basics correctly. And Access Control is often hard to get right.
At this point you might be asking, why are we devoting time to problems facing developers? Afterall, this is still an IAM focused blog that looks at challenges in managing access on cloud platforms, so what gives?
The answer is simple: Salesforce.
Securing Salesforce Apex
For the most part, IAM security revolves around understanding who has access to what. There is very little coding involved. This is more of a human and organizational challenge to solve, bringing visibility and continuous understanding to control large scales and complex authorization structures.
An exception to this is Salesforce’s Apex. This is Salesforce’s language that allows developers to get in and write their own code for managing the platform. It can be used for adding and manipulating data. As such, it is a place where missteps can lead to heightened risks of exploitation.
The primary risk here is that a developer may inadvertently create escalation paths that an attacker may later use for their advantage.
So how do we mitigate our risk here when it comes to Apex? Here are a couple of quick tips and tricks.
Know Who Can Access the Code
Bring in More Eyes
Sharing Isn’t Always Caring
Identify who can make the kinds of changes to the code that can create those escalation paths. If you are not confident that they need that level of permission, then take it away from them. Basic Principle of Least Privilege.
Have additional reviewers audit your code for possible vulnerabilities that can leave your Salesforce data exposed. Code review is a classic AppSec principle that is very applicable, similar to pentesting. Ideally, try to bring in an outside auditor to poke around. Sometimes fresh eyes can bring new issues to light.
It’s a simple trick but still useful. You can override sharing rules that may have been unintentionally written using Apex with the keyword “without sharing”.
While this may be useful, it is still advisable to use AppSec scanning tools that can identify a potential issue.
Access Control at the Core of Security
OWASP’s latest updates to their Top 10 list is a reminder that Access Control is a challenge facing security professionals across the board, and that we still have a long way to go in figuring out how to do it just a bit better.
Let’s hope that we’ve got a better handle on it for 2025.