Linkedin Tag

Back to blog

What is Client-Side Security?

Friday, September 27th, 2024

Carlo D'Agnolo's profile picture

Carlo D'Agnolo

Marketing & Growth

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.

ClientSideSecurity-cside.dev.webp

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.

A thought exercise

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 executed an attack if a request is made from Beverage.ltd and avoid every other website that uses the script. The security provider just buys threat feed intel from providers, and only flags 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.

You can secure your site in seconds using c/side.

Carlo D'Agnolo's profile picture

More About Carlo

I'm in charge of marketing & growth at c/side, educating companies and users on the web about the dangers of third-party scripts and the broader client-side security risks.