Final proofreading

Fix typos, langauge, etc.

Author: ErezYalon

2019/en/src/0x00-notice.md

@@ -4,7 +4,7 @@ Notice
 This is the text version of OWASP API Security Top 10, used as source for the
 official version distributed as a Portable Document Format (PDF).
 
-Contributions to the project such as comments, corrections or translations
+Contributions to the project such as comments, corrections, or translations
 should be done here. For details on [How To Contribute][1], please refer to
 [CONTRIBUTING.md][1].
 

2019/en/src/0x02-foreword.md

@@ -13,7 +13,7 @@ become a target for attackers. Without secure APIs, rapid innovation would be
 impossible.
 
 Although a broader web application security risks Top 10 still makes sense, due
-to their particular nature, an API specific security risks list is required.
+to their particular nature, an API-specific security risks list is required.
 API security focuses on strategies and solutions to understand and mitigate the
 unique vulnerabilities and security risks associated with APIs.
 

2019/en/src/0x03-introduction.md

@@ -20,7 +20,7 @@ architects, managers, or organizations.
 In the [Methodology and Data][2] section, you can read more about how this first
 edition was created. In future versions, we want to involve the security
 industry, with a public call for data. For now, we encourage everyone to
-contribute with questions, comments and ideas at our [GitHub repository][3] or
+contribute with questions, comments, and ideas at our [GitHub repository][3] or
 [Mailing list][4].
 
 [1]: https://www.owasp.org/index.php/OWASP_API_Security_Project

2019/en/src/0x04-release-notes.md

@@ -10,13 +10,13 @@ section, you'll find more details about how this version was built. For more
 details about the security risks, please refer to the [API Security Risks][2]
 section.
 
-It is important to realize that over the last few years, applications'
-architecture has significantly changed. Currently, APIs play a very important
+It is important to realize that over the last few years, architecture of 
+applications has significantly changed. Currently, APIs play a very important
 role in this new architecture of microservices, Single Page Applications (SPAs),
 mobile apps, IoT, etc.
 
 The OWASP API Security Top 10 was a required effort to create awareness about
-modern APIs security issues. It was only possible due to a great effort of
+modern API security issues. It was only possible due to a great effort of
 several volunteers, all of them listed in the [Acknowledgments][3] section.
 Thank you!
 

2019/en/src/0x11-t10.md

@@ -10,6 +10,6 @@ OWASP Top 10 API Security Risks – 2019
 | API5:2019 - Broken Function Level Authorization | Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers gain access to other users’ resources and/or administrative functions. |
 | API6:2019 - Mass Assignment | Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on a whitelist, usually lead to Mass Assignment. Either guessing objects properties, exploring other API endpoints, reading the documentation, or providing additional object properties in request payloads, allows attackers to modify object properties they are not supposed to. |
 | API7:2019 - Security Misconfiguration | Security misconfiguration is commonly a result of unsecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information. |
-| API8:2019 - Injection | Injection flaws, such as SQL, NoSQL, Command Injection, etc. occur when untrusted data is sent to an interpreter as part of a command or query. The attacker's malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization. |
+| API8:2019 - Injection | Injection flaws, such as SQL, NoSQL, Command Injection, etc., occur when untrusted data is sent to an interpreter as part of a command or query. The attacker's malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization. |
 | API9:2019 - Improper Assets Management | APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. Proper hosts and deployed API versions inventory also play an important role to mitigate issues such as deprecated API versions and exposed debug endpoints. |
 | API10:2019 - Insufficient Logging & Monitoring | Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems to tamper with, extract, or destroy data. Most breach studies demonstrate the time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring. |

2019/en/src/0xa2-broken-user-authentication.md

@@ -15,13 +15,13 @@ mechanisms.
 An API is vulnerable if it:
 * Permits [credential stuffing][1] whereby the attacker has a list of valid
   usernames and passwords.
-* Permits attackers to perform a brute force attack on the same user, without
-  presenting captcha / account lockout mechanism.
+* Permits attackers to perform a brute force attack on the same user account, without
+  presenting captcha/account lockout mechanism.
 * Permits weak passwords.
-* Sends sensitive authentication details, such as auth tokens and password in
+* Sends sensitive authentication details, such as auth tokens and passwords in
   the URL.
 * Doesn’t validate the authenticity of tokens.
-* Accepts unsigned / weakly signed JWT tokens (`"alg":"none"`) / doesn’t
+* Accepts unsigned/weakly signed JWT tokens (`"alg":"none"`)/doesn’t
   validate their expiration date.
 * Uses plain text, encrypted, or weakly hashed passwords.
 * Uses weak encryption keys.
