Every time your user or visitor loads your website or web application, they don't only load components from you, but also components from the wider web and third-party vendors. You only have visibility on what is happening server-side, not what is actually being loaded into the user's web browser.
Similar to how a Web Application Firewall (WAF) proxies HTTP requests, cside proxies JavaScripts you ordinarily have no control over today. This lets us see exactly what the user sees.
Attackers can't provide a clean script to security solutions and a bad script to users. We get the exact copy of the payload, deobfuscate it, and run it against detection systems including LLM-based analysis.
We look at how code executes, not just what it does. This helps differentiate between legitimate tracking scripts and malicious behavior with similar technical patterns.
Monitor marketing, analytics, and payment scripts without breaking checkout flows.
Protect user data while maintaining performance for global applications.
Ensure third-party integrations don't compromise sensitive payment data.
Maintain HIPAA compliance while using essential third-party services.
While both use proxy technology, cside's hybrid proxy is purpose-built for JavaScript security.
| Feature | cside Hybrid Proxy | Web Application Firewall (WAF) |
|---|---|---|
| What it proxies | Only specific third-party JavaScript files | All HTTPS traffic to your entire website |
| Impact on main site | Zero impact - your main site traffic is untouched | Sits between users and your entire website |
| Configuration complexity | Simple - just add NPM package or script tag | Complex - requires managing rules for all traffic, SSL certificates, content types |
| Failure mode | Fail-open: scripts fetch from original sources | Entire website becomes unreachable |
| Latency added | 8-20ms only for proxied dynamicscripts (static scripts cached and faster) | Adds latency to every single request |
| Security focus | Client-side JavaScript threats and behavior | Server-side inbound request protection |
| Works alongside existing security | Yes - complements WAF and other tools | N/A - handles different layer |
"You do not have control over third-party scripts today, that's why I started cside!"
FAQ
Frequently Asked Questions
Think of it this way: a WAF sits between your users and your entire website, proxying all HTTPS traffic. cside's hybrid proxy is much more targeted and only proxies the JavaScript files from third-party sources, leaving your main website traffic completely untouched. Your users connect directly to your website as normal, but when their browser requests a third-party script, that single request gets routed through our proxy for analysis before delivery.
Yes, that's why we call it a hybrid proxy. We designed cside as a hybrid proxy, meaning you have granular control over which scripts get proxied and which don't. Critical scripts like Stripe, PayPal, Google Pay, or Intercom can be set to bypass our proxy entirely with capture-only mode, while newer or less trusted scripts get the full proxy treatment. This flexibility means you can allow the scripts you trust and proxy the scripts you're most concerned about or have not seen before, and expand coverage as you become more comfortable.
No, your website will continue working normally as we only intercept third-party scripts, which are usually not render-blocking, and we will not stop scripts from being served during an incident. cside has a fail-open design with a 99.99% uptime SLA, but if there's ever an issue, JavaScript requests automatically fall back to fetching directly from their original sources. This is completely different from a WAF failure, where your entire site becomes unreachable. We've designed the cside platform to enhance security without creating single points of failure for your website's core functionality.
Your website will continue working as intended. cside has a fail-open design with a 99.99% uptime SLA, but if there's ever an issue, JavaScript requests automatically fall back to fetching directly from their original sources. This is completely different from a WAF failure, where your entire site becomes unreachable. We've designed the cside platform to enhance security without creating single points of failure for your website's core functionality. We knew from the start that this was an important requirement.
cside is much simpler because we're only handling JavaScript files, not your entire web infrastructure. With a WAF, you need to configure rules for all your traffic, manage SSL certificates, handle different content types, and worry about breaking legitimate requests. A WAF also has no overlap with cside, as a WAF monitors inbound requests, not client-side activity or server responses to the client-side. While some WAF vendors inject Content Security Policies, we built cside from the ground up to address client-side security by design and not as an afterthought. With cside, you just add our NPM package or one script tag to your pages and configure which third-party scripts you want us to analyze. There's no need to restructure your entire web architecture or manage complex proxy rules.
cside only adds 8-20 milliseconds (the blink of an eye typically lasts between 100 and 400 milliseconds) of latency to the specific, highly dynamic JavaScript files we proxy. Static scripts are cached at our edge and therefore load faster than the original source, improving the speed of your website. This is completely different from a WAF that adds latency to every single request to your website. Users won't notice any difference.
Because client-side security monitors an entirely different dimension of the application stack, there is no interference. Our platform co-exists with your existing security solutions. Your WAF continues to protect your main website inbound traffic while cside focuses specifically on client-side JavaScript security. cside operates at a different dimension; your WAF handles incoming requests to your servers, while cside handles outgoing requests from browsers to third-party script sources. There's no conflict or overlap in functionality.
Application security (AppSec) is a broad category that includes everything from secure coding practices to server-side vulnerability scanning and many subjects in between. Client-side security is a critical subset of AppSec that focuses specifically on protecting applications and their dependencies where they actually execute--in users' browsers. AppSec is protecting your entire application ecosystem, while client-side security protects the most critical layer--where your app meets your users. In today's JavaScript-heavy internet, most application logic actually runs client-side, making this the most important component of modern AppSec. Web Application Firewalls and most other AppSec tools do not monitor client-side activities at all, focusing on server-side code while ignoring the browser environment where most user interactions and data processing actually occur. AppSec covers where customers interact or input sensitive information, as well as where this information is stored and processed.
Server-side security protects your infrastructure with tools like firewalls, a WAF protecting the perimeter against malicious inbound requests, and vulnerability scanners, building a wall around your critical infrastructure. Client-side security protects where your applications actually execute: in your users' browsers. Think of it this way - server-side security protects your kitchen, but client-side security protects the meal after it's served to your customers. You need both layers because attackers increasingly target the client-side, where they can steal data directly from users without touching your servers.
Traditional security tools like firewalls, WAFs, and vulnerability scanners are designed to protect your server infrastructure, but they can't see what's actually executing in your users' browsers. They monitor sanitized data, often slow down your site, or completely miss dynamic threats that change based on user location, device, or timing. Content Security Policies (CSPs) and JavaScript agents either see cleaned-up data or get bypassed by sophisticated attacks using techniques like CSP evasion, shadow-DOM tricks, and obfuscated code.
Client-side security protects your web applications where they actually run--in your users' browsers. While traditional security tools monitor your servers, they miss the real attack surface where all your applications execute. Your website loads hundreds of third-party scripts for analytics, marketing tools, payment processors, and support widgets. If just one of these gets compromised, attackers can steal credit cards, session tokens, or personal data without you or your users knowing. Client-side security gives you visibility and protection where your apps actually operate.
A typical point of entry is when a malicious actor compromises a third-party service your website uses. Here's the process: your server sends the web page, and your browser requests hundreds of external resources like analytics scripts, marketing tools, and payment processors. Then, an attacker can intercept just one of these requests and inject malicious code instead of the legitimate script. Malicious scripts can also be injected through adverts or Cross-Site Scripting attacks. These scripts can steal credit card information and take sensitive tokens like session tokens. Additionally, it can send users to fake websites, all while appearing completely normal to both users and traditional security tools.