Update 0xa3-excessive-data-exposure.md

We can't ask developers to define and enforce all data returned by all API methods.
It's like asking "Implement input validation on every single input on the system" - for many companies it won't be a feasible solution.

As security engineers who provide recommendations for the broad community, we should always keep in mind the trade off between security and the available resources of the company that uses OWASP to improve the security posture.We should always assume that companies have limited resources.

With this mindset, OWASP has been provided recommendations for many years.
Recommendations like "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." don't align with this mindset.

The second part of the last recommendation already appears in the second recommendation.

Author: inonshk

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

@@ -42,12 +42,11 @@ 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. 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.
+* Use generis methods like "to_json" and "to_string" from the ORM / Model level 
+  carefully. Backend engineers should always ask themselves "who is the consumer
+  of the returned data?"
+* Classify sensitive and personally identifiable information (PII) that your
+  application stores and works.
 
 ## References