There are 2 things glossed over here that should be pointed out to prevent developers looking for help finding this and thinking this makes their code secure.
If you already commited your secrets to git and pushed, they are basically already exposed via the history and can be considered compromised just as much as if you directly commited them directly to the source and left them there.
If your saving api keys on the client-side, they aren't "hidden" in production due to all JS code being insecure, where anyone can go read/find the keys via the dev-tools.
Most apis that support directly calling from the client-side usually have some protection to prevent abuse since they are essentially just "floating out there" on the client side. Those that don't should really just be called via server-side code. Anything else you do (like the advice above) will only make things less convenient to malicious attacks but isn't actually making things hidden, which is basically impossible for client-side api keys.
Let's say I am using netlify functions, and I made the repo public on Github, is there any way to hide my APIs, because I don't want to make my repo private.
Hey @bradtaniguchi the 1st point that you have mentioned is for the case when someone has already pushed the code to github without adding the .js file (containing api keys) to .gitignore, right?
How is the security compromised in this case? because as far as I understand if I add any file to .gitignore it wouldn't be committed to github so if anyone clones the repo he wouldn't have that config.gs file (where all the api keys are present). Correct me if I'm wrong
The reason your keys are compromised is even if after you realized you pushed your secrets, and you perform these changes mentioned to remove them from your workspace, your secrets still live in your repo's history. So someone can just go back in-time to your commit to get the secrets you committed. Your only options are to force change the history to make it seem like it never happened, and even then github might still have the reference to this code at some level.
Or even if you did everything right and cleared up your repos history and github isn't hiding anything, no one said someone didn't just clone/copy/get the keys you committed in the time it was exposed.
as far as I understand if I add any file to .gitignore it wouldn't be committed to github so if anyone clones the repo he wouldn't have that config.js file (where all the api keys are present)
This prevents the 1st scenario I'm talking about, but the 1st scenario should be addressed at some point since its so common. The 1st scenario being you forgot to .gitignore your secrets and uploaded them. Github currently has a bunch of built in security features that will point out compromised keys automatically, which can help at least alert you you did something wrong.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
There are 2 things glossed over here that should be pointed out to prevent developers looking for help finding this and thinking this makes their code secure.
If you already commited your secrets to
gitand pushed, they are basically already exposed via the history and can be considered compromised just as much as if you directly commited them directly to the source and left them there.If your saving api keys on the client-side, they aren't "hidden" in production due to all JS code being insecure, where anyone can go read/find the keys via the dev-tools.
Most apis that support directly calling from the client-side usually have some protection to prevent abuse since they are essentially just "floating out there" on the client side. Those that don't should really just be called via server-side code. Anything else you do (like the advice above) will only make things less convenient to malicious attacks but isn't actually making things hidden, which is basically impossible for client-side api keys.
We can also restrict user from accessing
config.jsby using few line in .htaccessI think htacces is considered insecure and the file can still be read through js
Let's say I am using netlify functions, and I made the repo public on Github, is there any way to hide my APIs, because I don't want to make my repo private.
Use .env varibal and add .env in .gitignore file
But what the website and the functions are fed directly from the github repo to Netlify... Will it still work in that case?
Yes you just have to setup environment variables in netlify Also
To do so read official documentation
👉 Netlify Docs📗
Hey @bradtaniguchi the 1st point that you have mentioned is for the case when someone has already pushed the code to github without adding the .js file (containing api keys) to .gitignore, right?
How is the security compromised in this case? because as far as I understand if I add any file to .gitignore it wouldn't be committed to github so if anyone clones the repo he wouldn't have that config.gs file (where all the api keys are present). Correct me if I'm wrong
The reason your keys are compromised is even if after you realized you pushed your secrets, and you perform these changes mentioned to remove them from your workspace, your secrets still live in your repo's history. So someone can just go back in-time to your commit to get the secrets you committed. Your only options are to force change the history to make it seem like it never happened, and even then github might still have the reference to this code at some level.
Or even if you did everything right and cleared up your repos history and github isn't hiding anything, no one said someone didn't just clone/copy/get the keys you committed in the time it was exposed.
This prevents the 1st scenario I'm talking about, but the 1st scenario should be addressed at some point since its so common. The 1st scenario being you forgot to
.gitignoreyour secrets and uploaded them. Github currently has a bunch of built in security features that will point out compromised keys automatically, which can help at least alert you you did something wrong.