Route infuraId through a proxy to avoid API key being stolen

[ansonkao]

I had my infuraId stolen, and they exploited the key for all request capacity they could get. I was able to swap in a brand new infuraId, but they can just steal it again.

How does one safeguard against this?

I'm playing around with the ORIGINS allowlist setting in the Infura dashboard but it's not clear to me if this is having the intended effect

Many thanks!

[dzek69]

This is a question you should ask Infura support (or look through their docs), not a random project that happened to use it.

[ansonkao]

@dzek69 I posted this question everywhere:

• Here
• In the Consensys Discord: https://discord.com/channels/697535391594446898/931191328442822666/1001165535238705293
• In StackOverflow (for Ethereum): https://ethereum.stackexchange.com/questions/132031/protect-infura-id-from-being-stolen-and-abused

And this is prior thread that came up: https://community.infura.io/t/securing-keys-in-frontend-only-dapps/5182 TLDR is: the problem is kinda prevalent in the NFT world now. Seems to be no solution without changing the Web3Modal codebase to allow configuring the calls to go through a proxy as opposed to going directly to the Infura API. This doesn't prevent malicious users from abusing the proxy, but it limits them to just the specific API functionality that is being proxied, which will probably be enough.

FWIW, my infuraId was stolen twice, and the thief eventually gave up cause I kept replacing the API key.

We can let this issue serve as a way to gauge demand for a proxy feature. We'll see if any thieves come back to haunt me 🤣

[dzek69]

You forgot the Infura support :) They know their stuff the best.

But of course limiting by origin won't help if somebody uses the key serverside (where they can mimic browser and accepted origin). A lot of web apis work like that, including Google ones so I think if you used origin settings correctly and your key was still abused then I believe there is not much you can do, until Infura got something extra. You will have to ask them I guess.

We can let this issue serve as a way to gauge demand for a proxy feature

Seems useful, maybe rename your issue then? It should be easier to work on the issues with proper title.

[htcarr3]

This is not a random project... @ansonkao your point here is valid, and also is broadly an issue in web3 front end development. A proxy is not necessary though, you need something running server side. This project does seem to encourage dumping private keys into browser code, which is odd.

[xzilja]

With stable version 2.0.0 of Web3Modal now released, we are officially dropping support for version 1.x Due to this this issue/pr was marked for closing. It is highly recommended to upgrade as 2.x will be receiving further updates that will enable functionality for some of our newer sdks like auth and push as well as support for WalletConnect v2 (See this post about WalletConnect v1 being deprecated https://medium.com/walletconnect/walletconnect-v1-0-sunset-notice-and-migration-schedule-8af9d3720d2e)

If you need to continue using Web3Modal 1.x and require this feature/fix implemented, we suggest adding it via forking V1 branch.