3 ms·

If it is a paid service other can now use the service while you pay the price. And the API might also expose data you don't want to expose to the public. That

If it is a paid service other can now use the service while you pay the price. And the API might also expose data you don't want to expose to the public. That's why you never put these on the client side. There are better options, for example a proxy that injects tokens into the header.

spicybright 5y ago
Handing anyone your API key to use as they want is just asking for trouble. I'm shocked some people think that's an ok pattern to do...
- kall 5y ago
  And yet it's incredibly common. I would guess 95% of users of services like Firebase, Supabase, Algolia, Sentry, Segment, Cloudinary, Auth0... do this, because it's the point and officially endorsed. They are intended to be "frontend safe" to an extent. Not against service abuse/scraping maybe, but against actual RCE, unauthorized actions or unauthorized data access. I guess you can proxy all that, but then what do you that the third party couldn't be doing for you? Can the user not accomplish the same thing through your proxy that they could through the key? It'll be easier to drop some requests than it is to revoke an API key I guess. You could use client-certificates, stuff along the lines of Cloudflare's API Shield etc but I would guess that only the top 5% of applications do this. I've certainly done it/am doing it right now, which is likely why I'm writing such a defensive comment. Honestly if an enterprising user/developer wants to do something like dump all data that is already accessible to them, more power to them.
- harg 5y ago
  Usually the public facing keys are restricted in a number of ways to help prevent abuse. E.g. they'll have strict rate limiting, fine-tunable scopes, domain restricted, can only be used in conjunction with a server-side secret. E.g. Stripe has a publishable key and a secret key. The publishable key links the checkout session to a particular Stripe account, but you can't actually initiate a checkout session without setting a session ID from the server (which requires the secret key). If the 2 keys don't belong to the same account then the checkout session will fail. Yes, with some services you can proxy requests via your own service. But how is this more secure? If anything you've just increased the potential attack surface.
- ehnto 5y ago
  Part of the selling point of Algolia is that they handle the misuse mitigation for search, and running queries directly through their API using public facing keys is the enabling feature for that. The way to hide your keys would be to bounce the search through a proxy server that then does the API call on behalf of the user, but you're really not gaining anything by doing that, and now you're on the hook for traffic misuse mitigation. Most APIs designed to be used this way also whitelist your token to your site domain, so they can't just steal your key and use it on their own site. Regardless, Algolia and services like it fully expect to be exposed to the full force of the internet at all times, so there's really nothing your API key can do that they're not already covering their bases for.
- chatmasta 5y ago
  If your visitors are making requests to SaaS APIs on your behalf, how can a SaaS identify the visitors belong to you without a key? In general if a SaaS has a client-side SDK, they’ve designed around this and give you an API key just for the client bundle. It has only the permissions required for the client SDK, which - yes, could give a client the ability to run up your bill. But you could say the same about any usage based service. It’s up to you and the service to mitigate against that. I’m not familiar with every variable in the screenshot from this blog post. Of those I’m familiar with, I don’t see any secrets in there.

spicybright 5y ago

Handing anyone your API key to use as they want is just asking for trouble. I'm shocked some people think that's an ok pattern to do...

kall 5y ago
And yet it's incredibly common. I would guess 95% of users of services like Firebase, Supabase, Algolia, Sentry, Segment, Cloudinary, Auth0... do this, because it's the point and officially endorsed. They are intended to be "frontend safe" to an extent. Not against service abuse/scraping maybe, but against actual RCE, unauthorized actions or unauthorized data access. I guess you can proxy all that, but then what do you that the third party couldn't be doing for you? Can the user not accomplish the same thing through your proxy that they could through the key? It'll be easier to drop some requests than it is to revoke an API key I guess. You could use client-certificates, stuff along the lines of Cloudflare's API Shield etc but I would guess that only the top 5% of applications do this. I've certainly done it/am doing it right now, which is likely why I'm writing such a defensive comment. Honestly if an enterprising user/developer wants to do something like dump all data that is already accessible to them, more power to them.
harg 5y ago
Usually the public facing keys are restricted in a number of ways to help prevent abuse. E.g. they'll have strict rate limiting, fine-tunable scopes, domain restricted, can only be used in conjunction with a server-side secret. E.g. Stripe has a publishable key and a secret key. The publishable key links the checkout session to a particular Stripe account, but you can't actually initiate a checkout session without setting a session ID from the server (which requires the secret key). If the 2 keys don't belong to the same account then the checkout session will fail. Yes, with some services you can proxy requests via your own service. But how is this more secure? If anything you've just increased the potential attack surface.
ehnto 5y ago
Part of the selling point of Algolia is that they handle the misuse mitigation for search, and running queries directly through their API using public facing keys is the enabling feature for that. The way to hide your keys would be to bounce the search through a proxy server that then does the API call on behalf of the user, but you're really not gaining anything by doing that, and now you're on the hook for traffic misuse mitigation. Most APIs designed to be used this way also whitelist your token to your site domain, so they can't just steal your key and use it on their own site. Regardless, Algolia and services like it fully expect to be exposed to the full force of the internet at all times, so there's really nothing your API key can do that they're not already covering their bases for.
chatmasta 5y ago
If your visitors are making requests to SaaS APIs on your behalf, how can a SaaS identify the visitors belong to you without a key? In general if a SaaS has a client-side SDK, they’ve designed around this and give you an API key just for the client bundle. It has only the permissions required for the client SDK, which - yes, could give a client the ability to run up your bill. But you could say the same about any usage based service. It’s up to you and the service to mitigate against that. I’m not familiar with every variable in the screenshot from this blog post. Of those I’m familiar with, I don’t see any secrets in there.