5 JavaScript API Key Mistakes (and how to fix them)

all right so if i want to use this weather api in my react app let's go ahead and just copy this snippet i'll throw it into this fetch request for this url and then i'll just add in my api key right here no don't do it let me show you five mistakes that javascript developers often make with their api keys what's going on everyone my name is james q hick and i do weekly videos on web development related topics and i want to cover one of the things or i guess five examples of mistakes that people make i see this all the time with their api keys so if you've ever signed up for some sort of api in this case we were looking at the current weather api or if you're working with a database and you have some connection string or whatever it is if you have those private credentials here are five mistakes not to make and i'll show you how to fix them along the way now i wanted to give you a quick reference for something that's a little more hands-on on yakubo a good friend of mine on youtube has a video called how to hide your api key safely when using react and she talks about in detail to actually show you how to do some of the things that we'll talk about here so i'll have a link to her video if you want some extra resources but let's go ahead and get into it and we kind of teased this at the beginning a little teaser thing at the opener whatever you want to call it of the video where uh you kind of have this hypothetical situation where someone is like okay i want to use this open weather api and you see this all the time in tutorials say okay well um i've already signed up and i have my api key and then i will just add in this fetch request and add in the url for this request and then type in my api key here number one mistake that i see people make is adding their api keys directly to their code you never want your api keys hard coded into your code at all that's number one now how do you fix that what's the way around that well this is where you get into environment variables and environment variables in javascript probably the most common thing you'll see is a dot env file now if you're working in a regular node.js application you might have to install the let's see npm.env package and what dot env allows you to do is to create these emv files and then by using the package it'll allow you to read these in in your javascript by using let's see in here you can use process dot that's not it process i don't know why it's giving me that intellisense dot env dot and then whatever that variable name is so these are just key value pairs you can see in this example file you've got the key on the left side and then the value will go on the right side so you always want to use environment variables instead of just hard coding the actual api keys or secret credentials into your application all right now the next problem i have is once once people understand that and for what it's worth all these mistakes i've made and other experienced developers have made at some point in their career too so don't take this personally but you figured out okay i want to use environment variables and this is also the environment variables for our compressed fm sites this is uh not the actual values but an example of what these values look like but once you have this.env file one of the things that i see people make the mistake of all the time is to actually check that into their source code which defeats the whole purpose what you're trying to do is keep this api key out of the hands of people that could take your api key and go and use it for whatever they want they could rate limit it they could spam it they could run up charges if it's a processing thing whatever that is you want to keep your api key secret from those nefarious developers out there just people that want to do bad things with it so you create your env file notice i'm showing you a dot env.sample and not my real.env because those are where the actual variables live but the thing you need to know is if you look inside of the get ignore now this is the next.js application so this already comes with a lot of this stuff built in but you'll see if you scroll down this is ignoring env file so dot env dot envy.local development test production et cetera et cetera now i think next.js comes predefined with these and they don't mention env i always add this just to make sure because i like to just name mine.env because i don't have different uh different files on my local machine that represent different stages of development test production those would be servers somewhere else that are running those anyway you want to make sure that these files are inside of your git ignored to make sure they don't get checked in which you can tell by this if you look it's maybe maybe hard to see but this dot env file here is kind of grayed out in comparison to the rest of them so you can tell that this thing is not being tracked and it's not going to get checked into my source code and if i come to the terminal and i do a git status even if i were well i can't open the file but actually i'm not even in the right directory anyway that doesn't matter but inside of here uh because it's in the dot get ignore it's not going to check in your env no matter what you do it's always going to ignore it so after you get to the step of setting up your env files for local testing then make sure or probably even before make sure you're ignoring that file inside of your doc getting nor file so it never gets checked into your source code now the next thing is i see people use environment variables and you go to deploy your app and so once you deploy your app you have something like this this is a sample app and versel netlify and heroku and all these other ones all of them have environment variables that you can store safely inside of their dashboards so let's say i'm building a react application or whatever and i have an environment variable most people assume if i just use an environment variable with a react application and set it inside of the host like for cell here that you are good to go but that's not the case unfortunately you can't use any of your secret keys from your environment variables inside of any front-end code because you can just then inspect the code and be able to see what that value is so what happens is at kind of build time your code will go and grab those variables inject them into the code and now that's the code that's actually going to ship to the browser so anyone that can go or anyone with a browser can go and right click and inspect and look at the code or view source code or whatever it is and go and find that actual value on yakubo has a great example of that in her video if you want to go check that out so number one thing here is don't use environment variables if they're secret ones you can't have environment variables that are not secret but if they're secret environment variables don't use them in your front end which then complicates things because now technically to work with something like the open weather api which is a very common starter app that people build is to just go ahead and use this from the front end but technically to be the most safe to be the most secure you should never use those environment variables on your front end so what do you do well your instinct now is maybe to create a back-end api and anya talks about this in her example but you can create a nodejs back-end api that basically serves as a proxy for your application so instead of calling let's take this example here instead of calling directly to the weather api you might call to http if you're running locally http colon colon local host 3000 slash weather now if you then build that back-end api endpoint with node.js or if you're using serverless functions in next.js whatever it is as long as it's something that runs on the backend on a server that thing can then use environment variables from your host like versil and store them secretly the problem is and this is where mistake number four comes in is your backend api endpoint probably doesn't have any protection around it what does that mean well if you're using your backend api endpoint as a proxy meaning from your front end you call your backend which then calls the api that makes sense but there's nothing stopping someone else from calling your api backend endpoint directly so they could just send their own request using postman or whatever else directly to your endpoint which then uses the api key which means they more or less have access to whatever that api key has access to so how do you solve that well there are several things that you can do one you can enable course you can say courses cross origin request is it just i don't know what the s is coors web development let's look up the api cross origin resource not request resource sharing and what this is it's something that's actually implemented by the browser so what this says is if this backend endpoint does not tell me that it's allowed to receive requests from me if we're not on the same domain then google chrome for example will not let you not let you make a request to that endpoint so you can define your core's rules on the back end you can say only this domain can access me only only a couple of domains or maybe it's wide open whatever those rules are your browser will then listen to and respect mainly google chrome which then the problem with this though is that google or your browser it's up to the browser to enforce this it's not something actually enforced on the server so uh if you go without a browser and you go to postman you can still kind of get around that so coors is one option you can also rate limit to make sure that people aren't spamming you can kind of limit the amount of requests that people can make in a certain amount of time to make sure that you don't get spammed and then the two things that really probably need to happen are some sort of secret credential or token that come along with that request which is why things like the open weather api and any other api that you use probably have secret credentials because that's the way that they can validate the incoming request which puts you in this kind of like confusing state of like if i create my backend endpoint so i can safely store my api key and then i call that back an api endpoint but i need to prevent others from calling it it's like this convoluted thing but two things that you can do with that if you're making a request from your back end or excuse me from your front end to your back end you can include your own personal password whatever it is and type it in manually and send that with every request that's kind of a cheap hacky way to do it and then you know what the value of that should be on the back end and compare that when it comes in much like a password for login also this is probably the most realistic is you have some sort of authentication and authorization around this api so an example of this would be you have a user login when that user logs in they get a json web token which is kind of an artifact that proves that they had logged in and has basic information about themselves then when they make a request when your frontend makes a request to your backend you can validate that json web token and consider this to be a request that comes from a valid user now there's all sorts of details about json web tokens and best practices with security and anything if you have questions about that let me know i'd be happy to do a deep deeper dive into this but moral of the story is even if you use your own backend as a proxy from your front end to some third party api so that you can protect your environment variable your api key you still have the problem of preventing people from calling that directly that you don't want to so it's a long story if you have questions that i can help clear up or maybe a demo would probably be a good idea let me know and i'll do a follow-up video to clarify that now the last thing the last mistake that i see people make and this is one that i make all the time is if you stream or create content or whatever you accidentally pull up your env file or your show your environment variables your api keys in the dashboard etc and you never want to do that because if it's in a video and that video is around people can go and watch your video pause the video grab that secret credential go and use it for themselves obviously so streams and youtube videos and stuff are around for a while and people can see in real time or go back after the fact and find them so one of the things that you can do there's an extension if you create content like that called cloak that was created by john papa and what that does is inside of here i don't know if it works for sample files but if i do cloak there's a hide secrets and it's actually going to hide that value this would work with my env file i don't think it works with the env.sample but anyway if i'm live that extension can hide those api keys even if i accidentally show them on screen to make sure that i'm protected against giving you or some nefarious person access to my secret api credentials all right so that's five different tips or five different mistakes actually that i've seen with people working with api keys and how to fix them so if you have any follow-up questions let me know make sure to check out the video from anya she gives you a more hands-on example with code of how to solve this problem so go and check that out in the meantime thanks for checking out the video and i'll catch you next time

Channel: James Q Quick

Views: 44,841

Keywords: javascript api keys, how to hide api keys, api key mistakes, dotenv javascript, cors, dotenv, environment variables, web development, javascript, web development best practices, hide api keys, backend apis, how to use apis securely

Id: 7oJgdyMS4rQ

Length: 12min 48sec (768 seconds)

Published: Tue Mar 22 2022