TL;DR: cside vs Source Defense
- Source Defense targets enterprise merchants with client-side script security through behavioral controls and isolation. Credible product, but no public pricing and no free tier.
- cside runs in 100% of real user sessions with no sampling, downloads every script to its own infrastructure for server-side analysis, and preserves raw attack payloads as QSA-grade evidence. Transparent pricing, free tier.
- Large enterprise already running an RFP: put cside on the shortlist. Want to prove it on a free tier before signing anything, at a fraction of the enterprise spend: cside.
What is Source DefenseSource Defense specializes in client-side website security. They were founded in 2014 and, in their own words, built Source Defense with simplicity in mind.
How Source Defense Page Protect works
Source defense offers 2 methods:
“Source Defense Detect” - Crawler basedSource Defense Detect is a crawler that mimics a user visiting the same page, fetching the 3rd-party scripts that load.** **Crawlers can simulate user sessions, but they’re not actual users. And that difference matters, because they don’t capture the precise payload a real visitor receives during their browser session.
Most 3rd-party scripts use logic that adapts the response based on context. Location, device, time, and more. Crawlers are only one specific combination of this, so are unable to capture this correctly. They have some capabilities of mimicking different types of users, but not to the furthest degree.
Additionally, attackers can reasonably easily spot these crawlers and simply serve the non-altered script. The simple logic being: “if the request comes from a cloud provider, serve a clean script.”
Vendors that rely solely on crawlers typically need to buy extra intelligence from 3rd-parties. At cside, we also offer a crawler for situations where our script-based monitoring is not possible (niche cases), but with a major advantage: it's powered by threat data we continuously gather from every site using our on-site monitoring.
This doesn’t guarantee prevention, but it dramatically increases the chances of catching real-world threats compared to a crawler that depends on outside feeds.
Additionally, A crawler on its own cannot make you PCI DSS 4.0.1 (requirements 6.4.3 and 11.6.1) compliant. Read more on that here. We provide a combination with our other solutions where we can help you achieve PCI DSS compliance.
“Source Defense Protect” - JS Agent basedSource Defense also offers a JavaScript agent. Agent based approaches can make for a helpful dashboard with interesting information about scripts but they are not unbreakable and have a few issues by design.
JS agents are trigger based. Anything that doesn’t trigger, is considered good. This has the dangerous effect of “they do not know what they didn’t catch”.
These triggers are defined in the browser, where a bad actor can easily find out what behavior they are tracking. A bit like playing minesweeper but the bombs are exposed.
Source Defense uses their script to create a client-side sandbox, but the problem with that approach is up-to 100ms latency.
Another issue is that agent scripts rely on the same browser environment as the attacker. If a malicious script is already running, it can override core functions like the fetch). When the JS agent tries to send an alert, the attacker can intercept or redirect that request.
From the outside, it looks like everything’s working. But the alert never reaches its destination. The detection was triggered, but the signal was cut off before it left the browser.
This bypass method can be prevented and connections can be protected, but we haven’t seen any client-side security solution that is agent based adopt it.
We detailed that concept here.
Agents can show interesting information but any bad actor can work their way around them. There is also the common perception that they can make sites slower. This can be true but depends on how the script functions. We have decided not to rely on purely on the agent method as attempting to perform detections at the same rank as the bad actor performing threats does not work reliably.
Most importantly: Source Defense can not show you the script contents, which makes it hard for forensics and or have the ability to improve detections.
How cside goes further
Source Defense takes a sandboxing approach, isolating third-party scripts to limit what they can access on the page. The idea is sound, but sandboxing alone has limits. Attackers who find a way around the sandbox constraints still have access to the user's session. cside analyzes scripts before they reach the browser, so malicious code is blocked entirely.
Source Defense's per-script permission model requires ongoing configuration as your site evolves. New scripts, updated dependencies, and changing third-party integrations all need policy updates. With cside, protection is automatic. Our engine learns what scripts are supposed to do and flags deviations. No manual rule writing.
For forensics, Source Defense provides behavioral alerts when sandbox boundaries are crossed. cside captures the actual malicious payload: the full script code that triggered the detection, preserved in an immutable archive. When your incident response team needs to understand how an attack worked, or when a QSA auditor asks for evidence, you have the source code.
cside also publishes a public status page at status.cside.com, a public trust portal at trust.cside.com, and a 99.9% uptime SLA, so you can verify our reliability and incident history for yourself. Source Defense maintains a public changelog but no status page or uptime SLA.
cside offers two deployment options:
- Script Method: Add one script to your site. We monitor behaviors client-side and analyze scripts server-side. Takes seconds to deploy.
- Scan Method: If you can't add a script, cside scans your site using threat intelligence gathered from thousands of websites with billions of combined visitors.
cside actively contributes to the W3C to improve browser-native security specifications, and integrates natively with Linear and Jira so security findings flow directly into your development workflows.
Sign up or book a demo to get started.
Related resources
Founder and CEO of cside. Previously a product manager on Cloudflare Page Shield (now Cloudflare Client-Side Security). Co-chair of the W3C Anti-Fraud Community Group and a Forbes 30 Under 30 honoree. Building accessible security against client-side attacks, web security is not an enterprise-only problem.
