IPFS Secret Key in Client-Side App

Questions
1

I have a pure client-side application (statically served assets with no backend) that is making requests to IPFS through Infura. Currently, this requires me to expose the secret key to the client, in order to make the requests from the user’s browser.

Infura’s documentation suggests that the Allowlist feature is sufficient to prevent malicious users from abusing the key: “If you are sending API requests from a web browser or other client-side application which does not have the ability to secure your Project Secret, allowlisting can be used to prevent a third party from using your Project ID on another website” (refer to Secure a project - Infura Docs). However, it is possible for an attacker to spoof the Origin request header: https://stackoverflow.com/a/21058346.

I looked into using a JSON Web Token (JWT), but it seems like this is not supported for IPFS projects yet. Can you please advise me on what similar use-cases are doing? The best I can think of is to set up my own REST API and server-side application from which to make the requests to Infura, but I would very much like to avoid this overhead if possible. Thank you in advance.

2

Hey @Gray_Newfield, I’ve replied in the ticket, adding the response here too:

True, you can prevent other browsers from running requests with your key but cannot stop other people spoofing the origin when using scripting. I think the bigger problem with frontend only apps is the fact that you cannot really protect your keys, no matter how much you’d be trying to hide them, anyone could inspect and see the connection details. I might be wrong but a jwt would not help you much for that matter, it is the the roadmap btw. The most secure way would be indeed to have a backend service that takes care of the keys but yes, extra overhead. You could also use something like this Quickest way to Secure API Keys on the Frontend | by Jose Torres | KOR Framework | Medium

Traian

3

@traian.vila thank you very much for your insight. For those who are following along, as well as future developers, I want to share a bit of the research I did and which implementation decision I made.

The KOR framework shared by Traian is an interesting new product that seems to have a solid use-case. Basically, if you have an API you want to call from the client side, you can wrap it in a KOR “connection,” which is essentially a public proxy. To set one up, you just input your endpoint and credentials, and in return, they give you an endpoint you can call from your application. Very low-effort on the developer’s part, which is nice if you want to get a prototype up quickly. You also get some cool features out of the box, like CORS support, bot filtering, reCaptcha integration, and other defensive measures. I reached out to the KOR team to get info on pricing / request limits. They informed me that the product is still in beta, so for the time being, it is free to use up to 10K requests / month.

I think the strongest case for KOR is for read-only APIs. For write requests, you’ll want to do some additional user authentication to ensure that one user cannot modify the data of another. For example, my application unpins IPFS data when a customer no longer needs it. If any user could invoke this API, then an attacker could start unpinning the data of other users.

In order to perform this authentication, you need some sort of backend that allows you to run arbitrary logic. The solution at the top of my mind is a serverless Lambda function from AWS, which is low-effort, highly scalable, and cost-efficient (you only pay for what you use). (KOR may even be using this under the hood.) There’s also a great new feature that came out a few weeks ago, which spins up a URL endpoint that is directly attached to the function. In the past, you had to set this up separately through API Gateway. Here are the full details on the new feature: Announcing AWS Lambda Function URLs: Built-in HTTPS Endpoints for Single-Function Microservices | AWS News Blog.

In the end, I decided to go with Lambda this time. Whoever is reading this, please feel free to share any other approaches that have worked for you or considerations that one should make.

2 Likes
4

Cool, thanks a lot for sharing this @Gray_Newfield !