Generally speaking, there are two types of API keys: secret keys and read-only keys. Sometimes these are called private or public API keys, but it's best to use different terms to avoid confusion with SSH keys.
These are your traditional API keys that have write access to the API resources. They can modify data, delete records, or even disable your entire account. If someone got a hold of these API keys, they could do a lot of damage. Depending on what functions the API allows, malicious use of your secret API key could cost you a lot of time and money.
Never ever use secret keys in client-side code.
No, I don't want to hear about your clever obfuscation that prevents people from lifting your key from your source code. Or any one of a dozen other ways you might have "hidden" your API key. If your client-side code makes an HTTP request with that key, it will show up in the network panel of the browser's developer tools for anyone to see.
Just don't put them in your code.
These API keys are specifically designed to be used in client-side code. They can only read data from the API, not write to it or change anything. So even if someone got a hold of a read-only API key, they couldn't do any damage to your data.
Whether an API can be used in client-side code is often noted explicitly in the documentation.
If you're using a bundler, adding API keys or other configuration is usually fairly easy. The standard way in Node.js is to use
dotenv to load a
.env file and access the environment variables through
dotenv-webpack, or simply the built-in DefinePlugin
@rollup/plugin-replacealong with dotenv
- Parcel: built-in
If you're not using a bundler, embedding configuration values an be a little trickier. My preferred solution is to create a
config.json file and
Simply add the
config.json to your
.gitignore and treat it the same as you would a
Of course, the downside of this method is that you have to make an additional network request. You can mitigate the delay by adding a
The popular Twelve-Factor App principles state that configuration, such as credentials to external services (i.e. API keys), should be stored in the environment. This means using something like
dotenv to load and manage your config, rather than including it directly in your code and pushing it to your repository. And I completely agree with that.
Complex front-end applications need bundlers, API key management, minification and other optimisations, and many more things that make the website better and faster.
However, most of the sites on the internet are not large platforms. They're personal websites, blogs, online playgrounds for people just discovering the joys of web development. If you're working on a site like that, chances are most of the aspects of the Twelve-Factor App don't even apply to you. So why should the rule about configuration?
So go ahead and build that awesome site using a simple .html file and some .js files in a folder. Just remember to use the correct, read-only API keys.