accessToken leak

[webapple]

In the url address, accessToken directly appears after the url, resulting in information leakage of the token on the Router. And this API returns all the configuration information.
I already saw accessToken in the header of the request, so adding it to the url parameter is a bit redundant.

http://localhost:9091/nacos/v1/cs/configs?dataId=&group=&appName=&config_tags=&pageNo=1&pageSize=10&tenant=gtjazgqd_cloud_dev&search=accurate&accessToken=eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJuYWNvcyIsImV4cCI6MTcxODM3NDc0OX0.07Mc9AB1CDRSwEpl_udNBJeZCSFzgZZg6HXdcG1Ilro&username=nacos

[KomachiSion]

Sorry, I can't get the key issue. Do you means the nacos console is not need accessToken in url?

And you said the accessToken leak problem. If in nacos console url is leak, only remove in url is not usage, but you also can get it by browser console.

If you said client leak the token, you want to leak this token must be catch the tcp package and analyze them. If by this way, you also can get the token in header.

So which one is your issue?

[webapple]

You are right. For the http protocol, even if the accessToken is not placed after the URL, it can be seen through TCP packet capture if it is placed in the header information, but at least the accessToken will not be exposed on the router side.
In addition, the nacos request header already has the accessToken, and adding it after the URL is redundant.
And I have never seen other management systems put the accessToken directly after the URL.
This issue is an issue raised by our company's "Network Protection Action", and we also think it is indeed a small problem.
The following management system will not add the accessToken after the URL

[KomachiSion]

Well, It might be an enhancement for nacos console. See community response and callback, If you or someone want to do this enhancement, can submit a PR to remove it .

[HMYDK]

Hi, if you don't have time to address this issue, I'd like to give it a try and work on an optimization. @webapple