From 24e3be4021cd64bbdf29009a48c40ec350878594 Mon Sep 17 00:00:00 2001
From: Inon Shkedy <31135573+inonshk@users.noreply.github.com>
Date: Mon, 2 Sep 2019 22:47:53 -0700
Subject: [PATCH] A1 update name and add recommendation

A1 update name and add recommendation
---
 .../0xa1-missing-object-level-access-control.md    | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/2019/en/src/0xa1-missing-object-level-access-control.md b/2019/en/src/0xa1-missing-object-level-access-control.md
index 759501b97..8d25447ec 100644
--- a/2019/en/src/0xa1-missing-object-level-access-control.md
+++ b/2019/en/src/0xa1-missing-object-level-access-control.md
@@ -1,19 +1,19 @@
-A1:2019 Missing Object Level Access Control
+A1:2019 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 access control by manipulating the ID of an object that is sent in the request. This may 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 wide-spread. 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. |
+| Attackers can exploit API endpoints that are vulnerable to broken object authorization by manipulating the ID of an object that is sent in the request. This may 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 wide-spread. 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 access control is a mechanism that is usually implemented at the code
+Object level authorization is a mechanism that is usually implemented at the code
 level to validate that one user can access only objects that they should have
 access to.
 
 Every API endpoint that receives an ID of an object and performs any type of
-action on the object should implement object level access control checks. The
+action on the object should implement object level authorization checks. The
 checks should validate that the logged-in user does have access to perform the
 requested action on the requested object.
 
@@ -42,15 +42,17 @@ other user account data.
 
 ## How To Prevent
 
-* Implement a proper access control mechanism that relies on the user policies
+* Implement a proper authorization mechanism that relies on the user policies
   and hierarchy.
 * Prefer not to use an ID that has been sent from the client, but instead use an
   ID that is stored in the session object when accessing a database record by
   the record ID.
-* Use an access control mechanism to check if the logged in user has access to
+* Use an authorization mechanism to check if the logged in user has access to
   perform the requested action on the record in every function that uses an
   input from the client to access a record in the database.
 * Prefer to use random and unpredictable values as GUIDs for records’ IDs.
+* Write tests to evaluate the authorization mechanism. Do not deploy vulnerable
+changes that break the tests.
 
 ## References