OWASP · PauloASilva · May 3, 2023
diff --git a/2023/en/src/0xa1-broken-object-level-authorization.md b/2023/en/src/0xa1-broken-object-level-authorization.md
@@ -1,11 +1,6 @@
 API1:2023 Broken Object Level Authorization
 ===========================================
 
-| Threat agents/Attack vectors | Security Weakness | Impacts |
-| - | - | - |
-| API Specific : Exploitability **3** | Prevalence **3** : Detectability **2** | Technical **3** : Business Specific |
-| Attackers can exploit API endpoints that are vulnerable to broken object level authorization by manipulating the ID of an object that is sent within the request. This can lead to unauthorized access to sensitive data. This issue is extremely common in API-based applications because the server component usually does not fully track the client's state, and instead, relies more on parameters like object IDs, that are sent from the client to decide which objects to access. | This has been the most common and impactful attack on APIs. Authorization and access control mechanisms in modern applications are complex and widespread. Even if the application implements a proper infrastructure for authorization checks, developers might forget to use these checks before accessing a sensitive object. Access control detection is not typically amenable to automated static or dynamic testing. | Unauthorized access can result in data disclosure to unauthorized parties, data loss, or data manipulation. Unauthorized access to objects can also lead to full account takeover. |
-
 ## Is the API Vulnerable?
 
 Object level authorization is an access control mechanism that is usually

diff --git a/2023/en/src/0xa2-broken-authentication.md b/2023/en/src/0xa2-broken-authentication.md
@@ -1,14 +1,10 @@
 API2:2023 Broken Authentication
 ===============================
 
-| Threat agents/Attack vectors | Security Weakness | Impacts |
-| - | - | - |
-| API Specific : Exploitability **3** | Prevalence **2** : Detectability **2** | Technical **3** : Business Specific |
-| Authentication in APIs is a complex and confusing mechanism. Software and security engineers might have misconceptions about what are the boundaries of authentication and how to implement it correctly. In addition, the authentication mechanism is an easy target for attackers, since it's exposed to everyone. These two points make the authentication component potentially vulnerable to many exploits. | There are two sub-issues: 1. Lack of protection mechanisms: API endpoints that are responsible for authentication must be treated differently from regular endpoints and implement extra layers of protection; 2. Misimplementation of the mechanism: The mechanism is used / implemented without considering the attack vectors, or for the wrong use case (e.g. an authentication mechanism designed for IoT clients might not be the right choice for web applications). | Attackers can gain control of other users' accounts in the system, read their personal data, and perform sensitive actions on their behalf, like money transactions and sending personal messages. |
-
 ## Is the API Vulnerable?
 
-Authentication endpoints and flows are assets that need to be protected. Additionally, "Forgot password / reset password" should be treated the same way
+Authentication endpoints and flows are assets that need to be protected.
+Additionally, "Forgot password / reset password" should be treated the same way
 as authentication mechanisms.
 
 An API is vulnerable if it:

diff --git a/2023/en/src/0xa3-broken-object-property-level-authorization.md b/2023/en/src/0xa3-broken-object-property-level-authorization.md
@@ -1,11 +1,6 @@
 API3:2023 Broken Object Property Level Authorization
 ====================================================
 
-| Threat agents/Attack vectors | Security Weakness | Impacts |
-| - | - | - |
-| API Specific : Exploitability **3** | Prevalence **2** : Detectability **2** | Technical **2** : Business Specific |
-|  Attackers can exploit API endpoints that are vulnerable to broken object property level authorization by reading or changing values of object properties they are not supposed to access. | Authorization in APIs is done in layers. While developers might perform proper validations to make sure that a user has access to a function, and then to a specific object, they often don't validate if the user is allowed to access a specific property within the object. | Unauthorized access can result in data disclosure to unauthorized parties, data loss, or data manipulation. |
-
 ## Is the API Vulnerable?
 
 When allowing a user to access an object using an API endpoint, it is important

