Pass API_KEY via Authorization headers not URL

I'm just starting to get into the TORN api and the first thing that I noticed that is REALLY BAD is why do we pass the API_KEY via URL parameters???

This is so bad, wrong, dangerous etc. in so many ways...

Think about what a URL is. URLs are public. People copy and paste them. They share them, they put them on advertisements. Nothing prevents someone (knowingly or not) from mailing that URL around for other people to use. If your API key is in that URL, everybody has it.

1. There is a web standard for a reason. See here
2. Sharing URL means users sensitive API_KEYS get shared too.
3. Even with HTTPS your API_KEY isn't safe from being stolen.
4. Man in the middle attacks listening on the public api for URLs with users API_KEYS

So, my question is why not follow the web standard and pass any tokens, keys etc via the authorization bearer token at the very least?

I can think of an example: imagine you've got your generic player. This person doesn't know the first thing about API keys or even what Auth headers are, but you want every player, regardless of experience with API keys, to access their game data from the API.

Whilst path would you choose;

A) use Auth headers with a detailed explanation of how to use it, this, however, comes with the risk of deterring people from using their API, that is without forcing them to lay their trust in 3rd party apps to retrieve the information.
or
B) create a simplistic URL that you add both the parameters and the API key and you have instant access without the need of trusting 3rd parties with your API key.

When thinking about which of these options you'd rather choose. Remember that you have to consider that the API is meant for anyone to access, regardless of experience with them. Whilst many apps exist that also help gain access to the API info, this does rely on the trust that the person you are entrusting your API Key to will not misuse it.

In that case providing two mechanisms would be great.

1. via the URL parameter for newbies getting into programming
2. via headers for others who want to build custom user interfaces / apis

I couldn't find information on point 2.

For extra context I'm basing it around this.

1, My point was not about newbies getting into programming, it was about players that either have no interest in programming but want simple access to their API data.

2, Why bother creating 2 mechanisms when 1 is both sufficient and usable by all, advanced programmers are surely able to use the URL with the requirement of auth headers, are they not?

programmers are surely able to use the URL with the requirement of auth headers, are they not?

Hmm...no. If I understand correctly. If one tries to make a request to the torn API by setting the "X-Api-Key" in the header. Something like this:

const response = await fetch(`https://api.torn.com/user/?selections=profile`, {
headers: {
"Content-Type": "application/json",
"X-Api-Key": process.env.API_KEY,
}
});

const userProfile = await response.json();

It doesn't work at all. However setting it in the URL params does work but refer back to why its less than ideal in original post.

My bad, I made a grammar error, that should have said "programmers are surely able to use the URL without the requirement of auth headers, are they not?"

I don’t think security of this data is a massive concern, but I agree with you

Thank you. I guess we are stuck with the snowflake API the torn devs provide us with.

Makes total sense...

Cant really think of a reason to disagree with any of this.

If a "casual user" wants to use the API, and auth-headers are introduced...they can use curl, Postmans, etc to do so.

While I totally understand and share the end goal of this post, I can find some obvious reasons not do to it:

- Time to invest to change this on Torn side (code + documentation + all the things we don't see)
- Existing applications would not work anymore, and at least some of them would not be updated to follow the new standard.
- (this last reason is not great but anyway) : API key is not your login/password. Even if it gets hacked/sniffed, what happens? Not so much. Is it a real issue? if not, do we really need to solve it?

But as the OP states, it's completely against the Web standard (and industry best practice) to send credential via a URL param.

The change requried to update the service and apps would be tiny, if they've been built properly in the first place.

For apps that wouldn't get updated, the structure of the API responses changes all the time...they're likely to fail at some near point in the future anyway...this is why using deprecated/abandoned apps isnt recommended in general.

All the reasons are good and all, and the bearer tokens, oauth and stuff were created for a reason, don't get me wrong.

But, with your permission, I would like to make a few counter arguments:

1: the standard mentioned describes the basic auth which allows stuff like schema://user:password@url-is-here/. So using the token in the url is not against the standard. It just "not" by the standard

3 In context of header vs param in url, It is just wrong? Everything in http is text (except content in some cases) including url, headers, cookies etc. But https helps a lot, as everything is encrypted.

4: With successful man in the middle, nothing will help. The tokens must have expiration time. So time to time one must renew it, and the attacker will receive the key for generation of the tokens anyway

>advanced programmers are surely able to use the URL with the requirement of auth headers, are they not?
It means support of two systems which, advanced programmers try to avoid for sure.

The header is encrypted in a HTTPS request...but URL params aren't, and can't be.

Using a credential in the URL is 100% against the standard.

Tbh, I don't even get why this is a vaguely controversial topic...

"Tbh, I don't even get why this is a vaguely controversial topic..."

Because playing devil's advocate is a second nature for some people .... Load image: angel :D

Reading "Cant really think of a reason to disagree with any of this." makes my brain look for some actual reasons. And I do think the ones I've raised are valid.

However, as already stated, I wouldn't protest against this improvement!

I hope it clarifies and answer your last point!

But the thing is...there isnt a devil's advocate position in software development...

There is a small number of right ways, and many MANY wrong ways.

Since they've opted for API keys, they should be included in the header, not the URL params.

There's no real devils advocate position that can rationally explain why the change isnt a positive one.

(Professional developer here, who regularly builds out API's for BIG clients...)

And if people aren't bothered to change (more accurately, actually use) the auth method that their chosen HTTP/Rest client uses...do you really want to use their software?

If they cant/wont change it, then its probably a good indication that the rest of their code is probably bubblegum and lollipop sticks.

Its just wrong, I've always thought it was wrong (because it has always been wrong) but didnt say anything...this thread spurred me to finally speak up.

Tbh, I still think its weird that some people oppose the change...must be non-developers?

>but URL params aren't, and can't be.
Sorry to say, but this is false information.
The only thing available to man in the middle (like your provider) is host. Whole request is encrypted and is not available to any man in the middle without having their CAs installed.
This is actually the reason why in dictatorship states like russia dpi blocks the IP instead of uri if "forbidden materials" are behind https and only specific uri if http
Btw you can use dns over tls to make it completely invisible


>Using a credential in the URL is 100% against the standard
Basic auth works with credentials in the url and it is per standard. If torn used basic auth, say with pair USER and PASSWORD, I would be able to login with https://USER:PASSWORD@www.torn.com/ as url. Must add that it will be transformed into a header. But still, credentials in uris are completely valid and per standard

If I may sit on the fence:

It's not best practice, but it's not atrocious either.

I think I can conceive of some man in the middle attacks though.

By using the API key in the url, someone with admin network access could look at all the domain requests made on the network and without being particularly clever could look at all the network traffic over a period of time and search for url requests pertaining to torn API calls (which would have the API key included as plain text).

Vulnerability could be mitigated with a less rudimentary implementation.

I believe Torn could support a more robust API request system while allowing for this entry level API request system to remain enabled for less technically savvy players.

For me personally, this game has been a nice playground for sharpening my programming skills and learning how to make API calls about my character's data has empowered me with skills applicable to my professional life. My point being that this game is a great use-case to learn programming.

Nevertheless I think Torn *should* support a more robust API system with best practices for those that want it (while allowing legacy support for the existing system for the less technical users to hone their skills).

The fact that the API system is dead easy means novice programmers have the opportunity to hone their skills without much computer knowledge.