How safe is it to expose a restricted DatoCMS token on the frontend side?

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


2- If the above isn’t an option, I’ll have to implement a server-side route that the frontend uses to call the search api indirectly

My Questions are:

  • Which of the above is more adequate? more precisely, is there ANY security concern with the first solution?
  • Is there any other solutions for my use case that I’m missing here?
    Thanks!

Hi @mohamed.younes,

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.

Otherwise, Netlify offers serverless functions that could probably do the job: Functions overview | Netlify Docs

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.)

Hope that helps!

Hey Roger,

Thanks for the accurate and detailed answer, that was very helpful

Have a great day!