Add a section for checking if the server responds with sensitive information.

[pinkLagoon]

What would you like added?
We sometimes see that developers might just serialize an entire object into JSON and returns it in a API response. Sometimes this object contains sensitive information. I personally have seen passwords and API keys being displayed. I think this will fall under the new 4.12 API Testing section.

Would you like to be assigned to this issue?
I might later. If someone beats me to it that will be good.

[ThunderSon]

I highly believe this goes beyond API testing.
I just noticed the guide doesn't tackle that point, CWE 200 and similar vectors.
@kingthorin what do you think about this? Top 10 A3 (sensitive data exposure) is just referenced when data is sent unencrypted, but the guide in no way discusses "more" data being sent back to the user.
Would be interesting to find a home for it.

Nice catch @pinkLagoon!

[kingthorin]

Yup this is definitely something we need to tackle. I've definitely seen apps in the past that returned JSON or XML responses that contained more data than displayed to the user.

[ThunderSon]

This is currently being reviewed to see on how many stages this can be added.

1. Potentially dangerous data (testing topic)
2. Benign data -- cultural and leads to maturity (early chapters topic)

Talking with @elarlang ASVS doesn't have clear directions on that topic as well.

[github-actions]

Please comment if you are still working on this issue, as it has been inactive for 30 days. To give everyone a chance to contribute, we are releasing it to new contributors.

[github-actions]

Please comment if you are still working on this issue, as it has been inactive for 90 days. To give everyone a chance to contribute, we are releasing it to new contributors.

[github-actions]

Please comment if you are still working on this issue, as it has been inactive for 90 days. To give everyone a chance to contribute, we are releasing it to new contributors.

[elarlang]

Talking with @elarlang ASVS doesn't have clear directions on that topic as well.

The solution in ASVS - added a requirement in the "defensive coding" section:

Verify that the application returns only the data the user has permission to access. For example, the API response does not return a full object with attributes that contain values the user has no permission to access although having permission to access the data object.