Client-side security covers all operations occurring on a user's device, such as a browser on a computer or other device when interacting with a web application. Attacks targeting the client-side aim to manipulate the user’s interaction with that web application to steal data or inject malicious code.
Why secure the client-side?
A lot of attention is already placed on securing the supply chain. NPM and similar registries are covered by a range of solutions, cloud security is an entire industry, infrastructure security as a whole and firewalls are mature industries. Companies know these risks and spend accordingly to prevent issues. But one massive attack vector, which is on the rise, is forgotten: the browser.
The browser is what we call client-side. Third-party JavaScript code is fetched by the browser and executed, and website owners really have no idea what is being loaded with certainty. Yet, they are at fault when something goes wrong.
And it goes wrong. Most recently, the Polyfill attack which we were amongst the first to cover, showed how large the attack reach goes. Though there are many more examples.
Here we wrote out the full browser supply chain and how to secure it. In 2018, David Gilbertson shared a viral Medium post about how to use client-side scripts to steal payment information. Everything written in the blogpost is still possible today.
We believe it’s only a matter of time (and more attacks) until this is finally going to be taken seriously and securing client-side fetched dependencies will be broadly adopted.
If we use The OWASP top-10 list of most common client-side attacks, we see that JavaScript is practically always involved. JavaScript is not to blame, but it should be secured. Especially when you have a site that deals with logins, payments or other forms of data transfer.
1. Broken client-side access control
This often involves JavaScript to manipulate the DOM or access client-side assets inappropriately. We wrote here how this section in the web supply chain is often overlooked.
2. DOM-based Cross-Site Scripting (XSS)
This involves the insertion of malicious JavaScript into the Document Object Model (DOM).
3. Sensitive data leakage
While not always directly involving JavaScript, data leakage can occur through scripts that access and transmit sensitive data without proper controls. This is technically how Kaiser Permanente leaked +13.4 million customer's data.
4.Vulnerable and outdated components
This involves outdated JavaScript libraries and components that contain known vulnerabilities. This is part of what happened in the recent Polyfill attack which targeted +490k websites.
5. Lack of third-party origin control
Third-party scripts include JavaScript, which can access data within the website’s origin if not properly controlled.
6. JavaScript drift
This specifically refers to changes in JavaScript code that go undetected, potentially leading to malicious behavior.
This is part of why we created our detection the way it is. We check the full payload of the script instead of just the sources. And we save these changes to train our models and detect new vulnerabilities.
7. Sensitive data stored client-side
JavaScript can be used to store sensitive data in ‘localStorage’, ‘sessionStorage’, or cookies.
8. Client-side security logging and monitoring failures
JavaScript can be involved in logging client-side events and monitoring activities. Failures can occur if these scripts are not properly implemented or monitored.
9. Not using standard browser security controls
Although this risk involves broader security practices, JavaScript is often subject to these controls (like CSP, iframe sandboxing, etc.) to prevent injection and other attacks.
10. Including proprietary information on the client-side
Sensitive business logic and proprietary algorithms can be included in client-side JavaScript code.
Why third-party JavaScript is dangerous
The tricky part is that JavaScript is dynamic, and the delivery method of client-side script too. This makes third-party scripts that are served in the browser of the user (client-side) are prone to dangerous attacks. Just because they can serve anything, and depending on the site where the request is made from, adjust their behaviors and neither party is aware of what they do as every response can be different. The website has no say, and most users aren’t checking this themselves.
Yet most attention in security is currently given to server-side JavaScript and other inbound attack methods.
In our article on What is the browser supply chain and our launch campaign on Supply Chain Risk Doesn’t End at NPM we dug deeper into the need to secure the full chain. And that message is to be repeated here.
Securing the client-side is equally crucial.
Regulation is catching up too, as PCI DSS 4.0 now includes improved security measures targeted at the client-side by March 2025.
But, too many tools rely on allow-list and threat feeds, which fundamentally don’t work. They “don’t know what they don’t know” thus new or targeted attacks come through before being detected.
To put this into perspective: Imagine a sports drink company named Beverage.ltd were to use a security product that solely relies on threat feed intel. The provider claims to be able to protect the client-side using their advanced ‘military grade ML based’ detection capabilities ~ this may sound silly but some sound like that. Beverage.ltd fetches a compromised 3rd party script. The bad actor can make the script only execute an attack if a request is made from Beverage.ltd and avoid every other website that uses the script. The security provider actually just buys threat feed intel from providers and flags only the scripts that were noticed by those providers. Beverage.ltd would have an attack successfully execute against them, impacting their customers. By design, the security product they purchased would simply be unable to flag the attack.
Unfortunately today many security products are built that way. This is often because of a fundamental misunderstanding of the attack vector at hand by both the customer and the provider or simply because the repercussions on the security vendor are little to none.
In 2024, we must do better. Real people face real hardship as a result of these lacking security products. Security companies should not create a false sense of security.
At c/side, we check every third-party script’s full payload and stop 0-day JavaScript attacks. Even on our free tier, we provide:
-
Monitor and Analyze: Continuous monitoring of client-side activities to detect and respond to threats in real-time.
-
Secure Data Handling: Implementing best practices for secure data storage and transmission on the client-side.
-
Third-Party Script Management: Vetting and managing third-party scripts to ensure they do not introduce vulnerabilities.
-
Compliance Assurance: Helping businesses meet compliance requirements through robust client-side security measures.