Do I need to worry about front end javascript code security, like watch out for any kinds of vulnerability in my front end code if I don’t have any kind of back end? So front end website/application only.
3 Likes
Yes.
The biggest concern in a JavaScript app that doesn’t have a backend is leaking your API keys. For example, if you use a mail service or talk to a 3rd party API to fetch weather data.
These 3rd party services will normally require you to pass a secret key with your requests. Without a backend or using a serverless function these keys will end up in the users browser which is then possible to steal.
1 Like
All the code in your frontend is visible. There are no secrets in the frontend. Anything you need kept secret should be handled by the backend.
2 Likes
So basically, if I just have a normal website(static website or reactjs/vuejs application) and without any kind of secret or api keys that I need to hide and of course no back end, basically I don’t need to worry too much about font end code vulnerability??
Even if I have a user input??(like a todo list but not saving it any where so when the browser refresh, all the todo list are gone)
If there is nothing in your frontend code that you do not want the world to see, no problem.
The main problem comes with API keys. Take for an example an app I made when I was learning. I needed to get some google maps stuff, to search for data on a city that the user inputs. But that needed an api key. Soooooo… I had to create a microservice. My frontend app would call my backend with the city name, and my backend would call google with the api (safe and snug in the backend code) and then my backend returned the data to my frontend.
As to your todo list, the frontend is going to have to deal with frontend stuff. Obviously you should never store sensitive used data in your frontend code. It might even be questionable to store it in the browser storage (but a todo list is probably OK). If you want to send it to a backend, you’d want it over a secure link and require some kind of key or authentication to get it back.
But for a little todo toy app? I wouldn’t worry about it.
1 Like
So, sorry, come back to the front end code vulnerability part, so if I don't have any secret or api keys to hide and no sensitive data stored at the front end, and no back end, but for example, if I have many vulnerabilities to my front end code, can (bad)site visitor/site user still hack it or break the site or somehow manipulate/change the code or use the vulnerabilities to do something to my site, and when other (good)site visitor visit the site, the site got changed and maybe is dangerous due to some hacker manipulate/change the code or whatever… and is all because of my front end’s code vulnerability?? (one example I can think of is, maybe using chrome dev tools to find site vulnerability and do something with it)
I don’t really want my site/codes to get manipulated just because the site visitor/site user can get access to my front end HTML, CSS and Javascript through using something like chrome dev tools…
Well, the security of the site - that is different.
I’m not expert, but usually when we talk about a site getting hacked, we are talking about someone interfering with the code in some way or gaining access to something they shouldn’t because they got a password or found an unprotected endpoint.
For a simple static frontend site like the one you are describing, they would have to hack your host - it would have nothing to do with the security of your site. Or you would have to participate by (even unknowingly) installing some software. As far as passwords - there are not. As for endpoints - there are none.
Again, I’m not expert - someone tell me if I’m wrong. These are good questions to be asking. Some of this is covered in the laster FCC modules. There are books written on internet security and online courses. But for a simple static toy site? Not only is the danger pretty much nil, no one will want to.
I don’t really want my site/codes to get manipulated just because the site visitor/site user can get access to my front end HTML, CSS and Javascript through using something like chrome dev tools…
Just to reemphasize, yes, everyone can see all the HTML, CSS, and JS code in every web site. That is just how it is. You can make it a little more difficult using minimizers and uglifiers, but still - someone can get it. Nothing should ever go into your frontend code that you wouldn’t want published - it is basically published. But just because someone can see that doesn’t mean that they can hack it and change it.
Just to reemphasize, yes, everyone can see all the HTML, CSS, and JS code in every web site. That is just how it is. You can make it a little more difficult using minimizers and uglifiers, but still - someone can get it. Nothing should ever go into your frontend code that you wouldn’t want published - it is basically published. But just because someone can see that doesn’t mean that they can hack it and change it.
So this doesn’t count as front end code vulnerability?
html
<body>
<button class="banana">Click</button>
<script src="./scripts.js"></script>
</body>
js
const myBtn = document.querySelector("button");
const fruits = {
fruitOne: "Apple",
fruitTwo: "Orange",
fruitThree: "Peach"
};
myBtn.addEventListener("click", (evt) => {
/* Get the first class from myBtn element */
const fruitProperty = evt.currentTarget.classList[0];
if (!fruitProperty) {
return;
} else {
/*
Do something with "fruitProperty" variable,
either use it to get property from fruits object or
set new property to fruits object
*/
fruits[fruitProperty] = fruitProperty;
}
});
So like above code, I only want user to add property key “banana” and property value “banana” to fruits object(which they only need to click the button cause the class is already set to “banana” on myBtn element) but if a site visitor/site user open up the chrome dev tools and change the html myBtn element class to something else, then the thing they change to will get added to the fruits object instead of key and value “banana”. So does this count as a vulnerability? and if not why??(user can change my code and add some random thing to the fruit object)
Yes, they can break their copy of the app. Toyota doesn’t want me to replace my tires with licorice and fill the gas tank with peanut butter, but how would they stop me? Why would they care? Your hacker can only break his copy. I’m not sure how we could stop that and I’m not sure why we would care. Putting peanut butter in my gas tank just breaks my car and it doesn’t do anything to tarnish the reputation of Toyota.
1 Like
In this case the user is only “hacking” himself.
2 Likes