@@ -48,23 +48,23 @@ within a few minutes.
 ## How To Prevent
 
 * Make sure you know all the possible flows to authenticate to the API (mobile/
-  web/deep links that implement one-click authentication/etc)
+  web/deep links that implement one-click authentication/etc.)
 * Ask your engineers what flows you missed.
 * Read about your authentication mechanisms. Make sure you understand what and
-  how they are used. OAuth is not authentication, and neither API keys .
+  how they are used. OAuth is not authentication, and neither is API keys.
 * Don't reinvent the wheel in authentication, token generation, password
   storage. Use the standards.
-* Credential recovery / forget password endpoints should be treated as login
-  endpoints in terms of brute force, rate limiting and lockout protections.
+* Credential recovery/forget password endpoints should be treated as login
+  endpoints in terms of brute force, rate limiting, and lockout protections.
 * Use the [OWASP Authentication Cheatsheet][3]
 * Where possible, implement multi-factor authentication.
 * Implement anti brute force mechanisms to mitigate credential stuffing,
-  dictionary attack and brute force attacks on your authentication endpoints.
-  This mechanism should be  stricter than the regular rate limiting mechanism on
+  dictionary attack, and brute force attacks on your authentication endpoints.
+  This mechanism should be stricter than the regular rate limiting mechanism on
   your API.
 * Implement [account lockout][4] / captcha mechanism to prevent brute force
   against specific users. Implement weak-password checks.
-* API keys should not be used for user authentication, but for [client app /
+* API keys should not be used for user authentication, but for [client app/
   project authentication][5].
 
 ## References

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

@@ -18,7 +18,7 @@ of the following limits is missing or set inappropriately (e.g., too low/high).
 * Max allocable memory
 * Number of file descriptors
 * Number of processes
-* Request payload size (e.g. uploads)
+* Request payload size (e.g., uploads)
 * Number of requests per client/resource
 * Number of records per page to return in a single request response
 

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

@@ -47,7 +47,7 @@ personal preferences, and authentication data.
 
 Inspecting traffic of a mobile application an attacker finds out that not all
 HTTP traffic is performed on a secure protocol (e.g., TLS). The attacker finds
-this to be true, specifically for the download of  profile images. As user
+this to be true, specifically for the download of profile images. As user
 interaction is binary, despite the fact that API traffic is performed on a
 secure protocol, the attacker finds a pattern on API responses size, which he
 uses to track user preferences over the rendered content (e.g., profile images).
@@ -73,7 +73,7 @@ Furthermore:
   schemas including error responses.
 * Ensure API can only be accessed by the specified HTTP verbs. All other HTTP
   verbs should be disabled (e.g. `HEAD`).
-* APIs expecting to be accessed from browser-based clients (e.g. WebApp
+* APIs expecting to be accessed from browser-based clients (e.g., WebApp
   front-end) should implement a proper Cross-Origin Resource Sharing (CORS)
   policy.
 

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

@@ -30,7 +30,7 @@ The API might be vulnerable if:
 ### Scenario #1
 
 After redesigning their applications, a local search service left an old API
-version (`api.someservice.com/v1`) running, unprotected and with access to the
+version (`api.someservice.com/v1`) running, unprotected, and with access to the
 user database. While targeting one of the latest released applications, an
 attacker found the API address (`api.someservice.com/v2`). Replacing `v2` with
 `v1` in the URL gave the attacker access to the old, unprotected API,

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

@@ -1,7 +1,7 @@
 What's Next For Developers
 ==========================
 
-The task to create and maintain secure software, or fixing existing ones, can be
+The task to create and maintain secure software, or fixing existing sofware, can be
 difficult. APIs are no different.
 
 We believe that education and awareness are key factors to write secure
@@ -19,7 +19,7 @@ comprehensive list of available projects.
 | **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. |
-| **Secure Software Development Life Cycle** | You can use the [OWASP Software Assurance Maturity Model (SAMM)][13] to improve the process when building APIs. Several other OWASP projects are available to help you during the different API development phase,s e.g., the [OWASP Code Review Project][14]. |
+| **Secure Software Development Life Cycle** | You can use the [OWASP Software Assurance Maturity Model (SAMM)][13] to improve the process when building APIs. Several other OWASP projects are available to help you during the different API development phases e.g., the [OWASP Code Review Project][14]. |
 
 [1]: https://www.owasp.org/index.php/Category:OWASP_Project
 [2]: https://www.owasp.org/index.php/OWASP_Education_Material_Categorized