encoded sensitive data (such as JWT) should not be logged

[elarlang]

access_token (also id_token) JWT may contain relatively sensitive information, such as person's full name, SSN, email, phone, address, etc.

At the same time, those are sent via URL parameters - that means JWT content is logged everywhere to access logs, browser history etc.

If we could put all this information as plain text to URL parameters, everyone would understand, it's nonsense to send information like a person's full name, SSN, email, phone, and address as URL parameters. If it is inside JWT, it's the same, just base64 encoded.

I know, there is OAuth response_mode=query, and I know there is OIDC logout id_token_hint - this is actually one reason to address this problem. The problem exists for both when the browser communicates directly with the authorization server or IdP.

At the moment we have requirements:

#	Description	L1	L2	L3	CWE
7.1.1	Verify that the application does not log credentials or payment details. Session tokens should only be stored in logs in an irreversible, hashed form.	✓	✓	✓	532
8.2.2	[MODIFIED, MERGED FROM 3.2.3] Verify that data stored in browser storage (such as localStorage, sessionStorage, IndexedDB, or cookies) does not contain sensitive data, with the exception of session tokens which should be stored in either cookies or sessionStorage.	✓	✓	✓	922
8.3.1	[MODIFIED, MERGED FROM 3.1.1, 13.1.3] Verify that sensitive data is only sent to the server in the HTTP message body or headers and that the URL and query string do not contain sensitive information, such as an API key or session token.	✓	✓	✓	598

Based on 8.3.1 - JWT, containing data about the user, must not sent in a URL parameter anyway.

7.1.1 and 8.2.2, as access_token is not a session token (although massively used as such), I recommend putting special spotlight on JWT (or abstractly "encoded data, such as in JWT") and mentioning them in 7.1.1 and 8.2.2

Visualized:

[EnigmaRosa]

I feel like

If we could put all this information as plain text to URL parameters, everyone would understand, it's nonsense to send information like a person's full name, SSN, email, phone, and address as URL parameters. If it is inside JWT, it's the same, just base64 encoded.

is obvious to those using the ASVS, unless I'm mistaken. Is the clarifying language proposed that necessary? (this is a genuine question - are there ASVS users who would need to be reminded about JWTs?)

[elarlang]

This is the danger when you know the topic and you going to assume, that "this is so basic, everyone must know it" (it's good to teach web application security to developers, it gives a reality check).

I know, there is OAuth response_mode=query, and I know there is OIDC logout id_token_hint - this is actually one reason to address this problem. The problem exists for both when the browser communicates directly with the authorization server or IdP.

I'm pretty sure OAuth and OIDC developers also know what is JWT, but it is still carried from one party to another in the URL parameter.

In short, yes, I think it requires special attention (otherwise I would not have opened the issue). The issue is open to collecting opinions from others, and I got yours, thank you :)

[tghosth]

First, I love the meme. I do prefer the Geordi La'Forge version though 🤣

Secondly, I think that @EnigmaRosa is correct that people should really know the risks of storing a JWT and the fact that this is sensitive data. However, I can see how this specific case might slip through the cracks.

It sounds like a subtle clarification in one of the requirements should be sufficient.

@elarlang do you have a specific proposal?

[elarlang]

Suitable requirement is 8.3.1, also related 8.3.5.

Maybe a special mention in the chapter text is enough, something like "Just encoding sensitive data (classical solution base64, including as JWT) is the same as sending it as plain text."

[tghosth]

Can you open a PR on V8 and I will take it out of V7 for now?