Lucid requires leaking the blockfrost key if in a browser enviornment about lucid

[Traka-Dev]

you could implement a proxy api call so instead use blockfrost url, you can use a custom rest api to your backend and then from there call blockfrost to get the data so you don't need to expose your project id to the front end

[GGAlanSmithee]

According to @Traka-Dev's suggestion, I created an example repo for doing this with next.js: https://github.com/GGAlanSmithee/cardano-lucid-blockfrost-proxy-example

It also handles multiple blockfrost projects (for different networks) and for switching between networks.

Only implemented with the nami wallet for now, as a testbed. Please check it out.

[alessandrokonrad]

I don't see it as a "big" issue. What would be your alternative approach?
If you don't want to expose it at all costs, then you likely have to implement your own provider into Lucid.

[rosieks]

Are you fine then if community use your blockfrost API key? I think that it's worth to think about safer alternative

[MartinSchere]

I don't see it as a "big" issue. What would be your alternative approach? If you don't want to expose it at all costs, then you likely have to implement your own provider into Lucid.

I'm not sure. But it is indeed a problem, because other people can use your API key (spending your money)

[LowNightSnack]

you could implement a proxy api call so instead use blockfrost url, you can use a custom rest api to your backend and then from there call blockfrost to get the data so you don't need to expose your project id to the front end

This is the recommended way to do it. Create a serverless function for the proxy request.

[besiwims]

Could be for just testing, otherwise use it on nodejs as backend (https://github.com/blockfrost/blockfrost-js)

[GGAlanSmithee]

To add to this conversation, even if you proxy the Blockfrost API calls, there is nothing stopping an advesary from abusing your API endpoints and by extension you Blockfrost account.

In similar services that I've used before - Infura and magic.link - they allow you to whitelist domains, which would solve both issues, because in that case, it does not mather if your API key is public.

Until that is in place / if they don't implement it, you could use headers, like x-real-ip and x-forwarded-for to prevent this, but to my knowledge, they can be spoofed. Either way, I will update the example repo with this.

[GGAlanSmithee]

I got an answer from Blockfrost:

Hi Alan,

Thanks a lot for the feedback, we really appreciate it! I've shared the GitHub issue with the team and discussed it. We also added a section to our docs: https://blockfrost.dev/docs/start-building/tips-tricks#securing-the-api-key

Although the best practice for securing the project_id is to never expose it publicly (eg. in client-side code), we do understand the current state of our industry and the needs of our customers. In the near future, we plan to introduce whitelisting based on origin domains, IPs, user agents and specific endpoints, which will help lowering the abuse.

However, even with restricting the project_id to certain domains or user-agents it will not completely prevent a potential abuse of the project_id as spoofing this information is trivial for any determined attacker.

Without a separated app backend, I believe there is really no 100% way of securing the api key. This applies to the infura domain whitelisting, too.

Cheers,
Peter
Blockfrost.io

The information on the linked page more or less reaffirms what @Traka-Dev said