I noticed some websites do this and I am not sure if this is normal or not. So for example, on some websites, I go into setting and can create an API key that will be visible in plain text. Also, seems like a lot of HTTP requests have an API key visible in the URL. Something like this "https://www.myWebsite/user?apiKey=\(apiKey)". Any insight on this is appreciated.
Add a comment
|
4 Answers
"Normal" may be the wrong choice of words for your question. The real question is... "Is it secure?"
Breaking the question into different parts, here's my take at an answer:
1. Is it secure for a site to provide me with an API key?
Providing you with your own API key isn't a problem, since it's your key. This is true as long as the page is served using https. Serving the page unencrypted would allow anyone between you and the web server to also see your API key.
2. Can an API key be passed via URL and still be kept secret?
No. Passing an API key via the URL means that key is stored in the server's logs, in a browser's history, visible to browser extensions, accidentally copied / pasted by a user, etc. It is no longer a secret. This is true even if the page is served via https.
3. Does an API key need to be kept secret?
This question may be a good one to explore. Maybe the service you're referring to provides an API key and a Secret key. The API key can be exposed via URL but the Secret key must be used to calculate a certain header that must also accompany the request.
Another example might be an API that's expected to be called via JavaScript. In this case, anything in code will be exposed to the client. Again, the service provider may expect a key that is derived from your secret key to be passed via the service.
Alternatively, maybe none of the keys are secret but the service employs IP address whitelisting to ensure that the keys can only be used by your server. They could also do hostname checking and allow you to specify valid hostnames in your account that the key is allowed to be used for.
Summary
Ultimately, the technique that a service chooses to use to protect its keys and secret keys should match the need to keep them secret, or the need to protect unauthorized users from calling the service. In some cases it doesn't matter if someone uses your keys to call the service.
-
There is an error: "content that the client and server exchange is encrypted, the URLs are not": The host portion is not encrypted, the rest of the URL is encrypted but as mentioned the rest may well be logged and thus not secure on the server even though it is secure in transit.– zaphSep 20, 2018 at 0:53
It is standard to make the api key visible to you. And the end of the day, you can always extract the key from your browser no mater how it is protected. As for you mentioning "plaintext", it is not really possible to meaningfully encrypt the key if that is what you mean. At the end of the day, you are unlikely to abuse your api key, as it actually belongs to you. The only disadvantage of having it in the URL is a slight chance you will send someone the key as part of a link.
What is very suspicious about your example is that it is http: and not https:. You should NEVER send keys, passwords or anything sensitive over http. I am not sure if this is part of the question or mistake on your part.
answered Sep 20, 2018 at 0:00
-
1Sorry, I edited my question. Yes, I meant https. Sorry, but I have another small question. Is it normal still if a user logs in a mobile app, for example, gets a unique API key an the API key is visible in the URL when a user uses the App? Sep 20, 2018 at 0:02
-
Using a query parameter instead of the standard HTTP Authorization header exposes the key in various ways due to no support for no-cache/no-store, logging in access logs, and potentially as referrer in remote access logs. Not to mention browser history, which is bad on public terminals. So it's a very bad way to transfer the key. Sep 20, 2018 at 4:32
-
@CurtRand I am not sure what you mean? You mean the app has an URL bar or is it using the browser for something or are you using the apps website from a different computer? Sep 20, 2018 at 7:34
-
The mobile app has a functionality opens a browser that shows the key. Sep 20, 2018 at 8:58
-
@Curt Rand again, it should not be an issue. Now as Aaron Cicali mentioned, there may be some small issues with doing it this way. But don't panic or anything, even big security conscious company, such as gitlab uses this. The logs can be sterilized on the server side and even if they are not, the logs are usually just as safe as the db the key would be stored in if not more. Of course, the one disadvantage is it may end up in your browser history and/or logs. But again, someone would have to gain access to your computer for that to be an issue. Sep 20, 2018 at 11:41
I will try to answer your question about "normality" of this practice, but it takes some setup. Say you are serving an HTML page, which makes an AJAX request to some third-party API. You have registered for a plan with them and they provide you with an API key.
Anyone looking at the source of your HTML page can find the API key and use it for their own purposes. The usual recommendation is to have your HTML page make the request not to the external API, but back to your server, where you have implemented a proxy API. You are adding the API key to the request, send it off to the external API and return the answer to the browser. That way your API key remains secret as long as you're using https and nobody breaks into your server.
However, what have you actually accomplished at this point? You have created the equivalent of an open mail relay. Just like spammers use an open mail relay to send their bulk emails without paying for a legitimate service, anyone can now use your server as a proxy for the third party API. In other words: instead of calling (say) Google Maps directly, they are calling your server and you are calling Google Maps for them with your secret API key.
At this point you might as well make your API key public, because then you will at least save the traffic generated by hundreds of unrelated sites using you as a convenient proxy. This may be the thinking behind the practice of not keeping third-party API keys secret - it saves you traffic at the expense of running up costs for your 3rd party API plan.
The security issue has now become a business decision: perhaps the external API has a generous free tier and you are not actually paying for "unwanted" requests. Or perhaps you are paying for those requests, but the business value of your actual service dwarfs those costs. Perhaps putting an authentication layer in front of your service would make it so inconvenient for your users, that you are losing business. Or perhaps (this is my favorite) you have designed your web app in a way that the result of the request to the external API is relatively useless outside the context of your app. Say you are fetching directions via Google Maps from point X to your company (and not to an arbitrary point Y).
If you do not want to solve this issue on the business level, but rather drill down on the security, then (as far as I see it) you have to be able to distinguish between wanted and unwanted requests. If the requests are going directly from the users's browser to the external API, then there is no way to do that. Unless you require all your users to provide their own credentials for access to the external API provider, which is unrealistic in most use cases (and may be a security problem from the perspective of your users).
At the end of the day you need to have the requests going through your server and filter out unwanted requests there. How you implement that depends on your application.
On a security / hackers perspective, definitely no.
You shouldn’t exposed any key via on the URL. That’s the best practice.
-
Welcome to Information Security! Do you have any evidence to support your claim? Your current answer is rather thin and may be downvoted. If somebody else claims the opposite, who should we believe? Jun 27, 2020 at 6:54