Is client side security dead - or a crucial part of the future?
10 Feb 2024tl;dr
This is one of my favorite essays so far: client side security is a niche tech field that seems to be unneeded for the most part. As someone whoâs very passionate about it, thatâs something thatâs hard for me to accept. After (Shubham Shah) addressed this topic in his tweet, I elaborate into the mixed feelings I have with this field, as well as present my take on the industry and most importantly, strongly argue why I think client side security isnât dying - but in fact is more crucial now than was ever before.
Does client side security still matter?
Not too long ago, the well known security researcher Shubham Shah wrote the following tweet:
For the first 3-4 years that I was working in infosec, I found client side security so exciting. I stayed on top of every new technique and studied new techniques closely. After this, I took a step back and realised that all of my work on client side security felt helpless,âŚ
— shubs (@infosec_au) September 3, 2023
And to me this was magical, because Shubham - like a good security researcher - managed to press some of my weak points pretty accurately. Truth be told, Iâve being brewing with similar feelings for long periods of time throughout my career, and I still do. To this day I battle my strong desire and pure passion for the field of client side security with rational thoughts and the understandable wish for a long, stable and thriving career as an individual in the tech industry.
Shubhamâs tweet made me realize that the fact that this dilemma had taken me through multiple emotional rides throughout my career already, had got to the point where itâs time to digest and self-reflect client side security, in terms of its relationship with the cyber-security industry, the importance of its role in the ecosystem, and its future.
To me, that usually means to write. Writing helps me clear my head and put my thoughts in order. In regards with the client side security industry, itâs time to do just that - so here goes.
Shubhamâs tweet
So first of all, whatâs all the fuzz about?
For context, Shubham is a security researcher with a lot of experience, both with vulnerability research and with application security. And from his tweet, it seems that his vast experience with application security had made him understand that when applications were suffering from security breaches, it was almost always the responsibility of components that werenât the client side:
âI analysed the reasons companies faced great hardship, and most of the time it was not because of client side security issues but rather server side issues that led to critical impact on their infrastructure.â
Shubham made me connect to his experience by expressing a similar passion he had out of hope and belief (almost self convincement?) that securing the client side is truly important, until it failed to hold water against logic and reality:
âFor the first 3-4 years that I was working in infosec, I found client side security so exciting. I stayed on top of every new technique and studied new techniques closely. After this, I took a step back and realised that all of my work on client side security felt helpless, useless, to some extent. â
As a security expert, responsible for auditing the security of applications by naturally going after the most impact apps can go under, Shubham had to shift his efforts towards other areas than the client side:
âA part of me thought that client side security issues still had impact to the end users (and they still do), but I couldnât cite a single example where a company had lost so much due to a client side issue. It really shaped my mindset and perspective for what to be looking for when auditing an application, and is the reason why I became so deeply invested in server side security.â
But what really got me, was the fear of ever saying the following words:
âI still try and stay on top of client side security exploitation techniques, but they donât really excite me anymore.â
Because knowing the industry and relating to Shubham sees things, I can see myself ending up in a similar place. And I take this harder than Shubham maybe, because of the relationship I have with client side security, for better or worse.
My relationship with client side security
In this section Iâll lay out some context about me and the path I went through for you to better judge my perspective on client side security and the promising future I see for it. I encourage you to read it for the important context, but you can still decide to skip to my take on client side security.
The beginning
As an 18yo Israeli, I was to serve the Israeli Defense Forces by duty.
There are many roles to take as part of this obligation, and the intelligent and/or fortunate ones serve in the Israeli Intelligence Corps, a batch of units which are mostly responsible for collecting valuable intel for national security. The most impactful way for achieving that is by practicing what you might know as âOffensive Cyber Securityâ, which is a primary reason why Israel is considered to be a world-class leader in cyber-security.
The most popular one, which I ended up at, is called 8200 ...
If truth to be told, on that spectrum between intelligent and fortunate, I was probably a lot closer to fortunate than intelligent. The proof of that was the fact that the professionality gap between the training course I was accepted to and the team I ended up in was the result of no less than an accident (a story for another day).
Naturally, such a gap introduced significant difficulties for me, as I struggled a lot to keep up with the rest of the team. I was surrounded by highly competent individuals, who were each highly skilled in each of their own distinct field of expertise, whereas I was a colorless weak link.
It was no picnic.
After a year and a half of doing mostly QA and struggling to learn Python, it was decided that our team should take some extra responsibility by absorbing a security field that belonged to another team, meaning no one in my team were familiar with that field - Browser JavaScript (offensive) Security.
Being the perfect opportunity for me to take on something that is not only a bigger contribution to the joint effort than the things Iâve done so far, but most importantly a chance for me to find my own color and to become an expert in a field no one else (in my team) is - I jumped on it immediately.
And so began the bumpy ride of mine I call âmy careerâ.
The choice
One decade forward, and Iâve been focusing almost entirely on JavaScript security. Working for the best in the field, Iâve gained experience in almost every client side security field one can imagine - whether itâs vulnerability research, anti debugging, web extensions security, bot detection, supply chain security or JavaScript security.
While fun for the most part, the ride was bumpy because for some parts of it I was unsure of whether focusing so much on client side security is a smart move. Taking such an active part of this industry, I learned (the hard way) that this is a niche industry, and while you might feel pretty wanted by some companies, such skills wonât serve you similarly for the big amount of the others.
Leaving PerimeterX (now Human), I wanted to move on to the offensive cyber-security industry to advance my vulnerability research and exploitation skills (right after finding a major breach in WhatsApp Desktop and a CSP bypass in Chromium).
After learning more about this industry, combined with personal choices, I changed my mind and decided to pass on this industry, which got me to think - if not this, what then?
The wrong choice?
This was a 3 months turbulence of emotions around the fear of whether I wasted the most important years of my career on this one niche field no one has any interest of?
I mean, being a security pro is great, the need for security specialists isnât going to end anytime soon, especially in popular fields such as cloud security. Same goes for JavaScript - being a pro in JS and an excellent JS engineer is also a safe bet as JS is still the most popular programming language in the world.
But a strict combination of the two? Perhaps too small of a cell in the tech industry matrix of needed skills.
As part of this roller coaster I was fortunate enough to consult with great people I look up to on the matter.
One of them was Bionicâs co-founder (acquired by CrowdStrike) Eyal Mamo which I got to know from the military service.
Eyal clearly understood where I was coming from and agreed I should broaden my horizons so that my perspective on security is wider, even if just slightly.
And thatâs how I joined Bionic for a standard FullStack software development position - a very different one from what Iâve been focusing on before - out of belief fully betting on client side security might not be the smartest thing to do.
And while Bionic turned out to be a great experience (both for working there and for it to be later acquired), I left Bionic only 1.5 years later - because the passion for client side security didnât die off, it only became stronger, leading me to my next great next opportunity.
The right choice
While working at Bionic, I kept learning about the world of client side security, and two initiatives I found fascinating were LavaMoat and SES.
After partly wrapping my head around them and the problem they address, it came clear to me JavaScript security is far from a solved problem - and that directly affects browser client side security.
At the time I was working on my own side project called Snow to address another non-solved problem in client side security I refer to as the Same Origin Concern.
I reached out to @kumavis (the creator of LavaMoat) to discuss the different problems we both attempt to address, and it made sense to both of us that my work could be a great addition to the LavaMoat project which focuses on securing JavaScript both for their main product (MetaMask) and for anyone in the world.
⌠So why am I telling you all this đ?
My take on client side security
What does the future hold for client side security? Given my experience and perspective, Iâll try to answer that.
The death of client side security?
Referring back to Shubhamâs take, applications are architected so that the backend of an app carries the core responsibility for the security of the app.
And rightfully so - in contrary to the client side, the backend is more capable of that for being able to manifest logic that no outer entity has access to nor the ability to tamper with, whereas with the client side itâs the other way around - anything thatâs being served to the client is by definition fully accessible for it to both read and modify.
This core principal leads to an important conclusion - the client side is not to be trusted to begin with, so why even bother securing it?
This hopefully gives you a taste of the anxiety I went through multiple times throughout my career - if thereâs no good reason to secure the client side and this is the one single thing I feel I have an advantage in, is my career based on an unneeded skill?
Sure, there are some use cases for securing the client side, but are they niche reasons barely relevant to the tech industry, as it will mostly focus on securing other components of their applications (probably forever)?
Thatâs the conclusion I was arriving at when I joined Bionic to gradually migrate away from my passion for client side security.
But right before giving up for good, I decided to go for one last round by joining MetaMaskâs LavaMoat effort, to see once and for all whether thereâs still something to it, or is client side security basically a lost cause?
Client side securityâs second chance
Joining LavaMoat, meeting brilliant people focusing on securing the JavaScript ecosystem, I rediscovered the reasons for why client side security is going to matter a lot in the future and why I personally feel confident betting on it more than ever.
I mostly have two main reasons in mind:
Software Composability
This one is a reason I had in mind even before joining MetaMask. In fact, our shared take on it is what drove LavaMoat to adopt Snow into its set of security tools.
The bottom line is that the evolution of web application development had put us in a place where telling what code our application is going to execute is pretty much impossible.
Saying that 10 years ago would have sounded ridiculous, but since then supply chain driven development became so prominent that most web apps nowadays are composed of around 90% of code written by other entities - entities we can hardly verify nor blindly trust.
And trust is far from enough too, because even if the maintainer is verified to be trustworthy for years, meaning they have no malicious intentions - a malicious entity can still compromise access preserved to the maintainer and abuse it.
So from a world where unwanted code execution was mostly XSS, which can be specifically identified and mitigated, malicious code can now be introduced from within the application itself - a far harder form of abuse to detect.
In addition to the form of âSupply Chain driven developmentâ, Software composability comes in other forms that also require strong client side security.
âPluggable platformsâ are a great example - since web applications are so advanced these days, many operate as platforms, allowing developers to create plugins to be plugged into the platform on user demand.
Shopify, Wix and more are platforms allowing developers to upload plugins aimed for users to install on top of the basic services these platform offer to enhance the benefit they give, forming more powerful and versatile services for their users - a form of practice weâll see more and more as we go on thanks to the web allowing JS software to easily consume smaller programs.
No reason to look too far either - MetaMask is also a platform which allows the extension of its basic services using developers-made plugins called âsnapsâ.
The âsnapsâ plugin system required great client side security engineering (conducted by us internally) for the same reason the formers went through similar such careful care - those plugins are designed to run in the client side, within the app/platform itself, and that means it must endow them with some basic capabilities while confining them from obtaining more power in the app than they should have.
And to make things even more tricky - both âPluggable platformsâ and âSupply Chain driven developmentâ use cases can theoretically (and practically) be included and/or executed both at runtime and build time, making it sometimes impossible to address using backend prevention solutions (especially for runtime).
In other words - code we donât trust can potentially end up running in our application, and trusting backend solutions to prevent it can no longer cut it, because statically identifying this is just too complex of a task.
And when preventing something is too hard, the second-best way to tackle it is by waiting for it to happen.
And when it comes to breached web applications, it happens on the client side.
Thus, the industry will have to result into client side based detection tools in addition to backend prevention attempts, as such breaches can generate big damage (potentially too big to recover from) - a risk that companies canât afford to take.
In the past years, attempts to create such security tools were already made (coming from the co-creator of PerimeterX CodeDefender), but quite unsuccessfully. Perhaps because the timing was off, or because my take is simply wrong - time will tell.
But one thingâs for sure: composability driven software is a great turn - itâs far more efficient (âbuild on the shoulders of giantsâ) and the JS language as well as its ecosystem specifically are well suited for such engineering methodology. The further we advance, the more softwareâs going to rely on other software, and therefore the need for supporting this long term process securely is more important than ever (in which the client side takes a major role IMO).
Decentralization
This is a more controversial one. Based on who usually reads my stuff, you either see and expects the upsides the Web3 paradigm barres with it (and therefore will relate to this argument) or youâre here for the JavaScript security take and this argument might not speak to you really. If thatâs the case, stick around regardless. If you like technology and information security, you might find this angle interesting to think about, regardless of your stance.
Even if Iâm way off about the former argument, and the problem of composable software is completely addressable from the server end (which it isnât) - what if there wasnât a server to help in the first place?
Many would claim there is a decentralized revolution in action, making this argument worth of examination at least.
In the Web3 space for example, thatâs kind of the case.
Instead of web apps you have dapps (decentralized apps) which are normal web applications on the client side, but they connect to something slightly different from a traditional server (a common example would be the Ethereum network), and those dapps can practically operate without a traditional server to begin with.
While somewhat unrealistic on one hand, a big portion of the Web3 industry actually expects dapps to not incorporate a server that stores/processes user information - thatâs actually a big part of the Web3 idea for many people in the first place.
This strongly applies to credentials - in the Ethereum ecosystem for example, authenticating to dapps and operating them is expected to be done via the private key of the user in front of the Ethereum network rather than some centralized-managed server (it isnât really authentication but thatâs good enough for the explanation).
This dramatically shifts away from the traditional security paradigm referred to earlier, where servers are not only expected to participate in ensuring the safety of applicationsâ users, but are also expected to do the heavy lifting.
But in Web3 architecture, thatâs no longer possible - for better or worse, the most sensitive actions being performed in dapps take place in the client side (from start to finish).
This turns the tables - if before the server was such a great way to design safe applications that client side security was barely even relevant, in Web3 context, client side is the only way to secure that part of the application.
Itâs also important to clarify - this extends beyond just Web3. The idea of decentralized services is realized on other forms as well, such as financial services (aka DeFi, e.g. Bitcoin), P2P applications and more, but in this essay we focus on client side security in context of browsers, whereas client side security of other decentralized services will be affected differently depending on their supporting infrastructure.
This came very clear to me working on MetaMask, and is why Iâm so proud of the JavaScript security work we do - Since the MetaMask crypto wallet is a browser extension that is theoretically vulnerable to the same threats described in context of dapps (and even more so being the critical bridge between dapps and the Ethereum network), in order to not die, MetaMask is forever obligated to ship the most secured client side product ever.
And while slightly less so, dapps and other Web3 client side services are under a similar obligation - otherwise the idea behind Web3 (and decentralization in general) wonât ever truly take off.
Therefore, if you see some sense in the decentralized movement and believes itâs here to stay to whatever extent you can imagine, you should agree the need for advanced client side security technology is more critical than ever.
Client side securityâs critical role in the future
I guess this is my way of telling 5/10 years ago Gal:
â Donât panic.
While client side security might feel like some useless niche sometimes, remember itâs also a matter of timing.
Telling what turns the tech industry is going to take is hard as it is such a difficult to predict industry that takes seemingly random curves occasionally.
Those curves can be surprising and can lead particular technological fields to the road of adoption or complete failure - itâs hard to tell.
And as for client side security, similarly to many other niche fields, it might turn out just fine. â
At the same time, this is also my take on Shubhamâs observation on client side security:
When sticking to traditional client side security (XSS and such), I tend to agree it might die off a little from a security researcher perspective, as this becomes a more and more closed gap both because addressing traditional client side security is more simple and because traditional security architecture mainly leans on the server side.
But given the POVs above, I believe client side security will become more advance and more complicated, thus naturally will introduce new attack surfaces for researchers.
Based on the experience of coming up with the threats the MetaMask app is potentially exposed to, I have multiple examples to back this claim up:
JavaScript Sandboxing
LavaMoat is a security tool written in JavaScript and built on SES we maintain, with which weâre able to sandbox each of our MetaMask JavaScript dependencies to confine them and minimize the amount of damage they can do if they get breached.
The Same Origin Concern
Snow is another security tool we use to prevent JS code from being able to create new same origin realms (aka iframes). This is a vital tool in case sandboxed code we donât trust manages to use the limited set of capabilities we endowed it to form a new realm, because new realms offer access to all capabilities the browser offers - including those we intentionally didnât endow it.
DOM Confinement
DOM API is historically designed so that you can travel from one node to basically any other node (and even the document itself and its owner window object) effortlessly, and preventing that was proven to be very hard (see the CaJa project).
LavaDome attempts to solve a subset of this problem, but a more complete solution doesnât seem to be coming any time soon.
Are those actual problems though?
Remember the context here: for the traditional web, where the client side isnât complicated and thereâs a server taking the responsibility for securing the app - these problems arenât too relevant, and current browsersâ threat model is rather enough.
But the context here is that for use cases falling under the arguments presented above, code running in the same origin as the app is no longer as trustworthy as it was considered traditionally - and the implications of that are big, because if browsers are good at isolating cross-origin entities from each other, the new take here is that similar confinement is now necessary in a lower resolution, where two entities within a single origin arenât trustworthy by default anymore - which results in the security gaps listed above.
And thatâs why I believe the web would have to adjust accordingly - whether by virtualized solutions such as those we compose at MetaMask or by advocating for browser-level solutions to properly address these gaps (probably both).
Furthermore - itâs important to note that the success/failure of client side security is affected by more means than just technological gaps (such as financial/political motives within the global cyber security ecosystem), but this essay focuses strictly on the technological angle.
And with that in mind, I expect a comeback for client side security - for the industry, for the vendors and most importantly - for the researchers!
I donât just guess - youâre welcome to further explore the work we advocate for around web and client side security which we find so important for MetaMask to become safer as well as allow other builders to secure their apps too: Gal Weizman: JavaScript realms used to bypass and eliminate web apps security tools - A problem with a WIP solution , Gal Weizman: JavaScript Realms: The Blank Spot In Web App Runtime Security and more