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, Gatekeeper is purpose-built for JavaScript security.
| Feature | cside Gatekeeper | 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 |
FAQ
Frequently Asked Questions
A WAF sits between your users and your web infrastructure proxying all traffic to your web infrastructure. The Gatekeeper is much more targeted and only interacts with the JavaScript files from third-party sources which you ordinarily have no control over. Leaving your main website traffic completely untouched. Your users connect directly to your website but when their browser requests a script an untrusted third party source, that single request gets routed through cside for analysis before delivery. This approach is necessary to avoid browser level limitations.
We designed Gatekeeper as a hybrid solution. You have control over which scripts flow through the Gatekeeper engine and which don't. Critical scripts like Stripe, PayPal, Google Pay, or Intercom are already set to serve in direct mode. We still check their behaviors client-side and through our async analysis but cside does not live in the middle here. But you can select the script you trust and anything else gets the full security treatment. This flexibility means you can allow the scripts you trust and flow the scripts you're most concerned about or have not seen before and expand coverage as you become more comfortable. This is necessary as browser side detection are limited. The browser was not built for client-side security so the Gatekeeper covers that gap.
Your website will continue working normally. In Gatekeeper mode we only pass the third party scripts through the engine. Those are mostly not render blocking so there is no notable difference. Even if an incident occured with cside we will not stop scripts from being served. Our products operate on a fail-open model with a 99.99% uptime SLA. If the Gatekeeper service goes down, the cside script making the pass through happen also stops serving. This is a classic dead-man switch model. This is completely different from a WAF failure where your entire site becomes unreachable when the vendor goes down. When we designed our product we made sure to include downtime events as a possibility, so we made sure that by design we're not going to break a webpage.
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.