15 Practices to Shield APIs from Attack: #5 – OWASP Top 10, Broken Access Control
Every few years, the Open Worldwide Application Security Project (OWASP) updates its top attack vectors. To illustrate how our work and the practices we’ve discussed in this blog series truly help improve security posture, this post goes through the first of the top 10 attack vectors and reviews which of the practices helps to prevent this kind of attack.
A01:2021-Broken Access Control
Broken access control involves clients obtaining information or operations that they are not permissioned to access. In APIs, access control can be complicated and hard to validate. Of the practices we have talked about, our teams rely on the following to prevent this kind of security risk.
Having the policies involved in access control continually tested prevents accidental failures and new bugs from being introduced. These tests cover failure scenarios as well, and having the team adopt this testing mindset (‘how can I break this code?’) is important in ensuring these tests have coverage. Part of our testing involves automated validation after deployment to all environments, including production, which allows the team to ensure access control policies are behaving as expected. We also test for valid encryption of identity tokens being used by the system, and tests involve providing fake and manipulated tokens to ensure the system does not accept them – a risk directly identified by this OWASP vector.
OWASP calls for deny-by-default as a practice for ensuring no access to unnecessary resources. Our network practice of closing ports by default is a good example of this one.
The concept of policy sets in our API gateway means that we prevent accidental deployment of API endpoints that miss the access control policies. None of the API deployment operators can ever configure an endpoint with missing authentication and access control, as a result of this design. It also means that, implicitly, access control mechanisms are being reused across the system.
Compromised software credentials for one of your clients is almost inevitable. In this scenario, a simple B2B API is automatically vulnerable, granting access to all the operations permissioned for the client, which might mean the ability to access hundreds or thousands of customer accounts and their related information. Our OAuth2 policy in the gateway can protect against this type of breach. Having the customer who owns the data in the API call flow, as identified by an Identity Platform generated authorization token, provides an extra layer of security that makes it virtually impossible for an attacker to brute-force an API to download thousands of results without also tricking every single customer into authenticating and authorizing their calls at the same time, which is far more difficult, unlikely, and impractical. Does losing thousands of customer records to an attacker sound like a familiar issue? It should be, it happens to corporations all of the time. Such an ‘OAuth as a service’ policy might have protected the compromised T-Mobile API, depending on the particular attack used. This kind of policy helps our client stay off the front page of the news with this kind of damaging announcement by ensuring access control is specific, not just to the API user, but also to the customer information being accessed.
OWASP requires access control failures to be logged. Our fully-instrumented observability and security events do exactly that. We push them to the Splunk platform for continued monitoring and auditing. Having a SIEM platform that can trigger and watch for unusual activity, perhaps even employing machine learning to detect these aberrant patterns, would further enhance the detection of access control failures.
