4 ms·
> In terms of security, all API calls should be using https and there is little difference in putting the token in headers or as part of the query string. Most
by Xorlev 11y ago
> In terms of security, all API calls should be using https and there is little difference in putting the token in headers or as part of the query string.
Mostly true. But as a heads up, you might want to shy away from this as plenty of browser extensions are actually spyware and report full URLs back to the mothership. We ran into this recently where calls to our service including API keys in the query parameters ended up being reported back -- our customers were testing our API by calling it in the browser. Some kind of extension(s) was reporting it to a service that finds popular URLs on a given domain.
Headers aren't much more secure if someone is trying to steal data, but analytics providers/url aggregators don't care about some arbitrary header.
Our solution has been to push users to use headers and offer mutual auth (client certificates). At least with mutual auth, there isn't a trivially-leakable shared secret, but it does require more sophisticated automation (or a gateway/proxy) for clients to manage.
- betenoire 11y agoI agree, urls are likely to be logged everywhere as well
- lmm 11y agoI wish browser vendors would put work into making the browser-managed client certificate UX much nicer. That would make it possible to offer a real step change in security.
- cmrx64 11y agoThis is about authenticating consumers of an API, not end users. So while your wish is nice, it's a non sequitur here.
- lmm 11y agoIf we're talking about browser extensions (as the comment I replied to was) then we're talking about calls being made from the browser.
- Xorlev 11y agoFWIW, if it clarifies things, we disable shared secret auth when enabling mutual auth. At that point, you can really only call it with curl or your application.
- lmm 11y agoI'm not sure I follow. If you can use it from curl (presumably by passing the client certificate) couldn't you also use it from a browser? The browser has client certificate infrastructure, surely it can use it when making ajax requests?
- Xorlev 11y agoYou can, it just requires you to import the cert and use some pretty gnarly UI. I didn't mean to imply you couldn't use it from the browser, just that it was much less likely than curl + we rely on the cert for figuring out your account and not an API key.
- lmm 11y agoRight, which ties back into my original point. I bet there are devs using the less secure interface right now because it was easier to test in the browser that way. Good UX for certificate management in browsers would make a lot of the web more secure.
- deleted 11y ago[deleted]
- btown 11y agoIf your token is invalidated and regenerated after every request, this mitigates a token leaking (unless the browser extension intercepts your call and uses the token immediately... at which point your user has other problems to worry about!) https://github.com/lynndylanhurley/devise_token_auth#about-token-management https://github.com/lynndylanhurley/devise_token_auth#about-t... has a good example of this. It's nontrivial for either clients or server to implement (the edge cases around overlapping requests require careful thought), but it would likely solve this scenario.