diff --git a/2023/en/src/0xa4-unrestricted-resource-consumption.md b/2023/en/src/0xa4-unrestricted-resource-consumption.md
@@ -1,11 +1,6 @@
 API4:2023 Unrestricted Resource Consumption
 ===========================================
 
-| Threat agents/Attack vectors | Security Weakness | Impacts |
-| - | - | - |
-| API Specific : Exploitability **2** | Prevalence **3** : Detectability **3** | Technical **2** : Business Specific |
-| Exploitation requires simple API requests. Multiple concurrent requests can be performed from a single local computer or by using cloud computing resources. | It's common to find APIs that do not limit client interactions or resource consumptions. Although most of the time interactions are logged, due to the lack of monitoring,  or improper monitoring, malicious activity passes unnoticed. | Exploitation can lead to DoS due to resource starvation, but it can also impact service providers' billing. |
-
 ## Is the API Vulnerable?
 
 Satisfying API requests requires resources such as network bandwidth, CPU,

diff --git a/2023/en/src/0xa5-broken-function-level-authorization.md b/2023/en/src/0xa5-broken-function-level-authorization.md
@@ -1,11 +1,6 @@
 API5:2023 Broken Function Level Authorization
 =============================================
 
-| Threat agents/Attack vectors | Security Weakness | Impacts |
-| - | - | - |
-| API Specific : Exploitability **3** | Prevalence **2** : Detectability **1** | Technical **2** : Business Specific |
-| Exploitation requires the attacker to send legitimate API calls to the API endpoint that they should not have access to. These endpoints might be exposed to anonymous users or regular, non-privileged users. It's easier to discover these flaws in APIs since APIs are more structured, and the way to access certain functions is more predictable (e.g. replacing the HTTP method from GET to PUT, or changing the "users" string in the URL to "admins"). | Authorization checks for a function or resource are usually managed via configuration, and sometimes at the code level. Implementing proper checks can be a confusing task since modern applications can contain many types of roles or groups and complex user hierarchies (e.g.  sub-users, or users with more than one role). Detection relies on proper logging and monitoring. | Such flaws allow attackers to access unauthorized functionality. Administrative functions are key targets for this type of attack. |
-
 ## Is the API Vulnerable?
 
 The best way to find broken function level authorization issues is to perform
@@ -25,8 +20,8 @@ Don't assume that an API endpoint is regular or administrative only based on
 the URL path.
 
 While developers might choose to expose most of the administrative endpoints
-under a specific relative path, like `/api/admins`, it's very common to find these
-administrative endpoints under other relative paths together with regular
+under a specific relative path, like `/api/admins`, it's very common to find
+these administrative endpoints under other relative paths together with regular
 endpoints, like `/api/users`.
 
 ## Example Attack Scenarios

diff --git a/2023/en/src/0xa6-server-side-request-forgery.md b/2023/en/src/0xa6-server-side-request-forgery.md
@@ -1,11 +1,6 @@
 API6:2023 Server Side Request Forgery
 =====================================
 
-| Threat agents/Attack vectors | Security Weakness | Impacts |
-| - | - | - |
-| API Specific : Exploitability **2** | Prevalence **2** : Detectability **1** | Technical **2** : Business Specific |
-| Exploitation requires the attacker to find an API endpoint that receives a URI as a parameter and then accesses the provided URI. URL parsing inconsistencies are well-known for most common programming languages' built-in functions and libraries. | Modern concepts in application development encourage developers to access URIs provided by the client. Usually, server-side data retrieval is not logged, or when it is chances are it isn't being monitored. | Successful exploitation might lead to internal services enumeration (e.g. port scanning) or information disclosure, bypassing firewalls or other security mechanisms. In some cases, it can lead to DoS or the server being used as a proxy to hide malicious activities. |
-
 ## Is the API Vulnerable?
 
 Server-Side Request Forgery (SSRF) flaws occur whenever an API is fetching a

diff --git a/2023/en/src/0xa7-security-misconfiguration.md b/2023/en/src/0xa7-security-misconfiguration.md
@@ -1,11 +1,6 @@
 API7:2023 Security Misconfiguration
 ===================================
 
