I use gatsby with DatoCMS to generate a static website that has absolutely zero server side , and all has been working sp far so good.
Now I wanted to implement search using the search api functionality from Dato API, all the setup went smooth and the search works well on the runtime based gatsby. However, for the static generated site, I have two options to make it work:
1- Using a token created with search api capabilities only and Iāll have to expose it to the users
Which of the above is more adequate? more precisely, is there ANY security concern with the first solution?
Iād strongly suggest #2 (doing it indirectly). Exposing the API key has a lot of risks:
Itās easy to accidentally forget to set explicit DENYs on the records & assets, potentially opening them up to the end-user
Even if you got all the roles right, exposing the API key like that means anybody can denial-of-service you or just rack up a lot of usage-based billing by repeatedly hitting the API with your key. At best this gets rate-limited after a while by us, but then none of your other users can search your site anymore. At worst, they figure out the exact rate limit and just flood your account with it, incurring thousands of dollars in charges or more.
Thereās no guarantee that another dev/editor doesnāt accidentally re-use or modify the role youāve assigned to the API key, potentially opening up more than originally intended.
Future permissions we may or may not create might assume that API keys are secrets, and if those default to ALLOW instead of DENY, suddenly this old site search key might have unexpected privileges it didnāt have in 2024
etc.
It is fraught with a lot of risk and weād heavily recommend against this approach.
Is there any other solutions for my use case that Iām missing here?
Sorry, Iām not very familiar with Gatsby, but is a āserver-side routeā something thatās built into the framework and easy to use? If so, that sounds like a great approach! It really just needs to validate the frontend request, maybe enforce some sort of auth or rate limits (or at least a basic referral check, etc.), and then pass it through to our API.
Cloudflare also does something similar: Cloudflare Workers Ā· Cloudflare Workers docs (and that also makes it easy to add on their security products to enforce rate-limiting, bot blocking, etc.)
