Various recommendations

2019/en/src/0xa3-excessive-data-exposure.md

@@ -42,6 +42,8 @@ the site.
 * Never rely on the client side to perform sensitive data filtering.
 * Review the responses from the API to make sure they contain only legitimate
   data.
+* Explicitly define and enforce data returned by all API methods including errors: give all JSON objects schemas, all string objects patterns, use clear field names.
+* Define all sensitive and personally identifiable information (PII) that your application stores and works with and review all API calls returning such information to see if these responses can be a security issue.
 
 ## References
 

2019/en/src/0xa4-lack-of-resources-and-rate-limiting.md

@@ -49,11 +49,14 @@ errors.
   [file descriptors, and processes][4].
 * Implement a limit on how often a client can call the API within a defined
   timeframe.
+* For sensitive operations such as login or password reset, consider rate limits by API method (for example, authentication), client (for example, IP address), property (for example, username).
 * Notify the client when the limit is exceeded by providing the limit number and
   the time at which the limit will be reset.
 * Add proper server-side validation for query string and request body
   parameters, specifically the one that controls the number of records to be
   returned in the response.
+* Define and enforce maximum size of data on all incoming parameters and payloads such as maximum length for strings and maximum number of elements in arrays.
+* If your API accepts zip files check compression ratios before expanding the files to protect yourself against "zip bombs".
 
 ## References
 

2019/en/src/0xa5-broken-function-level-authorization.md

@@ -4,7 +4,7 @@ A5:2019 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 hierarchy (e.g., sub-users, users with more than one role). | Such flaws allow attackers to access unauthorized functionality. Administrative functions are key targets for this type of attack. |
+| 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", or changing the value of a parameter like "is_admin" from "false" to "true"). | 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 hierarchy (e.g., sub-users, users with more than one role). | Such flaws allow attackers to access unauthorized functionality. Administrative functions are key targets for this type of attack. |
 
 ## Is the API Vulnerable?
 

2019/en/src/0xa6-mass-assignment.md

@@ -75,6 +75,7 @@ shell command injection once the attacker downloads the video as MP4.
 * Whitelist only the properties that should be updated by the client.
 * Use built-in features to blacklist properties that should not be accessed by
   clients.
+* In API contracts, explicitly define and enforce schemas for all JSON payloads.
 
 ## References
 

2019/en/src/0xa7-security-misconfiguration.md

@@ -4,7 +4,7 @@ A7:2019 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 no only expose sensitive user data, but also system details that may lead to full server compromise. |
+| 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 may lead to full server compromise. |
 
 ## Is the API Vulnerable?
 
@@ -65,6 +65,7 @@ The API life cycle should include:
   assets (e.g., images).
 * An automated process to continuously assess the effectiveness of the
   configuration and settings in all environments.
+* To prevent exception traces and other valuable information from being sent back to attackers, define and enforce all API response payload schemas including error responses.
 
 ## References
 

2019/en/src/0xa8-injection.md

@@ -33,7 +33,7 @@ The attacker replays the request with a different payload
 
 ```
 POST /api/account/recovery
-{"email": "[email protected]';WAITFOR DELAY '0:0:5'--"}
+{"username": "[email protected]';WAITFOR DELAY '0:0:5'--"}
 ```
 
 This time, the response took ~5 seconds confirming the API is vulnerable to SQL
@@ -103,6 +103,8 @@ Preventing injection requires keeping data separate from commands and queries.
   of injection.
 * Validate incoming data using sufficient filters to only allow valid values for
   each input parameter.
+* To prevent data leaks, define and enforce schemas for all API responses.
+* Define data types and strict patterns for all string parameters.
 
 ## References
 

2019/en/src/0xa9-improper-assets-management.md

@@ -61,6 +61,9 @@ user by using a simple brute-force to guess the 6 digits token.
 * Generate documentation automatically by adopting open standards. Include the
   documentation build in your CI/CD pipeline.
 * Make API documentation available to those authorized to use the API.
+* Use external protection measures such as API security firewalls for all exposed versions of your APIs, not just for the current production version.
+* Avoid using production data with non-production API deployments. If this is unavoidable, these endpoints should get the same security treatment as the production ones.
+* When newer versions of APIs include security improvements, perform risk analysis to make the decision of the mitigation actions required for the older version: for example, whether it is possible to backport the improvements without breaking API compatibility or you need to take the older version out quickly and force all clients to move to the latest version.
 
 ## References
 

2019/en/src/0xb0-next-devs.md

@@ -15,7 +15,7 @@ comprehensive list of available projects.
 
 | | |
 |-|-|
-| **Education** | You can start reading [OWASP Education Project materials][2] according to your profession and interest. For hands-on learning, we added **crAPI** - **C**ompletely **R**idiculous **API** on [our roadmap][3]. Meanwhile, you can practice WebAppSec using the [OWASP DevSlop Pixi Module][4], a vulnerable WebApp and API service intent to teach users how to test modern web applications and API's for security issues, and how to write more secure API's in the future. You can also attend [OWASP AppSec Conference][5] training sessions, or [join your local chapter][6]. |
+| **Education** | You can start reading [OWASP Education Project materials][2] according to your profession and interest. For hands-on learning, we added **crAPI** - **C**ompletely **R**idiculous **API** on [our roadmap][3]. Meanwhile, you can practice WebAppSec using the [OWASP DevSlop Pixi Module][4], a vulnerable WebApp and API service intent to teach users how to test modern web applications and API's for security issues, and how to write more secure API's in the future. You can also attend [OWASP AppSec Conference][5] training sessions, or [join your local chapter][6]. Read about the latest API vulnerabilities and breaches at [APIsecurity.io][15]|
 | **Security Requirements** | Security should be part of every project from the beginning. When doing requirements elicitation, it is important to define what "secure" means for that project. OWASP recommends you use the [OWASP Application Security Verification Standard (ASVS)][7] as a guide for setting the security requirements. If you're outsourcing, consider the [OWASP Secure Software Contract Annex][8], which should be adapted according to local law and regulations. |
 | **Security Architecture** | Security should remain a concern during all the project stages. The [OWASP Prevention Cheat Sheets][9] are a good starting point for guidance on how to design security in during the architecture phase. Among many others, you'll find the [REST Security Cheat Sheet][10] and the [REST Assessment Cheat Sheet][11]. |
 | **Standard Security Controls** | Adopting Standard Security Controls reduces the risk of introducing security weaknesses while writing your own logic. Despite the fact that many modern frameworks now come with built-in standard effective controls, [OWASP Proactive Controls][12] gives you a good overview of what security controls you should look to include in your project. OWASP also provides some libraries and tools you may find valuable, such as validation controls. |
@@ -35,3 +35,4 @@ comprehensive list of available projects.
 [12]: https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=OWASP_Proactive_Controls_2018
 [13]: https://www.owasp.org/index.php/OWASP_SAMM_Project
 [14]: https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project
+[15]: https://APIsecurity.io

CONTRIBUTING.md

@@ -24,7 +24,7 @@ follow the steps below:
 1. Fork this repository to your account
 2. Clone your copy of this repository, locally
    ```
-   git clone git@github.com:YOU/API-Security-Top-10.git
+   git clone https://github.com/YOU/API-Security.git
    ```
 3. Create a new branch based on `develop` (e.g. `fix/foreword-section`)
    ```