-| Threat agents/Attack vectors | Security Weakness | Impacts |
-| - | - | - |
-| API Specific : Exploitability **3** | Prevalence **3** : Detectability **3** | Technical **2** : Business Specific |
-| Attackers will often attempt to find unpatched flaws, common endpoints, or unprotected files and directories to gain unauthorized access or knowledge of the system. | Security misconfiguration can happen at any level of the API stack, from the network level to the application level. Automated tools are available to detect and exploit misconfigurations such as unnecessary services or legacy options. | Security misconfigurations can not only expose sensitive user data, but also system details that can lead to full server compromise. |
-
 ## Is the API Vulnerable?
 
 The API might be vulnerable if:

diff --git a/2023/en/src/0xa8-lack-of-protection-from-automated-threats.md b/2023/en/src/0xa8-lack-of-protection-from-automated-threats.md
@@ -1,11 +1,6 @@
 API8:2023 Lack of Protection from Automated Threats
 ===================================================
 
-| Threat agents/Attack vectors | Security Weakness | Impacts |
-| - | - | - |
-| API Specific : Exploitability **3** | Prevalence **3** : Detectability **1** | Technical **1** : Business Specific |
-| Exploitation usually involves understanding of the business model of the API, finding sensitive business flows, and automating access to these flows, causing harm to the business.  | When broken down, each of an attack's requests represent a completely legitimate request and cannot be identified as an attack. An attack can be identified only when looking at the sum of the requests in regards to the service/application business logic. | In general technical impact is not expected. Exploitation might hurt the business in different ways, for example: 1. Prevent legitimate users from purchasing a product; 2. Lead to inflation in the internal economy of a game; 3. Allow the attacker to send excessive amounts of messages/comments and easily spread fake news. |
-
 ## Is the API Vulnerable?
 
 Automated threats have become more profitable, smarter and harder to protect

diff --git a/2023/en/src/0xa9-improper-inventory-management.md b/2023/en/src/0xa9-improper-inventory-management.md
@@ -1,11 +1,6 @@
 API9:2023 Improper Inventory Management
 =======================================
 
-| Threat agents/Attack vectors | Security Weakness | Impacts |
-| - | - | - |
-| API Specific : Exploitability **3** | Prevalence **3** : Detectability **2** | Technical **2** : Business Specific |
-| Threat agents usually get unauthorized access through old API versions or endpoints left running unpatched and  using weaker security requirements. Alternatively, they may get access to sensitive data through a 3rd party with whom there's no reason to share data with. | Outdated documentation makes it more difficult to find and/or fix vulnerabilities. Lack of assets inventory and retirement strategies leads to running unpatched systems, resulting in leakage of sensitive data. It's common to find unnecessarily exposed API hosts because of modern concepts like microservices, which make applications easy to deploy and independent (e.g. cloud computing, K8S). | Attackers can gain access to sensitive data, or even take over the server, through old, unpatched API versions connected to the same database. |
-
 ## Is the API Vulnerable?
 
 The sprawled and connected nature of APIs and modern applications brings new

diff --git a/2023/en/src/0xaa-unsafe-consumption-of-apis.md b/2023/en/src/0xaa-unsafe-consumption-of-apis.md
@@ -1,11 +1,6 @@
 API10:2023 Unsafe Consumption of APIs
 =====================================
 
-| Threat agents/Attack vectors | Security Weakness | Impacts |
-| - | - | - |
-| API Specific : Exploitability **2** | Prevalence **2** : Detectability **1** | Technical **3** : Business Specific |
-| Developers tend to trust but not verify in their endpoints which interact with external or third-party APIs. Successful exploitation of security flaws in these APIs can impact those relying on them. | Usually, API integrations rely on weaker security requirements such as those regarding transport security, authentication/authorization, and input validation and sanitization. | Exposure of sensitive information to unauthorized actors and many kinds  of injections are common issues. |
-
 ## Is the API Vulnerable?
 
 Developers tend to trust data received from third-party APIs more than user