I hate to disagree, but I'm not sure that you should EVER send your personal/company API keys/database information to a client. If a client needs access to an external service that should most likely be something your backend can handle with either a POST route or a websocket if real time is needed. Just my 2 cents
But you can then still send a request to that backend API to proxy the request to the API-keyed API. You can of course control access (as described in the video) but you can still do that on many APIs - essentially rendering the key alone worthless.
It really depends on the scope of the API key-and whether it is meant to be public or private. As long as the key can't access anything outside of your desired scopes, it is perfectly fine to store them client-side. Some APIs also allow you to write "rules", which you can use to allow/deny access based on your own conditions with a script or similar.
Conclusion: Confidential data needs to be not sent to the browser, like using php. Non-confidential data like data meant for a user can be sent to the user, and can be processed using js.
Remember: People have cracked Minecraft's compiled and obfuscated Java bytecode and written tools to deobfuscate said code. Given that such a massive and complex game can still have it's (Compiled and double obfuscated, mind you) bytecode cracked, your Javascript code is basically helpless against anyone determined enough
Keep in mind that restrictions does not mean that no-one can use it outside of your app (except IP addresses restrictions). Since the Firebase API is over HTTP, it is easy to craft request headers to suit the restrictions. E.g. set the Referrer header to be the same as the site (HTTP referrers restriction). If someone wanted to use this on their site, they would need to create their own HTTP server, which sets the Referrer header to make the request and thereby circumvent the restriction. API Keys however are the most secure way (for now) that you can control access and avoid misuse. API keys are usually seen as temporary (even though they might have a long lifetime). It is a good idea to renew your API keys every now and then-for example every 6 months or a year. Also be very cautious when you use API keys that allow scoping (e.g. create/read/delete/update scopes) which may alter, delete or read data. If your API key is going to be public-as seen in this video-always keep the scopes to a minimum. In cases where you may want to use an API, but don't want to share the keys, use your webserver which doesn't need to expose any keys to make a request to the third-party platform. Firebase is a special case, in that it is real-time so you would loose that real-timeness, unless you use for example web sockets to message back and forth-though this requires a lot of maintenance that might not be worth it.
Also, if you'd like to restrict it even further some APIs provide a way to define your own conditions, usually called "rules". This allows you to write scripts that you can use to restrict the access on behalf of the third-party, without the need of your own backend.
It's bad design baked right into the Google API, or whatever API. If I were rolling this myself, all identifying info would be on the server. Requests would be made from the client, to the server where the API key would be inserted, then to whatever endpoint you're aiming for - like Firebase. Just because Google said use it, doesn't mean it's the best option.
Good video. I consider all client side JavaScript fairly vulnerable. IP white listing isn't a great solution for production level apps. Although difficult, you can spoof the IP. As you mentioned at the end of the video really the most important services need to be in the back-end. Also a good idea to use SSL/TLS
I wonder how that IP whitelist works, because the requests are being made from the end-users' browser, so any IP address can be doing the request really. Also, if the domain checking is based on the referrer header, that can be very easy to spoof as well. So that essentially means it can be easily abused. What we should be discussing is what sort of features can really protect you in this case.
So essentially run a server-side app and use environmental variables. Then create an api for your js frontend to interface with. You can configure your own permissions on the user by coding them yourself since its your api. Mern stack + typescript it is.
to be honest I am a bit flinched regarding NodeJS backend. I am a Newbie but everyone is saying better code your backend in Python, Java, C# etc. I wanted to learn Python anyways since it opens you a lot of doors additionally.
@Max, at @4:28 you are showing a minified code, but, at the bottom of that part you can see a { } button, and if you click on it, the code will be unminified.... easy to read, easy to understand =)
That is why we have cors so we can restrict call by domain. So we can accept the call to our api only if it comes from a specific domain. For Native clients like mobile and desktop we can obfuscate the code
Excellent as always, I would like you to also do a GraphQL course, I am sure that many like me also need it, it is one of the few things that are missing from the Academind UA-cam list
Thanks a lot for your great feedback and for your suggestion Randy! GraphQL is indeed an interesting topic, I do not have any concrete plans regarding a course as of now though, but this might of course change in the future :)
this video has everything to do with the title. i got an answer to something that was bothering a lot on watching this the 3rd time. i dont know why i didn't get it before. i think people who are into spa will find that the title of the video goes well with the content (since i noticed some comments about title and content )
1. If you really care about the users reading your stuff, *obfuscate* it. Makes it way more complicated to understand and read, but also makes the *files* many times *bigger* than the original. If it's important (like Google's Login page), obfuscate it. (look at the stuff in the debug window on Google's Login page, there is everything not only obfuscated but also the ids and many things change either on reload or just often) 2. Pretty print also makes it way easier to understand minified files 3. Don't use Api Keys etc in Javascript, just send everything to PHP/the server and verify everything there etc, then use backend to send the data for example to firebase 4. IP Whitelist doesn't work that great, because the IP addresses change in most cases every night or so. That also happens to servers, that's why you need a DNS
Point 1 and 4 are garbage. Obfuscation only helps against people who are too lazy or not skilled enough, aka the people you don't need to worry about. If someone skilled enough wants to steal your code, they will. It's better to spend the energy you would use to hide your code to actually improving your product. You don't need a DNS because the IP changes, if the IP changed the DNS lookup wouldn't work either. DNS is nothing more than turning to "donttalknonsense.com" to some IP. In that sense, whitelisting should work. The suggestions of the video are also garbage. Even if things seem secure, it's creating unnecessary attack vectors.
Interesting. I developed a React application which is 100% React, therefore all the code is visible. I did worry about it being copied but it's not a app for production, just to demonstrate my skill.
Ok, but i would have implemented it in my Backend-Server and send the user-credentials to my own API wich interacts with Firebase. This way no one can see my access-Keys and i can use the resulting data (if i wanted to) and implement my own logic to keep my stuff save. Just a tought i had ^^
Can't someone copy the firebase config credentials, embed it in their own app, and then write queries to get all the data? Especially like usernames, emails, etc
So if I have a use-case, in which I have developed a PWA for a client of mine, and the users need half of the time, open and use the PWA in an offline mode (they just read PDFs btw), I as a developer, still have to send a POST request to my own custom-made API? in other words, how can I still log-in in an offline PWA app?
Not really you can unobfuscate code quite easily and if people want to crack your code they can do it for games there where cases of games getting cracked before they come out.
Meaning you can really hide js just to don't show confidential information, to add i believe extra confusion to people inspecting your code you can minify it
thanks man this is really helpful. can you do a follow-up on that AWS Lambda function or a secure web-service on how to log data or login users securely without exposing the API credentials?
I am experiencing exact same problem, my API key is being exposed in the web console. From UI, my request passes through AWS Gateway, that requires API key for my request to pass through to server. What could be the better way to hide my API key (in Angular)from client.? Thank you
its not just api key or whatever . what about changing the code? if you make a front page game and you dont wanna put the code in the server what if the client change the rules of the game? for example change the time clock. if you have thousands of users playing simultaneously you dont wanna calculate the time and every movements and the rules in your server
Moin Max, was hast du für dieses Jahr noch alles an Kursen oder Videothemen geplant ganz grob? Ich finde fast alle Themen interessant und komme jetzt schon kaum hinterher das Meiste zu schauen :D
Das kann ich ehrlich gesagt nicht genau sagen Lukas, ich genieße es das relativ spontan zu entscheiden, daher habe ich keinen genauen Plan bzgl. zukünftiger Themen bzw. ändere auch meine groben Planungen öfter mal ;)
You almost answered my exact question! I have a Vue front end, with a Django backend (all running off the same host & port (proxied), using sessions). As it stands, a user can get full access to the front-end of the system by faking a login on the client-side, i.e. flipping a 'loggedIn' boolean. They will not get any data, but they will see the full UI, and I don't think I want this. How can that be prevented?
Lazy loading modules with canLoad guards is how it's being done in Angular. However it's always possible to circumvent with enough effort. And it shouldn't matter because your front-end should not contain the value, but access the value of your application.
Hi. I was wondering - (for paid-for chrome extensions) with Google stopping their payments and licensing api's - previously you couldn't read the client-side code if it's a purchased extension if you use the licensing api, but soon that wont be the case. So for example, with the code for a purchased extension that's a content script - the code would become visible. Is there a way to prevent this please? Not so bad maybe if it relies on a lot of server side code as well but if its just say, a content script that a developer wants to charge for then its a bit of a problem. Thank you
How should I implement google address autocomplete because getting that data from backend can be slow and if i keep the api key on the frontend then people can use my quota .. so how do you advise me to handle that?
In the Google API Console, the IP restriction is only for server side requests. For the front end you would have to use the "HTTP referrers" restriction, and the problem is that the referrers header can be easily spoofed. And if you create a lambda function (or hide the key on the server side in general) doesn't your function merely act as a proxy to the API service? Couldn't somebody create a script that uses your lambda function to fill your newsletter db with random emails? (or in cases of paid APIs to increase your bill) The only sort of solution I found is to have a rate limiter in the server side function (or the API service itself, if possible), so that e.g. allow only 3 newsletter sign-ups from the same IP within a certain period.
I actually did talk about this, too. Yes, the function is a proxy and yes, you can of course call it. But since I also use API Gateway together with Lambda, I can control access there. It is one way of creating a wrapper where you can add an IP whitelist for cases where the API you're wrapping doesn't give you a native way of doing that.
I haven’t used Jscrambler before. How exactly does it differ from other obfuscation tools? I’ve been working with reverse engineering obfuscated JavaScript for years now and there’s always a way to get back to the original source (or at least a working version of it). There’s no real way to completely hide code on the client.
I'm also using firebase and placing the api key in frontend code also makes me worried. What if we store the api key in the backend and we just request that. But before sending it to client, we encrypt it first and decrypt it once we receive it and store it to our secured local state. It is still possible to read the logic and decrypt the api key but it should be hard to that. However, people can still extract the api key by looking at the network requests. It is included in the api url, header, body etc.
Here's my tip: a) search for a web site that ulgify js code. b) back up all your js files c) ulgify all your js files d) deploy the uglified version of your files, .gitignore your jsFilesBackup Be happy.
if you want to store this client-side why would you not just set the keys as an environment variable so they accessible to the dev but they are not rendered to the DOM for client-side viewing? Can someone help me understand where my logic is wrong here so that I can improve this in the future? -Thank you
Cmd + f is still a problem. However you can use this to prevent making values available in git. Though if it’s available in the front-end, that probably doesn’t help
5:37, so lets say somebody copies the api key and creates a fake, phising website and creates a form, if i logged in in the fake.com website, will the fake.com website be able to steal data?
Hey Max, i just deployed a MERN app in heroku, when i inspect the source in browser it exposes the src/components folder of the react client part of my app. Hope you can help me with whats wrong with my setup
First off, ensure that you always deploy your app in production mode. Secondly, the reason for this is source maps. It can be helpful if you use things like Sentry to get accurate and detailed errors, but does give people the possibility to view the actual source code, depending on the variety of source maps. Find documentation about how to change how source maps are generated for your framework, and see if there is any settings which limits the output to only the necessary parts that you need. If you use webpack, you can set the devtool setting to e.g. `nosources-source-map` to completely hide the source code and only retrieve line numbers. This comes with the limitation of not being able to see the exact problem, though.
Hi,There as u have shown that we can see are Js code through inspect element and also we can hide it for security reasons,can u please provide me solution like i have uploaded my website on a free domain and though i can see all code and files from inspect element,i want to hide everything it is showing complete directory with folder names and files and can be downloaded easily
How can I protect the nodejs source codes Academind? because I want to upload my application to a cloud server ( maybe AWS ) and I do not want cloud staff access to my source codes! thanks
I actually released a Vuetify series almost a year ago or which one do you mean? academind.com/learn/vue-js/a-comprehensive-project-with-vuetify-and-firebase/
You Said You Can Lock Down Access To Your Domain. In That Case If Someone Loads Your Website On Chrome Then He/She Can Modify Data Using Developer Console By Executing JS. What You Really Need For These Issues Are Firebase Rules.
Thanks for the nice feedback and suggestion! I'll note it but I believe there already are plenty of videos on that topic. So it's not #1 priority right now to be honest - still noted! :)
Thanks so much for your great feedback Vince. I do have two JavaScript courses actually, a general JS course (www.udemy.com/javascript-bootcamp-2016/learn/v4/?couponCode=ACAD_M) and an ES6 course (www.udemy.com/es6-bootcamp-next-generation-javascript/?couponCode=ACAD_M)
What if API also require secret key? Is it OK that users can view it? What about APIs that can do some things that could do something that you don't want other users do?
Hi Max, I am new with React app. I learn videos tutorial from your udemy channel. I got some problems with building react project and deploy build files to herokuapp. And my full source code is completely show extract of my project source code look like. Please help me, Thanks
Your cloud function code will not be accessible. But anyone with the URL to it can send a request and execute it of course, that's what I meant with the "wrapping function". But this gives you more control of course and (as you correctly stated) ensures that your key isn't directly shared.
Biggest reason why I obfuscate my code: To hide my incompetence.
True it is.
I just thought about it and then saw your comment.
🤣
I do it to make it HARDER to steal my work
obfuscation is not the solution
@Pavel Rakowski please show me a tutorial how exacty it works
Tldr: hide JavaScript? Nope
If it's client side, client can see it. If it's server side, server can see it.
Thanks captain obvious
Like I've got a coock but at the toilet still using the pussy...
@@cipherxen2 😂😂
He sounded so dumb right?
I hate to disagree, but I'm not sure that you should EVER send your personal/company
API keys/database information to a client. If a client needs access to an external service that should most likely be something your backend can handle with either a POST route or a websocket if real time is needed. Just my 2 cents
But you can then still send a request to that backend API to proxy the request to the API-keyed API. You can of course control access (as described in the video) but you can still do that on many APIs - essentially rendering the key alone worthless.
It really depends on the scope of the API key-and whether it is meant to be public or private.
As long as the key can't access anything outside of your desired scopes, it is perfectly fine to store them client-side.
Some APIs also allow you to write "rules", which you can use to allow/deny access based on your own conditions with a script or similar.
Well usually that's a public key they see, the secret key is in the server end which can't be seen in the browser.
Client will however be in touch With API true Wireshark and intercept the pakets with API secret... Even SSL can't help... I can hack it anyway....
I agree with this logic.
Stick to the point man..your videos are good,but you should focus on the point on title of video..
this
Yaap
I think he explained it very well
@@DerClaudius window
I appreciate his help, but yeah, he's long-winded for sure.
Conclusion: Confidential data needs to be not sent to the browser, like using php.
Non-confidential data like data meant for a user can be sent to the user, and can be processed using js.
Video summary: No problem showing your front end js code to the clients.
u saved me 10 mins, thank you :D
@@pneujai 😁️
@@sergsergesrgergseg why do u put backend codes in clients
Remember: People have cracked Minecraft's compiled and obfuscated Java bytecode and written tools to deobfuscate said code. Given that such a massive and complex game can still have it's (Compiled and double obfuscated, mind you) bytecode cracked, your Javascript code is basically helpless against anyone determined enough
06:49 you can change the headers with curl so that won't help.
May be we could implement JWT or CORS
Keep in mind that restrictions does not mean that no-one can use it outside of your app (except IP addresses restrictions). Since the Firebase API is over HTTP, it is easy to craft request headers to suit the restrictions. E.g. set the Referrer header to be the same as the site (HTTP referrers restriction).
If someone wanted to use this on their site, they would need to create their own HTTP server, which sets the Referrer header to make the request and thereby circumvent the restriction.
API Keys however are the most secure way (for now) that you can control access and avoid misuse. API keys are usually seen as temporary (even though they might have a long lifetime). It is a good idea to renew your API keys every now and then-for example every 6 months or a year.
Also be very cautious when you use API keys that allow scoping (e.g. create/read/delete/update scopes) which may alter, delete or read data. If your API key is going to be public-as seen in this video-always keep the scopes to a minimum.
In cases where you may want to use an API, but don't want to share the keys, use your webserver which doesn't need to expose any keys to make a request to the third-party platform. Firebase is a special case, in that it is real-time so you would loose that real-timeness, unless you use for example web sockets to message back and forth-though this requires a lot of maintenance that might not be worth it.
Also, if you'd like to restrict it even further some APIs provide a way to define your own conditions, usually called "rules". This allows you to write scripts that you can use to restrict the access on behalf of the third-party, without the need of your own backend.
Title is not match exactly what you want to convey... It is fully related cloud api restriction not JavaScript code.
Starts by saying you can use this with any backend, gives a solution specific to firebase.
He explained that it could be applied to any backend and it's true. I did it with my nodejs server.
Can't someone copy the firebase config credentials, embed it in their own app, and then write queries to get all the data?
Finally a man that talks about this things!
Thanks so much, this honestly means a lot to me!
@@academind Can't someone copy the firebase config credentials, embed it in their own app, and then write queries to get all the data?
The video content has nothing to do with the title
It's bad design baked right into the Google API, or whatever API.
If I were rolling this myself, all identifying info would be on the server. Requests would be made from the client, to the server where the API key would be inserted, then to whatever endpoint you're aiming for - like Firebase.
Just because Google said use it, doesn't mean it's the best option.
Good video. I consider all client side JavaScript fairly vulnerable. IP white listing isn't a great solution for production level apps. Although difficult, you can spoof the IP. As you mentioned at the end of the video really the most important services need to be in the back-end. Also a good idea to use SSL/TLS
I wonder how that IP whitelist works, because the requests are being made from the end-users' browser, so any IP address can be doing the request really. Also, if the domain checking is based on the referrer header, that can be very easy to spoof as well. So that essentially means it can be easily abused. What we should be discussing is what sort of features can really protect you in this case.
Yup, like without SSL you can't even use Stripe API.
The best is to have to api keys. One for --prod and one for --dev. Then lock only one.
So essentially run a server-side app and use environmental variables. Then create an api for your js frontend to interface with. You can configure your own permissions on the user by coding them yourself since its your api. Mern stack + typescript it is.
to be honest I am a bit flinched regarding NodeJS backend. I am a Newbie but everyone is saying better code your backend in Python, Java, C# etc. I wanted to learn Python anyways since it opens you a lot of doors additionally.
@Max, at @4:28 you are showing a minified code, but, at the bottom of that part you can see a { } button, and if you click on it, the code will be unminified.... easy to read, easy to understand =)
That is exactly what I mean => The code might look unreadable but it's actually pretty easy to read.
I have struggled to English language but this video can easy to catch ... thanks
That is why we have cors so we can restrict call by domain. So we can accept the call to our api only if it comes from a specific domain. For Native clients like mobile and desktop we can obfuscate the code
Excellent as always, I would like you to also do a GraphQL course, I am sure that many like me also need it, it is one of the few things that are missing from the Academind UA-cam list
Thanks a lot for your great feedback and for your suggestion Randy! GraphQL is indeed an interesting topic, I do not have any concrete plans regarding a course as of now though, but this might of course change in the future :)
Randy Tellez Galan I agree
Academind I also want to vote for a GraphQL course
React - Relay - GraphQL would be dopeski. :D
this video has everything to do with the title. i got an answer to something that was bothering a lot on watching this the 3rd time. i dont know why i didn't get it before. i think people who are into spa will find that the title of the video goes well with the content (since i noticed some comments about title and content )
1. If you really care about the users reading your stuff, *obfuscate* it. Makes it way more complicated to understand and read, but also makes the *files* many times *bigger* than the original. If it's important (like Google's Login page), obfuscate it. (look at the stuff in the debug window on Google's Login page, there is everything not only obfuscated but also the ids and many things change either on reload or just often)
2. Pretty print also makes it way easier to understand minified files
3. Don't use Api Keys etc in Javascript, just send everything to PHP/the server and verify everything there etc, then use backend to send the data for example to firebase
4. IP Whitelist doesn't work that great, because the IP addresses change in most cases every night or so. That also happens to servers, that's why you need a DNS
Point 1 and 4 are garbage. Obfuscation only helps against people who are too lazy or not skilled enough, aka the people you don't need to worry about. If someone skilled enough wants to steal your code, they will. It's better to spend the energy you would use to hide your code to actually improving your product.
You don't need a DNS because the IP changes, if the IP changed the DNS lookup wouldn't work either. DNS is nothing more than turning to "donttalknonsense.com" to some IP. In that sense, whitelisting should work.
The suggestions of the video are also garbage. Even if things seem secure, it's creating unnecessary attack vectors.
Interesting. I developed a React application which is 100% React, therefore all the code is visible. I did worry about it being copied but it's not a app for production, just to demonstrate my skill.
Thanks bro but i don't want anybody to steal my alert('are you sure you want to leave this page') logic magic code😃
That is all too understandable!
Ok, but i would have implemented it in my Backend-Server and send the user-credentials to my own API wich interacts with Firebase.
This way no one can see my access-Keys and i can use the resulting data (if i wanted to) and implement my own logic to keep my stuff save.
Just a tought i had ^^
White listing isn't available for most APIs. The best solution is to invoke the API from the server side.
I guess the point is you don't hide your code, you just don't put anything needs hiding in it.
Can't someone copy the firebase config credentials, embed it in their own app, and then write queries to get all the data? Especially like usernames, emails, etc
So if I have a use-case, in which I have developed a PWA for a client of mine, and the users need half of the time, open and use the PWA in an offline mode (they just read PDFs btw), I as a developer, still have to send a POST request to my own custom-made API?
in other words, how can I still log-in in an offline PWA app?
Can’t hide it but you can make it almost unreadable
Not really you can unobfuscate code quite easily and if people want to crack your code they can do it for games there where cases of games getting cracked before they come out.
Filip Cordas that’s what I said
Can't someone copy the firebase config credentials, embed it in their own app, and then write queries to get all the data?
Atleast newbies like me can't copy
Meaning you can really hide js just to don't show confidential information, to add i believe extra confusion to people inspecting your code you can minify it
thanks man this is really helpful. can you do a follow-up on that AWS Lambda function or a secure web-service on how to log data or login users securely without exposing the API credentials?
I am experiencing exact same problem, my API key is being exposed in the web console. From UI, my request passes through AWS Gateway, that requires API key for my request to pass through to server. What could be the better way to hide my API key (in Angular)from client.? Thank you
its not just api key or whatever . what about changing the code? if you make a front page game and you dont wanna put the code in the server what if the client change the rules of the game? for example change the time clock. if you have thousands of users playing simultaneously you dont wanna calculate the time and every movements and the rules in your server
Moin Max, was hast du für dieses Jahr noch alles an Kursen oder Videothemen geplant ganz grob? Ich finde fast alle Themen interessant und komme jetzt schon kaum hinterher das Meiste zu schauen :D
Das kann ich ehrlich gesagt nicht genau sagen Lukas, ich genieße es das relativ spontan zu entscheiden, daher habe ich keinen genauen Plan bzgl. zukünftiger Themen bzw. ändere auch meine groben Planungen öfter mal ;)
You almost answered my exact question! I have a Vue front end, with a Django backend (all running off the same host & port (proxied), using sessions). As it stands, a user can get full access to the front-end of the system by faking a login on the client-side, i.e. flipping a 'loggedIn' boolean. They will not get any data, but they will see the full UI, and I don't think I want this. How can that be prevented?
Lazy loading modules with canLoad guards is how it's being done in Angular. However it's always possible to circumvent with enough effort. And it shouldn't matter because your front-end should not contain the value, but access the value of your application.
Hi. I was wondering - (for paid-for chrome extensions) with Google stopping their payments and licensing api's - previously you couldn't read the client-side code if it's a purchased extension if you use the licensing api, but soon that wont be the case. So for example, with the code for a purchased extension that's a content script - the code would become visible. Is there a way to prevent this please? Not so bad maybe if it relies on a lot of server side code as well but if its just say, a content script that a developer wants to charge for then its a bit of a problem. Thank you
In Angular => put firebase credentials inside environment.ts file.. then init you FirebaseModule inside app.module.ts
How should I implement google address autocomplete because getting that data from backend can be slow and if i keep the api key on the frontend then people can use my quota .. so how do you advise me to handle that?
In the Google API Console, the IP restriction is only for server side requests. For the front end you would have to use the "HTTP referrers" restriction, and the problem is that the referrers header can be easily spoofed.
And if you create a lambda function (or hide the key on the server side in general) doesn't your function merely act as a proxy to the API service? Couldn't somebody create a script that uses your lambda function to fill your newsletter db with random emails? (or in cases of paid APIs to increase your bill)
The only sort of solution I found is to have a rate limiter in the server side function (or the API service itself, if possible), so that e.g. allow only 3 newsletter sign-ups from the same IP within a certain period.
I actually did talk about this, too. Yes, the function is a proxy and yes, you can of course call it. But since I also use API Gateway together with Lambda, I can control access there. It is one way of creating a wrapper where you can add an IP whitelist for cases where the API you're wrapping doesn't give you a native way of doing that.
Wanna 'hide' your code? JSScrambler. No more people misusing our api
I haven’t used Jscrambler before. How exactly does it differ from other obfuscation tools? I’ve been working with reverse engineering obfuscated JavaScript for years now and there’s always a way to get back to the original source (or at least a working version of it). There’s no real way to completely hide code on the client.
But how the other website encrypt their code? example like facebook google when u do inspect element, all the javascript code is unreadable
click bait. this video should be called: "Is it a problem to have an API key in my JS code".
I'm also using firebase and placing the api key in frontend code also makes me worried. What if we store the api key in the backend and we just request that. But before sending it to client, we encrypt it first and decrypt it once we receive it and store it to our secured local state. It is still possible to read the logic and decrypt the api key but it should be hard to that. However, people can still extract the api key by looking at the network requests. It is included in the api url, header, body etc.
Here's my tip:
a) search for a web site that ulgify js code.
b) back up all your js files
c) ulgify all your js files
d) deploy the uglified version of your files, .gitignore your jsFilesBackup
Be happy.
if you want to store this client-side why would you not just set the keys as an environment variable so they accessible to the dev but they are not rendered to the DOM for client-side viewing? Can someone help me understand where my logic is wrong here so that I can improve this in the future? -Thank you
There is another problem that come next with some vulnerable npm packages like (st, moongose=12, ....)
The biggest reason I hide my code is because I don’t want my friends looking at my front end code!
Cant we just load the configs from process.env by tweaking the webpack? It wont make it completely secured but less vulnerable?
Cmd + f is still a problem. However you can use this to prevent making values available in git. Though if it’s available in the front-end, that probably doesn’t help
5:37, so lets say somebody copies the api key and creates a fake, phising website and creates a form, if i logged in in the fake.com website, will the fake.com website be able to steal data?
Keys and secret info go in environment vars on server. They're perfectly safe there.
Doesn't help with frontend JS code though.
"Harder"? what? You need to press {} pretty code button on chrome only.
Hi Max, your explanations are always out of the world
I like the way you explain
So great to read that you like my explanation style Rohit, thank you very much for your comment!
Academind my pleasure
Hey Max, i just deployed a MERN app in heroku, when i inspect the source in browser it exposes the src/components folder of the react client part of my app. Hope you can help me with whats wrong with my setup
First off, ensure that you always deploy your app in production mode.
Secondly, the reason for this is source maps. It can be helpful if you use things like Sentry to get accurate and detailed errors, but does give people the possibility to view the actual source code, depending on the variety of source maps.
Find documentation about how to change how source maps are generated for your framework, and see if there is any settings which limits the output to only the necessary parts that you need.
If you use webpack, you can set the devtool setting to e.g. `nosources-source-map` to completely hide the source code and only retrieve line numbers. This comes with the limitation of not being able to see the exact problem, though.
Hi,There
as u have shown that we can see are Js code through inspect element and also we can hide it for security reasons,can u please provide me solution like i have uploaded my website on a free domain and though i can see all code and files from inspect element,i want to hide everything it is showing complete directory with folder names and files and can be downloaded easily
hey sir I am taking you react js I personally want to thanks you for you effort
Also, cloud services let you create environment variables that are not "visible" in the code
May be we could implement JWT or CORS?
My boss asked me, "Why didn't you write any code?" I told him, "Because I hid it." He didn't believe me. :'(
😁good one. have to remember that when a customer asks, why they can't see anything
How can I protect the nodejs source codes Academind? because I want to upload my application to a cloud server ( maybe AWS ) and I do not want cloud staff access to my source codes! thanks
Hi when is your vuetify series is coming? Eagerly waiting , huge fan of you
I actually released a Vuetify series almost a year ago or which one do you mean? academind.com/learn/vue-js/a-comprehensive-project-with-vuetify-and-firebase/
Academind thank you
What if somebody change headers by curl? This can avoid our whitelist
Can we also use environmental variables? Some js frameworks allow that.
Nope.
That’s why google push JavaScript so hard.
Steal all your idea.
you also can use global variables when you host to keep it safer
So as HTML5 Game Developers where content is 100% in the client, we're essentially screwed?🤔
Great, great vídeo! Thanks and Cheers from Brazil!
Thanks a lot Flavio, really cool to read that! Best wishes from Germany :)
Great video as usual! Thanks for sharing the information!
Great video. This was one of my concerns but didn't have time to look into.
Just fantastic to read that the video was helpful for you, thank you very much for your comment!
I felt better to see the past comments before starting the video
can you download source code of website whose code is locked
Thats some very valuable information. Thanks. Appreciate the detailed explanation. Keep it up
Thank you :)
Using sever side frameworks like Web Firm Framework is more secure.
who else search this vid trying to get some tips to hide our incompetent code in the browser inspector that even Junior Programmers can read....?
What about .env files for hiding api keys? Isnt that a secure option?
Not if the keys end up in your frontend JS code - which they will if you need them there.
You Said You Can Lock Down Access To Your Domain. In That Case If Someone Loads Your Website On Chrome Then He/She Can Modify Data Using Developer Console By Executing JS. What You Really Need For These Issues Are Firebase Rules.
Do you know how they lock access to a domain?
this does make sense,y ou talking about hiding code or you talking about firebase
Another great video!!! Next time could you make a video about MVC(Model-View-Controller). Thank you.
Thanks for the nice feedback and suggestion! I'll note it but I believe there already are plenty of videos on that topic. So it's not #1 priority right now to be honest - still noted! :)
Thanks , Max i would love to take your course on Javascript if u have :) u are the best instructor
Thanks so much for your great feedback Vince. I do have two JavaScript courses actually, a general JS course (www.udemy.com/javascript-bootcamp-2016/learn/v4/?couponCode=ACAD_M) and an ES6 course (www.udemy.com/es6-bootcamp-next-generation-javascript/?couponCode=ACAD_M)
Thanks bro :)
Thanks man you are the best 😃
Thanks a lot for your great feedback, YOU are the best!
Which IDE you are using? is it Visual Studio?
I use Visual Studio Code.
as a beginner bug bounty hunter, please keep making insecure javascript code,and if you could hard-code secret keys and tokens, the better 😂 😂
I faced this issue a while ago. Seems like we solved it the same way.
What if API also require secret key? Is it OK that users can view it?
What about APIs that can do some things that could do something that you don't want other users do?
Always keep your secret key secret. Write some server-side code if you really want to be secure.
Awesome video straight to point with perfect explanation i really got allot of questions answered for me
It really makes me happy to read that the video was helpful for you, thank you very much for sharing this fantastic feedback!
Thanks for so good explanation!
Hi Max, I am new with React app. I learn videos tutorial from your udemy channel. I got some problems with building react project and deploy build files to herokuapp. And my full source code is completely show extract of my project source code look like. Please help me, Thanks
Isn't http referrer too easy to manipulate for someone who is going to try to steal your API key from chrome dev tools?
The title is misleading
sir I want to hide html comment "/" from source in my website. please help me.
put it in
or what ever your backend programming language
and will make comment only exist in source code like php code
Really enjoying your Udemy courses...especially Vue.
It's really great to read that Rich, thank you very much for your comment and for your support!
mobile devs : loud Evil laugh
Dear Max ... Can I put the API key in cloud function if my project host in firebase ?
Thanks
Your cloud function code will not be accessible. But anyone with the URL to it can send a request and execute it of course, that's what I meant with the "wrapping function". But this gives you more control of course and (as you correctly stated) ensures that your key isn't directly shared.
Could we simply obtain the sensitive data through ajax calls instead
Not really because that code (as well as the request response) will still be accessible through dev tools.
Makes sense
Why not create a service and let the backend handle the api calls? Get that shit away from the ui....
Hey thanks max for such a good tutorial. :)
Thank YOU for your comment Siddhesh, happy to read that you like the video!
Obfuscation does not make anything more secure.
Thanks for this! Great explanations.
Thank YOU for your great feedback!
What ???? No one heard about jquery VM, CDN, Obfuscatation, same as PHP CodeIgniter ... This is an old problem that long ago has been solved