This article takes an honest look at the features of Report DataDome.
Since you’re on the cside website, we acknowledge our bias. That said, we’ve built our case honestly and based our analysis on publicly available information, industry information, and our own or our customers' experiences.
If you want to verify their claims yourself, please navigate to their product pages.
| Criteria | c/side | Source Defense | Why It Matters | What the Consequences Are |
|---|---|---|---|---|
| Approaches used | Proxy + agent based detections but also offers crawler and offers a free CSP reporting endpoint | Crawler + JS-Based Detection | ||
| Real-time Protection | Attacks can occur between scans or in the excluded data when sampled | Delayed detection = active data breaches | ||
| Full Payload Analysis | Ensures deep visibility into malicious behaviors within script code itself | Threats go unnoticed unless the source is known on a threat feed | ||
| Dynamic Threat Detection | Identifies attacks that change based on user, time, or location | Missed detection of targeted attacks | ||
| DOM-Level Threat Detection | Tracks changes to the DOM and observes how scripts behave during runtime | Unable to identify sophisticated DOM-based attacks | ||
| 100% Historical Tracking & Forensics | Needed for incident response, auditing, and compliance | Needed for incident response, auditing, and compliance | ||
| Bypass Protection | Stops attackers from circumventing controls via DOM obfuscation or evasion | Stealthy threats continue undetected | ||
| Certainty the Script Seen by User is Monitored | Aligns analysis with what actually executes in the browser | Gaps between what’s reviewed and what’s actually executed | ||
| AI-driven Script Analysis | Detects novel or evolving threats through behavior modeling | Reliance on manual updates, threat feeds or rules = slow and error-prone detection | ||
| QSA validated PCI dash | The most reliable way to ensure a solution is PCI compliant is to conduct a thorough audit by an independent QSA | Without QSA validation, you rely entirely on marketing claims, which could result in failing an audit | ||
| SOC 2 Type II | Shows consistent operational security controls over time | Lacks verified security control validation, making it a risky vendor | ||
| PCI specific UI | An easy interface for quick script review and justification via one click or AI automation | Mundane tasks and manual research on what all the scripts do, which takes hours or days |
What is Source Defense
Source 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 based
Source 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 proxy is not possible (niche cases), but with a major advantage: it’s powered by threat data we continuously gather from every site using our own proxy.
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 based
Source 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
The cside team has substantial experience in client-side security. Throughout our experiences we identified that bad actors are operating at a level of sophistication that takes the upper hand over some security approaches. If the reward is high, any gap in a security detection model is an opportunity for a bad actor.
Given browsers specification limitations for client-side security, we’ve had to get creative which is why we approached client-side security with the ability to intercept scripts through a hybrid proxy.
- Direct Mode - Easiest: We check script behaviors in the browser and fetch the scripts on our side. We then verify we got the same script. We don't place ourselves in the path of a script unless you explicitly ask us to. Just one script to add to the site, it takes seconds.
- Gatekeeper Mode - Safest: We check script behaviors and cside places itself in the middle between the uncontrolled third-party and the end user - only script you didn't already trust. Just one script to add to the site, it takes seconds.
- Scan mode - Fastest: If you can't add a script to the site, cside will scan it. We will use the cside threat intel gathered by thousands of other websites with combined billions of visitors to help secure your site the best you can.
The mix of the above brings us closest to full coverage technically possible today.
As a nice side piece, with some of the approaches we have taken we were able to make websites faster depending on the scripts on the webpage. Placing a solution in the middle only makes things slower if they are already fully optimized, which is often not the case.
With this cside helps companies achieve compliance, whether its security or privacy focussed.
Cside actively contributes to the W3C in the hopes of creating attention to client-side security. Aiming to make adjustments to the browser specification to allow for fully bulletproof client-side security.
At cside, we capture attacks. If you are reading this blogpost, you are likely a sufficiently high value target for a bad actor to invest some level of mental capacity to inspect how your web security works. It is better to be safe and assume a bad actor will attempt to bypass security solutions you use. So use solutions that think a step ahead.
Sign up or book a demo to get started.
