Published on: December 17, 2024
In the ever-evolving landscape of cybersecurity, client-side security has become a crucial battleground. Third-party scripts, often essential for modern web functionality, also present significant security risks. Simon Wijckmans, founder and CEO of c/side, recognized this growing threat through his experience at Microsoft, Cloudflare, and Vercel. Drawing on years of experience managing client-side security products, he launched c/side to provide a specialized, proactive approach to third-party script monitoring and protection. In this interview with SafetyDetectives, Simon discusses the inspiration behind c/side, the unique challenges of client-side security, and how his company’s innovative methods are shaping the future of the industry.
What inspired you to start c/side, and how does your background influence the company’s mission to monitor, secure, and optimize third-party scripts?
I’m Simon Wijckmans, founder and CEO of c/side. I’m originally from Belgium, but I split my time between London and San Francisco. My career began at Microsoft, and I’ve also worked at Cloudflare and Vercel. At Cloudflare, I managed client-side security products, giving me about four to five years of experience in this field.
During that time, I realized that it was common for established security vendors to ship “solutions” for client-side security as side products. But that these products were often incomplete, easy to bypass, and driven more by marketing than substance. It became clear that client-side security needed a dedicated approach. As companies have gotten better at protecting their infrastructure and open-source dependencies, there’s still a major blind spot—what’s happening in the user’s browser. This oversight presents a significant attack vector, which inspired me to build c/side as a specialized, effective solution for client-side security.
What unique challenges do third-party scripts present to businesses, and how does c/side address these challenges better than traditional security solutions?
A lot of web-based data theft occurs through third-party scripts. These scripts are often responsible for attacks that steal credit card details and login credentials. While the execution happens in the browser, businesses are still liable since they’re the ones that added the scripts to their website.
Major incidents like the British Airways breach highlight the risks. If you visit baways.com, you’ll see a full write-up of that incident. More recently, the Polyfill attack affected around half a million websites. The full scope of what happened from February to June of this year remains unknown because no one was actively monitoring it. This kind of uncertainty is damaging to both security and brand reputation.
C/side addresses this problem by providing continuous monitoring of third-party scripts. We make it possible to track these scripts in real time, identify any anomalies, and take action immediately. Our approach ensures businesses know exactly what’s running in the user’s browser—something most traditional solutions fail to do.
Third-party scripts often operate in obscurity. Can you explain how c/side brings transparency and control to this aspect of client-side security?
Our biggest differentiator is that we provide full visibility into the actual third-party scripts. Unlike competitors, we analyze and display the full script payload. This allows us to spot and block malicious intent before it’s executed in the user’s browser.
Here’s why that’s crucial: Every time a website requests a third-party script, that web server can send a different response. A bad actor with access to a third-party domain could tailor an attack to a specific IP addresses, headers and even as specific to targeting an individual user. If the response changes with each request, traditional monitoring methods won’t catch it. Our solution records and analyzes each unique payload, giving businesses the ability to see exactly what’s being served to each user. This level of transparency is critical for ensuring security.
With regulations like PCI DSS 4.0.1 requiring tamper-detection mechanisms, how does c/side help companies meet such compliance standards effectively?
Two key PCI DSS requirements, 6.4.3 and 11.6, target the use of third-party JavaScript on payment portals. While we didn’t build c/side specifically for PCI DSS compliance, our platform addresses these requirements directly—and goes beyond them. Payment card providers recognized that the majority of credit card skimming today happens client-side in a browser. Therefore they had to take action.
Compliance alone isn’t enough. If an attacker can hijack the “Pay Now” button or intercept a payment form before it’s secured, the company is still at risk. That’s why c/side doesn’t just monitor payment portals. We secure the entire user journey, ensuring attackers can’t exploit earlier steps in the process.
By monitoring the entire site, c/side provides complete visibility and protection, not just for specific payment forms. Our approach ensures compliance with requirements 6.4.3 and 11.6, and it provides the holistic security companies need to stay ahead of attackers.
Your platform utilizes AI and historical context for script analysis. How does this approach enhance threat detection and response compared to conventional methods?
Traditional methods typically rely on threat feed intelligence or content security policies (CSPs), but both have serious limitations.
- Threat Feed Intelligence: Relying on threat feeds is ineffective because of how targeted attacks work. As I mentioned earlier, each request to a third-party script can generate a different response. Threat feeds don’t track those dynamic changes, which means they’re often outdated and unreliable.
- Content Security Policies (CSPs): CSPs limit which domains can load scripts on a page, but they’re too broad. For example, you might allow scripts from Google Analytics, but that doesn’t restrict what’s inside those scripts. Companies often whitelist large platforms like GitHub User Content or Google Tag Manager, which can introduce security risks.
- Behavioral Detection (e.g., JS Scrambler, HUMAN Security): Some tools rely on hooks that trigger alerts when a user’s browser behaves abnormally. But attackers can easily detect and bypass these hooks. Worse, if the attack succeeds, you have no historical record to analyze and improve your detection rules.
- Web Crawlers: Some security tools crawl websites weekly to list the scripts in use. But because attackers can serve different responses based on user agents or IP addresses, crawlers never see the malicious scripts. Attackers simply give the crawler “clean” scripts, resulting in a false sense of security.
Our approach is different. We analyze the full payload of every script and use AI to review, understand, and identify potentially malicious activity. By storing a historical record of scripts, we ensure companies have data to improve detection and response. If an attack happens, our customers have a full audit trail of the event—something other tools can’t offer.
How do you see third-party script management evolving in the next few years, and what role do you envision c/side playing in that landscape?
AI is going to play a significant role. Large language models (LLMs) are already capable of reading and understanding JavaScript code. If you feed JavaScript into a commercial LLM, you’ll get back useful, detailed insights. I think that’s going to be a major differentiator in the market. Tools that analyze code in real time—rather than relying on threat feeds—will become the standard.
Another trend is the growing awareness of client-side security issues. The problems haven’t gone away, but the media’s attention has shifted elsewhere. Compliance mandates like PCI DSS are bringing these issues back into focus. As more companies realize the risks, we’ll see increased adoption of tools like c/side. We’re prepared for that shift and plan to continue leading the charge on client-side security.