Hacker News new | ask | show | jobs
by xonix 1119 days ago
Correct me if I'm wrong, but to me passing the access token in the GET URL is not a good security practice. This increases the probability of unintentionally exposing the token. The URLs can be logged by proxy servers, application logs. Simply, user can accidentally send the link with token in chat, etc.

Usually in REST APIs the auth token is passed via some HTTP header.

3 comments

Hi, i'm new to HN and didn't find comments easily! Sorry for late reply.

Having them in the query params was intended for sharing indeed. I wouldn't expect someone using it on the frontend of course. I might switch to having them in the headers instead, as it was initially like that. Idea was to use the service with minimal requirements.

Tokens can be set as READ_ONLY, these tokens are only meant to be used with GET requests. So you can share the link to use in some other app for example. Again, headers might be better however we can't share them, i.e. simple copy paste.

A stackoverflow answer on this:

https://stackoverflow.com/a/499594

I don't think proxy servers or sniffers see GET data - it's encrypted, assuming HTTPS of course. Server logs might be an issue. Browser logs and accidentally sharing is definitely a bigger issue. Less of a concern if API is only used behind the scenes by apps though.

Disclaimer: I'm not an auth expert!

> I don't think proxy servers

Proxies with MITM (mostly corporate) would see everything, because they are terminating client SSL/TLS.

MITM will see everything, but this should be the case with headers as well as GET params, passwords/tokens/data etc.
In case there is no MITIM but the original link was written using the plain HTTP then the proxy would see it anyway, before upgrading to SSL CONNECT.
> Usually in REST APIs the auth token is passed via some HTTP header.

Yes, headers or even as a data in the POST request.

> Simply, user can accidentally send the link with token in chat, etc.

Yep! Even more - it can be seen in the URL even if the user send a screenshot.

Are headers/POST data safer in any way against an attacker? Do they get any special treatment while the data is in-transit, as of being usually more often encrypted than the visible request URL?
There is no defence against an attacker sitting on your wire. But headers and data 99.9% aren't logged or can be seen in a shared link or screenshot.

Just hit F12 in you browser, switch to the Network tab and look what happens when you do the things.

TL;DR: no, but you should be vary of how things are logged and/or shared.

Eg: you see a screenshot with https://bank.com/pay.php?from=17255252&to=6445675665&amount=... URL in the browser...

Yeah, true, even a security camera pointed at your laptop's screen would have access to GET data and not POST data.