OWASP top 10 -Sensitive Data Exposure

As per apigee docs for top 10 OWASP indicates following OWASP, have question on listed two OWASP

As per " A3:2017 - Sensitive Data Exposure" indicates following

Use standard OAuth techniques and consider adding HMAC, hash, state, nonce, PKCE, or other techniques to improve the level of authentication for each request.

Does this relates to Hashing token ? link indicated "Hashing tokens for extra security" or relates to other aspect ? we are using OAUTH token not the JWT token. Any inputs ?

0 5 462
5 REPLIES 5

No, this is not related to hashing tokens. It's about additional techniques, in addition to standard OAuth techniques, that you can use.

Each of these is a separate technique (or range of techniques) that would require a detailed explanation. See eg, https://auth0.com/docs/protocols/oauth2/oauth-state for state, or https://www.oauth.com/oauth2-servers/pkce/ for PKCE.

@Christian King Thanks for response., have couple of question.

Q1: Does or means one of either " Mitigate CSRF Attacks with State Parameters" or "Protecting Mobile Apps with PKCE" one of this is fine not both ?

Q2: : If we are only using OAUTH Client credentials (system to System only) without human login or interaction, then both are not required ?, meaning "A3:2017 - Sensitive Data Exposure" indicates following" is not required in such cases ?

Please confirm my intial understanding

1) Both of the links I posted are examples of things that would help you protect against A3:2017 - Sensitive Data Exposure. Which, and how many of these are necessary for your needs will depend on your use case.

2) The OWASP Top 10 is a list of vulnerabilities (or categories of vulnerabilities) rather than a prescriptive list of solutions to implement. The Apigee page you listed is a list of suggestions of how Apigee can assist, but it's neither exhaustive nor prescriptive.

Most of the solutions listed assume you're not using client-credentials, and so may not be appropriate for your environment, but that doesn't mean you should not consider this vulnerability. Personally, I'd be inclined to look at mTLS auth as a more secure alternative than client credentials for this usecase.

Thanks for update @Christian King