diff --git a/2019/en/src/0xa3-excessive-data-exposure.md b/2019/en/src/0xa3-excessive-data-exposure.md
index 30a39b2c7..2d7ab4c71 100644
--- a/2019/en/src/0xa3-excessive-data-exposure.md
+++ b/2019/en/src/0xa3-excessive-data-exposure.md
@@ -39,15 +39,20 @@ the site.
 
 ## How To Prevent
 
-* Never rely on the client side to perform sensitive data filtering.
+* Never rely on the client side to filter sensitive data.
 * 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. Whenever possible: use schemas for responses, patterns for all strings
-  and 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.
+* Backend engineers should always ask themselves "who is the 
+  consumer of the data?" before exposing a new API endpoint.
+* Avoid using generic methods such as to_json() and to_string(). 
+  Instead, cherry-pick specific properties you really want to return
+* Classify sensitive and personally identifiable information (PII) that 
+  your application stores and works with, reviewing all API calls returning such
+  information to see if these responses pose a security issue.
+* Implement a schema-based response validation mechanism as an extra layer of 
+  security. As part of this mechanism define and enforce data returned by all API 
+  methods, including errors.
+  
 
 ## References
 
diff --git a/2019/en/src/0xa4-lack-of-resources-and-rate-limiting.md b/2019/en/src/0xa4-lack-of-resources-and-rate-limiting.md
index 127e5dfe2..608ee2454 100644
--- a/2019/en/src/0xa4-lack-of-resources-and-rate-limiting.md
+++ b/2019/en/src/0xa4-lack-of-resources-and-rate-limiting.md
@@ -49,9 +49,6 @@ 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 (e.g., authentication), client (e.g., IP address), property
-  (e.g., 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
@@ -60,8 +57,7 @@ errors.
 * 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 compressed files check compression ratios before expanding
-  the files to protect yourself against "zip bombs".
+
 
 ## References
 
diff --git a/2019/en/src/0xa5-broken-function-level-authorization.md b/2019/en/src/0xa5-broken-function-level-authorization.md
index d4ee7a7c0..2f5f729d0 100644
--- a/2019/en/src/0xa5-broken-function-level-authorization.md
+++ b/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", 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. |
+| 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. |
 
 ## Is the API Vulnerable?
 
diff --git a/2019/en/src/0xa8-injection.md b/2019/en/src/0xa8-injection.md
index c5729b6a6..f08179333 100644
--- a/2019/en/src/0xa8-injection.md
+++ b/2019/en/src/0xa8-injection.md
@@ -103,7 +103,6 @@ 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