Hi there,
I’m using a 3rd party API that requires a key/token that must be remain secret (not visible in the javascript calls). It is normally stored into environment variables or application configurations on the server side.
What is the way to do that in Webflow?
The closest way I found relates to Google Maps/JavaScript API Key (see screenshot)
Thank you for your help,
Nicolas
Hey @nmanaud
Best way would probably be custom code, you could hide it behind some sort of encryption if allowed. Which service is it? I could provide additional information if I knew which API it was.
Thanks Julian. I’m already using custom code. The service I use is called Mapbox (Access tokens | Help | Mapbox)
Not sure what your trying to accomplish but can’t you just use a public scope token? And also restrict access by incoming domain?
If you are just trying to display a map, you can use the public scope token, but if you are trying to allow update requests by users I would suggest using a temp token or maybe you could hide the access behind a password-restricted page.
Yes I could use a public token but eventually I would like to allow only certain users/apps to use the basemaps that we are crafting. It doesn’t come for free and we will have to pay for extra map views.
But beyond Mapbox, my question is really related to hide API keys in general.
Google maps api keys are public and will always be publicly visible as are mapbox tokens.
With google maps, you can setup http referer restrictions to prevent other sites from using your key. Not too sure about mapbox but I’m sure there’s a way.
Whenever you are dealing with “private keys” make sure to not publish those. However, both google maps and mapbox have public keys and they’ll always be accessible by tech savvy users.
Hi @Hollydenh
This is exactly what I’m trying to do within Webflow. Note that I’m not using Google Maps, and my question applies to any 3rd party API.
Thanks.
This is very late, but you can manage IP address that can access your API key. This has to be done within google cloud api security and is separate of webflow
Hey Spencer, that won’t work for client-side script, since the visitor’s browser is actually making the call to the API. That IP will be different for each user, and you won’t know them in advance.
The way to protect API keys is to only use them server-side, and never put them in client-side JS.
In Webflow the common approach here is to use automations. Use Make.com, Zapier, n8n, Pipedream, Automate.io, etc, and your automation will safely secure your API key. Your client side script then calls the automation Webhook to perform its needed tasks in a more controlled way and with less direct exposure.
Won’t someone be able to use the same script from the client side on their own website and receive incoming data? Would I for instance need to add the “HTTP - Make a request” module in my Make scenario and set the URL to prevent that from happening - and will this then be the only security I have?
Yes, all of those risks are valid.
If you create a webhook on Zapier that, say, ships Lamborghinis to the address you specify, there isn’t anything really to prevent someone from finding that webhook URL in your code, and shipping themselves a few dozen.
These are fairly low-level hacker skills. All you need is Chrome.
To defend against this, you can add a tiny degree of limited security by implementing CORS protection or other mechanisms that check the referring website. Google uses this for endpoints like Google Maps, so that you can reduce the chance of someone else abusing your maps key. However that’s only useful for situations where someone tries to use your key on their own website.
There’s still nothing to prevent them from making calls directly, and pretending they came from your website.
Add some strong login security with MFA, and server-issued keys, and you might be able to sign requests you’re making to your API to authenticate them. But this is alot of infrastructure, and there are still ( much more challenging ) techniques that can defeat this.
The basic rule is this;
Any API calls made from client-side script, are insecure. Period.
If that’s an unacceptable risk, you need to eliminate that approach entirely, and build your own server-side application so that all secure communications happen between your server and the APIs you need directly. This puts them out of reach of the browser, and keeps those endpoints completely out of your client-side code.
Thanks for clearing that up! I’ve been searching for days for something more secure when calling Webhooks or API’s from the client side. It’s not even really needed in my situation at this point (no sensitive information getting back to Webflow), I just want to do it right (without the need of Another subscription).
Is all Webflow Logic running server-side that you know off? I have a Make HTTP request action atm that has my Webhook in it and thought this was all hidden client-side but am in doubt now.
Edit: A service side solution like a serverless Netlify function would be the safest then yes? I sort of keep trying to avoid this but perhaps I should stop doing that.
My understanding is that both form-triggered and webhook-triggered Logic flows execute on Webflow’s servers, but that doesn’t really improve your security any more than a Zapier/Make webhook does.
If you’re ultimately calling something like Xero, your Xero API keys are protected server-side, however your trigger is probably still happening client-side - so anyone who can see that form can unpack it and simulate those calls to Logic with little to stop them.
The best approach is to just be very intelligent about the types of things your client-facing API or automation ( Logic, Make, Zapier, whatever ) can do, so that there is little harm anyone can cause.
Thanks again, I’m doing some more research!
Use environment variables for security.
