Are the provider keys safe in the Dapps? (doubt)

[bakeiro]

Hi!

I have a security concern about the provider api key and whether it's safe to set them in the frontend:

If I have to type:
new ethers.providers.AlchemyProvider(network, apiKey)

Then variable apiKey it's public to whoever can access the code (dev tools in any browser basically), and sees the apiKey, then it's like "okey, I can access to this apiKey, then I can use it for my own proporses".
How safe it's to explicitly set the apiKey in a frontend code? there is any way to do it "secretly"

thanks in advance!!

[zemse]

Actually, it's not safe at all unless there is some white-listing applied. For e.g. Alchemy allows white-listing by contract address, so "eth_call" things would only work for certain contracts and someone can't just steal your API key and plug in their app which has to work with a different contract. Also, there is a domain white-list in Alchemy, so if a request is coming from a different domain, it would give a CORS error, however, this kind of protection can be bypassed from the backend, but still, it's good to have.

If you have an API key from a service that does not provide a white-listing feature, then you should have a backend that acts as a proxy and only allow certain kind of requests, so that the API key cannot be used by someone else. If you are using next js, you might be able to use the serverless APIs, I think they are very useful in the sense that you don't have to manage a backend server for proxy and infrastructure services like vercel, netlify handle it for you.

[bakeiro]

I see.. so apart of the domain protection and contract protection (these protections are good, but I can bypass domain easily in the hosts file of the SO (associate a domain with 127.0.0.1 for example) so most safe without having to restrict calls to a specific contract would be to have a backend (using node) that receives the client request, and then uses the API key to interact with the blockchain, then sends the response back to the client... I am right with this?

PD: thanks for the info!

[zemse]

Yeah, you can have the backend to be serving only specific requests, so that even if someone can't use your backend for their general use.

[ricmoo]

Everything above is correct, I just wanted to add a quick note to keep in mind what you are protecting it from and wether you need to.

Most developers do place their public API keys in client side code. The additional overhead of shielding your API (which means you need to run backends, etc) is usually overkill and reduces your performance, since services like INFURA have significant load-balancing that would be hard for most (especially new and prototype) projects to set up for their own infrastructure.

If your concern is griefing, shielding just moves the attack vector from “using your api keys in a backend” to “hitting your endpoint which calls INFURA”, so it isn’t mitigated at all; it just places your infrastructure at risk, unless you have complex throttling.

Just my 2 cents, that this is often not necessary and can be very time consuming for something with relatively little protection. :)

[bakeiro]

I see... thanks!! good for the info, because I was feeling unsure about that plus didn't find good info about this topic anywhere... clear now, thanks! (I will put my API keys in the frontend then :) )