(And where to store your backend API/Session tokens?)
XSS otherwise known as “cross-site-scripting” attacks is also a very serious threat to your credibility as a service provider. These attacks may originate from your frontend side but can also easily be prevented with all the good practices that must be implemented by you.
Imagine a web page that is importing a functionality i.e. in form of a plugin from a third party using “<script src=”//some-third-party-url/plugin.js”></script>” even though at time of this integration, this remote script was thoroughly inspected and contained no vulnerabilities, but consider that now it does! The contents of this remote script has since been changed and this third party provider may itself either be unaware or has knowingly implanted an XSS vulnerability at your frontend.
With this XSS implant, now the attacker has the ability to execute arbitrary javascript code in your frontend and possibilities are limitless for this attacker. Basically they now have full and complete control over your frontend web!
While attackers can modify the contents of your website to show certain messages, advertisements and can even redirect your viewers away, but the most sinister XSS attacks are more discreet! What if they can secretly hijack the secret API/session tokens that your users use to communicate with your backend to execute certain API calls? This may even mean leak of confidential personal information or even financial loss for your users without any mistake of their own since as a service provider it is your responsibility to ensure there is now XSS vulnerability on your frontend.
Now before we continue any further, it is very important to stress the fact that this is not just limited to “script” tags but an XSS can just as easily be implanted from CSS or images, so trust nothing! Never take these small things for granted. Never import such elements into your frontend from a fellow webmaster or suspicious CDN.
- Don’t trust third parties!
Ideally each and every element served on your web pages should be hosted locally. Don’t link to remotely hosted javscripts or stylesheets or images when you can simply download to include them locally with the rest of your frontend. It’s really this simple.
- Integrity checks!
While personally I haven’t come across any reason to not just store the resource locally but if you somehow have one and must include a resource that is remotely hosted then use Subresource Integrity (SRI) checks by simply computing a hash of the given resource at the time of your integration and providing it as attribute to your “<script” or “<link” tag, which looks something like this:
Also make use of CORS “crossorigin” attribute; But please note that following integrity checks can mean next to nothing if the remote resource is not hosted with a valid SSL certificate, meaning that you are not importing this resource over HTTPS.
What about NPM?
There is no other way to put it but modern day front-end developers simply love NPM! It is their lifeline!
But are you aware when you start a fresh new Angular project, without any contribution of your own, the angular CLI will install all these packages from NPM that are nearly 400MB comprising around 36,000 files just to get you started. That is around 700+ packages installed from hundreds of different vendors. And then there will be some that you have to include yourself in your packages.json file while building your shiny and sublime frontend.
Now a big part of your final production angular build is compiled from all these 3rd party resources; And this is also true for every other frontend development framework such as React or VueJS.
All the same rules and potential vulnerability threats apply here as well; What if a vendor turns evil and creates a new release or simply replaces existing ones to include one of those XSS implants we have talked about? What if it secretly exists even right now as you are developing your application?
While it’s always a possibility, as I always say and believe, creating an application is all about commitment. NPM guys have created a reporting mechanism so when a package is reported/flagged, it will highlight every time you use the npm command. Vulnerabilities are classified into categories such as high, moderate and low; It is not really always about XSS, can even be as simple as memory leak. Always use the npm audit command to learn more about what exactly these vulnerabilities are and whether they have been fixed in next releases.
Now here is when your commitment as developer or a good service provider comes into question. Your application should be regularly monitored and audited even after the build has rolled into production; Even if there is no further development work going on; Your application should continue to be monitored and audited for such vulnerabilities throughout the lifetime of your application.
How to protect API/Session tokens?
While an XSS attack does not directly bothers your backend but if API/Session token is stolen then every user that logs into your frontend will be compromised for the duration of this XSS attack.
As a developer, if you google about where you should store the API or session token that you have issued from your backend API for you user; You will find a lot of contradicting information especially involving localStorage and how it is bad for you to store such tokens in localStorage. But truth be told, if an XSS vulnerability can steal a token from your local storage in the first place then it can essentially do pretty much anything else as well.
In fact, localStorage or sessionStorage are completely safe to store sensitive information such as API and session tokens.
There is no need to be paranoid about it as it doesn’t really matter if such a token is stored in-memory, in localStorage, in sessionStorage or even in a HttpOnly cookie; Being in bed with XSS, there is always a way for this token being read and stolen one way or another despite how and where it is stored. If you have XSS, this is pretty much “it” for you!