{"id":18416,"date":"2024-02-20T14:37:34","date_gmt":"2024-02-20T14:37:34","guid":{"rendered":"https:\/\/staging2022.42crunch.com\/?p=18416"},"modified":"2024-02-21T10:25:05","modified_gmt":"2024-02-21T10:25:05","slug":"how-to-protect-apis-from-owasp-authorization-risks-bola-bopla-bfla","status":"publish","type":"post","link":"https:\/\/staging2022.42crunch.com\/how-to-protect-apis-from-owasp-authorization-risks-bola-bopla-bfla\/","title":{"rendered":"How to Protect APIs from OWASP Authorization Risks: BOLA, BOPLA & BFLA"},"content":{"rendered":"

The OWASP API Top Risks listing identifies three different Authorization challenges\u00a0<\/b><\/h2>\n

Coding issues relating to Authorization configuration failures continue to present a significant challenge for development and security teams building and protecting APIs. Just read any issue of our fortnightly APIsecurity.io newsletter and you\u2019ll discover that Authorization-based breaches are at the root of a large percentage of the high-profile attacks. Authorization, in its various flavors, presents challenges because any misconfigurations or vulnerabilities can lead to unauthorized access and harmful data breaches.<\/p>\n

In a recent 42Crunch webinar, \u201cTop Things you Need to know about API Security<\/a>” with Isabelle Mauny and Dr. Philippe De Ryck, we explored why Authorization warrants 3 different entries in the OWASP API Top 10, why it is difficult to get right and how organizations should go about implementing Authorization safeguards.<\/p>\n

\"\"<\/p>\n

Figure 1. Authorization entries in the OWASP API Top 10<\/span><\/i><\/p>\n

Authorization Compliance is Complicated<\/h2>\n

Many APIs are characterized by layers of complexity which inevitably leads to a complicated rules logic. Ensuring <\/span>that this logic is accurately implemented <\/span>and determining what the authorization rules should be<\/span> can be challenging.<\/span> It is even doubly difficult to check for compliance once the API has been deployed as there is the added time pressure of racing to review and remediate any holes, before the API is potentially attacked. All an attacker requires is one hole from which to build his attack from. This is why building logic into the APIs during the development phase is a recommended best practice.<\/span><\/p>\n

Philippe De Ryck observed though that when developers are quizzed by security about how they can prove that their Authorization checks work and how they were implemented there tends to be a lot of head scratching and finger crossing. He suggested two ways in which security and engineering developer teams can successfully implement these checks.<\/span><\/p>\n

    \n
  1. Make authorization auditable<\/span><\/li>\n
  2. Define the authorization rules in the OpenAPI contracts and ensure that the APIs enforce that contract and its rules.\u00a0<\/span><\/li>\n<\/ol>\n

    Make Authorization Auditable at Scale<\/h3>\n

    Authorization is undoubtedly a critical aspect of your overall API security posture. But<\/span> without the ability to audit authorization checks in your security policies you will have great difficulty in identifying whether developers have implemented the appropriate checks in the correct places. <\/span><\/p>\n

    The best way to do this is to integrate security measures early in the development lifecycle by giving your developers easy to use API audit and scan testing tools that run in their IDEs and help them implement Authorization best practices as they build their APIs. In parallel, you also need to give your security teams real-time oversight via these tools from within the CI\/CD pipelines to ensure that the authorization requirements are being adhered to.\u00a0<\/span><\/p>\n

     <\/p>\n

    \"\"<\/p>\n

    Figure 2. 42Crunch audits & scans Authorization checks inside the development IDE<\/span><\/i><\/p>\n

    OWASP Authorization Issues<\/h3>\n

    The OWASP API Authorization challenges are identified next and how 42Crunch can help companies address them.<\/span><\/p>\n

    \"\"<\/p>\n

    Figure 3. \u00a0Different levels of API Authorization: Functional, Object and Object-Property<\/p>\n

    Broken Object Level Authorization (BOLA)<\/strong><\/h4>\n

    BOLA relates to a flaw or weakness in the implementation of object-level authorization within an API. It means that the API doesn’t adequately verify and enforce the permissions associated with a specific object, allowing unauthorized users to access or modify it.\u00a0<\/span><\/p>\n

    Risk<\/b>: Attacker substitutes the ID of their own resource in the API call with an ID of a resource belonging to another user. Lack of proper authorization checks allows attackers to access the specified resource.\u00a0<\/span><\/p>\n

    Fix: <\/b><\/p>\n