A brand new version of the OWASP API Safety Prime 10 is simply across the nook, so we determined to take a sneak peek on the work in progress at OWASP to see what’s been trending for the reason that record was first compiled in 2019. Whereas the present work has launch candidate standing, we’re not anticipating any vital modifications – and can, after all, observe up with a deep dive as quickly because the official record is introduced.
Evolution moderately than revolution
Whereas, at first look, most of the class names are completely different, all the chance classes from the earlier version are nonetheless right here in a single kind or one other. Within the 4 years which have handed, APIs have gone from extensions of core performance to a everlasting staple of net utility structure. This has introduced safety points into sharp focus, permitting classes to be redefined to higher match the particular dangers noticed in precise net environments.
General, the discharge candidate record consists of 4 classes that haven’t modified since 2019, 5 with modifications in naming or scope, and one previous standby that makes a brand new look on this explicit record.
Damaged auth nonetheless prime of the pile
The entire objective of an utility programming interface (API) is to supply entry to one thing in or from the appliance, so entry management has all the time been the highest safety concern for APIs. Accordingly, the #1 danger class hasn’t modified from 2019: Damaged Object-Degree Authorization. Particularly when mixed with insecure direct object references, entry management failures on the utility object stage may end up in information publicity (as within the Optus breach), permitting malicious actors to freely extract delicate information through the API.
Intently associated is one other entry management danger that hasn’t modified in identify or rank since 2019, particularly Damaged Perform-Degree Authorization at #5. This class covers weaknesses that expose utility performance moderately than information, although in follow, there’s vital overlap between the 2. For instance, if an attacker can entry the export operation for buyer information, they may extract delicate data in bulk even when they can not entry every buyer file object individually.
Earlier than any authorization comes authentication, so Damaged Authentication needed to make the record as soon as once more, remaining at #2 (and barely renamed from Damaged Person Authentication). This class encompasses all types of weaknesses that might permit an attacker to behave as a sound consumer, whether or not by allowing credential stuffing for brute-force entry, failing to confirm token signatures, or just permitting unauthenticated entry in some circumstances.
API administration as troublesome as ever
Different dangers that proceed unchanged as of this writing are associated to API administration and administration. Safety Misconfigurations stay at #7, overlaying safety points at any stage of the API expertise stack that aren’t immediately brought on by flaws within the API or utility itself. These embrace unpatched methods, lacking or inconsistent safety headers, improper permissions on cloud companies, and lots of different configuration-related safety dangers throughout advanced API stacks.
Improper Stock Administration (beforehand “asset administration”) continues at #9 and can probably stay on the record as a result of inherent challenges of managing APIs throughout their complete lifecycle. As interfaces and their underlying purposes each bear modifications (typically independently), any gaps in model management and documentation can expose further assault surfaces within the type of deprecated APIs which are nonetheless accessible or undocumented API endpoints that go unnoticed throughout testing.
APIs are all about automation, so failures to manage and restrict utilization are one other mainstay of the API safety prime 10, barely renamed to Unrestricted Useful resource Consumption at #4. These broadly fall into two principal classes. Firstly, limitless API entry can expose net companies and purposes to denial of service (DoS) assaults brought on by useful resource exhaustion when a server within the API stack can not deal with any extra requests. Simply as importantly, an absence of appropriate charge limiting can permit attackers to mount brute-force assaults to, for instance, break passwords or enumerate information information.
Broadening danger horizons
Three danger classes have been broadened and redefined to cowl a wider vary of safety points. In comparison with the 2019 record, extreme information publicity and mass project dangers at the moment are each included beneath Damaged Object Property Degree Authorization at #3. That is intently associated to object-level authorization failures however applies at a extra granular stage, the place defining and implementing entry management is far more durable. Even with correct entry management to, say, buyer information information, you continue to have to outline who can carry out which operations on which information fields, and whether or not they can import, export, or modify information in bulk.
Renamed from Inadequate Logging & Monitoring, we now see the extra descriptive Lack of Safety from Automated Threats class at #8. Malicious bots and different automated assaults make up a big a part of net visitors, and APIs are particularly designed for automated entry, so it’s essential to watch API utilization and have the flexibility to reply if suspicious behaviors are detected. This class isn’t a lot about safety on a technical stage as it’s about figuring out and blocking malicious enterprise logic flows that might lead to undesirable outcomes. A typical (and topical) instance could be a ticket website not stopping bots from instantly shopping for up all of the tickets for a high-profile occasion.
Injection flaws have been moved beneath the broader heading of Unsafe Consumption of APIs (at #10). On this case, “unsafe consumption” refers to utilizing information retrieved from an API with out sanitizing and validating it to the identical normal as user-supplied information. Particularly for communication between APIs (whether or not inner or exterior), there’s a danger that builders will implicitly belief API habits with out checking if it’s safe. Aside from risking injection assaults through unsanitized information, this might additionally create encryption gaps or exhaust utility sources if the consumed useful resource gives information at the next charge than anticipated.
New but very previous: SSRF
The one new class up to now, and in addition the one vulnerability positioned in its personal class, is Server Facet Request Forgery, at present sitting at #6. This mirrors the selection made for the final OWASP Prime 10 in 2021, the place SSRF additionally acquired its personal class for the primary time. Within the context of APIs, server-side request forgery vulnerabilities permit attackers to smuggle URLs by way of an API and trick a back-end server into sending a request to that URL. This class of vulnerabilities will be particularly harmful in trendy utility architectures, the place containerized elements within the cloud usually talk by way of APIs over predictable paths, thus vastly growing the potential for SSRF.
Watch this area
Whereas it might be a while earlier than the ultimate API Safety Prime 10 arrives, the present launch candidate record is unlikely to alter a lot. All the most important danger areas for contemporary APIs are already lined, and the general pattern appears to be in direction of making the classes extra generic for use extra as best-practice tips and fewer as a vulnerability guidelines (which was the method taken for the primary OWASP Prime 10 record in 2021). That stated, the small print and examples supplied for some classes nonetheless range by way of format and depth of element, so it’s probably that work will proceed there. We’ll take an in depth technical have a look at the ultimate record when it arrives, as we did for the 2019 API Safety Prime 10.
