How the HR System Enabled my Promotion to CEO

by Matt Keil on October 22, 2020

Just kidding. I am happy to remain an individual contributor. However, if the HR system API had been implemented without the appropriate levels of authorization control, commonly referred to as broken object-level authorization (BOLA), it could be exploited by bad actors, internal or external, to enable an undeserving promotion.

BOLA is #1 in the OWASP API Top Ten list and the reason is simple – it’s the most commonly exploited API vulnerability. In simple terms, BOLA means the API has not been developed with appropriate authorization controls. As shown in my fictitious promotion and in recent real-world examples including WAZE, Shopify, and New Relic, a BOLA exploit means a bad actor could access, modify or steal PII, or in some cases, execute an automated attack using, for example, enumeration techniques as shown in our PryingEye disclosure from 2019.

One of the reasons BOLA exploits are more common than others is the fact that controlling permissions after access (authorization) is a fundamental building block of most any application or API. With that understanding, the need for some type of authorization is, or should be defined in the product requirements, which are then translated to the API specification. It’s in the implementation phase(s) of the release process that BOLA vulnerabilities are introduced. There is no single reason, but a few possible causes come to mind.

Development teams have not received training on secure coding for modern applications or for APIs. Security training for developers has long been a challenge, and the flexibility that APIs introduce exacerbates the challenge. Developers are human. Errors are made. However, more complete and API specific training may lessen the frequency of errors.
Inadequate security testing was performed on the API functionality. Many organizations perform application pen-testing, but too often the API functionality is not tested from a security perspective.
The API was originally intended to be an internal API, behind multiple levels of security, yet it was exposed either accidentally or purposely, without knowing about the lack of authorization, and the inherent security risk. Many organizations are adopting the security best practices approach that treats all APIs as external, which means tighter controls and fewer risks.
The API is a shadow API, released outside of the defined process, so peer review, QA cycles, security testing may not have been applied. If this is the case, then the specifications may have been summarily ignored. Worse yet, often these systems are built at full “admin” level and everyone is an admin.

No doubt there are other reasons BOLA retains the #1 position. The bigger question is what can be done about it. To learn how other organizations are addressing these and other API security challenges, please join Joe Krull from the Aite Group and Ameya Talwalkar, our CPO and co-founder for an API Security Best Practices webinar on October 27^th at 11:00AM Pacific Time.