娇色导航

Hi everybody, welcome to DEMO, the show where companies come in and showcase their latest products and services. Today, I'm joined by Simon Wijckmans. He is the CEO and founder of c/side. Welcome to the show, Simon.

Thanks for having me.

You're coming all the way from the U.K., so I appreciate you making the trip. Tell us a little bit about c/side and what you're going to be showing us today.

So c/side stands for "client side"—we basically do client-side security. It's a logical step, since we’ve worked to protect our infrastructure, buying firewalls and all that kind of stuff. Now, we also protect open source dependencies on registries like Node Package Manager.

There are all kinds of attacks looking for less monitored places to execute—and of course, the browser is one of those. So that’s what we do.

When we ask who this is designed for, I’m pretty sure you just said “attacks” and “security.” So this is aimed at security professionals within companies, correct? Yeah, mostly.

I’d say companies in the e-commerce space or those that generate significant revenue through their websites—whether by accepting credit card information or running ads. In line with that, PCI DSS now requires client-side security, since the majority of credit card theft these days happens via client-side attacks.

What problem are you solving here? Why should companies care about this issue? When we talked before the show, you mentioned things I wasn’t even aware of—especially regarding third-party scripts. Correct.

The thing is, we don’t actually know what’s happening in a user’s browser. When you build a website, you add all kinds of dependencies, many of which make fetch requests when loaded in the browser—and you don’t see any of that happening.

So when we talk about client-side attacks, it could be anything: crypto mining, stealing credit card information or login credentials, capturing sensitive information from input forms—you name it. Anything you can do in a browser for legitimate reasons, you can also do for illegitimate reasons.

So what would companies be doing if they didn’t have c/side? Would they only find out about an attack after the fact, once they’re already in trouble? Or is there another way to monitor for this?

There are a couple of open-source options to help limit risk—like using Content Security Policies or being very selective about the client-side fetches you allow. But even then, there’s often a significant gap.

What we see is that, when a client-side security incident occurs, it can take days, weeks, even months before it’s discovered. For example, in the case of credit card theft, session tokens might be stolen, bucketed, and resold on the dark web—making it very hard to trace the origin.

Many companies don’t even know they’ve suffered a client-side attack. The Polyfill incident last June was a great example—a script on over 500,000 websites was potentially doing things we still don’t fully understand. Wow.

That’s intense. All right, show me the cool demo you’ve got. Sure.

We built a website for a fictitious company called Beverage Ltd. It’s a drinks company, and like most websites, it asks for your email to sign up for a newsletter. You can also buy products on it. If you go to the cart, you can enter your credit card info.

We’ve added some analytics tools—if you inspect the site’s tag, you’ll see it’s built on Webflow. We’ve also added PostHog, Google Analytics, ServerCell Analytics, Clicky, PartnerStack, and Intercom—the common support chat widget. Now, even if I don’t submit a form, anything I type is being keylogged.

I’ll refresh the page and show you. Here are things I typed yesterday—"help, help, help." A script on this site is actively stealing that information and sending it elsewhere. In fact, there’s even a crypto miner running on this website—it’s mining crypto in users’ browsers.

Definitely a site with major client-side issues. Now I’m going to implement c/side. There are multiple ways to do this depending on the framework.

This site is built on Webflow, but if you're using React, Next.js, or another modern framework, we recommend our NPM package—it provides the highest level of security. I’ll paste the c/side script into the Webflow settings and publish. After a few seconds, the site will update.

Now, if we reload the page—you’ll see the scripts are rerouted through c/side. For example, domains now go through proxy.cipher.dev, one of our testing URLs. These scripts now flow through us, so we can inspect and block malicious activity.

You’ll notice my laptop fan has stopped spinning—it’s no longer crypto mining, because that’s now blocked. Let’s go into the c/side dashboard. Here, you can see your site, the scripts that were blocked, and those flagged for review.

The browser is a bit of a wild west—people do things with JavaScript that aren’t necessarily malicious, but are unconventional. So we have three paths: block the script, flag it for review, or allow it if we know it’s safe. Now let me show you a blocked script—the crypto miner.

This one’s heavily obfuscated to avoid detection. It uses eval, spikes CPU usage, and was flagged by our AI classifier. We parse the code and run it through an LLM to determine intent. As you can see, this script was blocked by c/side, triggered by our obfuscation and script rules.

Here are other scripts running on the site—like analytics tools—that didn’t raise concerns. But during onboarding, customers are often surprised by how many scripts are running. That’s because a client-side script often loads more scripts, which load even more—creating a noisy and complex environment.

As I mentioned, PCI DSS version 4 now requires monitoring of credit card payment pages for client-side scripts. We built a compliance portal to support that. PCI DSS asks you to justify why each script is on the page.

Here’s a list of all scripts on the payment page—like Intercom, JSDelivr—and you can provide justifications. For PostHog, for example, I can write one manually or click “Get AI Review Suggestion.” Since we inspect the payload, we know what the script does and can auto-generate a justification.

I’ll accept that AI suggestion, and it's now recorded. This is a subrequest of PostHog—I’ll do the same. The platform recognizes its parent-child relationship automatically.

So this helps with PCI DSS compliance, right? Yes, specifically Section 6.4.3.

And on the right here, you’ll see security headers, which relate to Section 11.6.1. That section requires monitoring headers to guard against malicious server-side behavior that might disable security controls. This helps with audits—you can download a clean PDF report to share with auditors.

(Though on this Wi-Fi it doesn’t seem to be loading.)

You’ve been around for about a year, and I assume this will evolve. Where can people go to learn more about your service?

Our website—cside.dev. We offer a free tier so anyone can onboard a site. We didn’t want to build security tools only for enterprises. There’s also a low-cost business tier—$100/month—ideal for companies making a few hundred thousand dollars a year. And of course, we have enterprise and partner/MSP tiers as well.

Great stuff.

Simon, again—thanks for the demo.

Thank you very much.

That’s all the time we have for today’s show. Be sure to like the video, subscribe to the channel, and drop any thoughts in the comments. Join us every week for new episodes of DEMO. I’m Keith Shaw—thanks for watching!