This article takes an honest look at the features of DomDog.
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 page.
DomDog is a tool specifically designed to solve PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1. Keep in mind that on January 30th 2025 the companies needing to comply with both requirements received an update.
SAQ A companies do now no longer need to comply, providing:
their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).
Find the full PCI DSS update stating this.
Criteria | cside | Domdog | Why It Matters | What the Consequences Are |
---|---|---|---|---|
Approaches used | Proxy | 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 DomDog?
DomDog’s founders have a long history and track record in client-side security. All information regarding their product, and their pricing, is fully visible and very easy to find. This is rare with products in our space. Pricing starts at $999 per year, similar to cside.
How DomDog works
DomDog is tailor made for PCI DSS requirements 6.4.3 and 11.6.1 focusing on client-side security. Their set up process requires just a single script to be added to the header tag of your website. This is similar to cside, though the functionality of both scripts very a lot.
It seems like they are collecting data, showing the scripts in a dashboard and asking the user to review it. While okay for PCI, it’s not the best approach from a security standpoint.
Say a stored XSS script turns malicious, they won’t be able to detect it since they don’t sit in the flow of the delivery. This approach is often called a JavaScript “Agent”. JavaScript Agents operate within the JavaScript layer and can not monitor code outside of it. It scans for which data various scripts are collecting and allows the user to black- or whitelist certain scripts on certain websites or pages.
They do use a secondary approach, being a Content Security Policy (CSP). A CSP acts like a firewall which only trusts pre-approved script sources, not their content. Should the source stay the same but the content changes, like in the biggest client-side attack of 2024 – Polyfill – a CSP won’t catch it.
We wrote an in depth article on Why CSP Doesn’t Work in regards to providing the best client-side security solution:
CSP operates on an allow-list model, which permits resources from trusted domains but cannot block individual scripts or resources from those domains.
We could not find a SOC2 or PCI DSS certification.
How cside goes further
cside primarily offers a hybrid proxy approach which sits in between the user session and the 3rd party service. It analyzes the served dependencies code in real-time before serving it to the user.
This allows us to not only spot advanced highly targeted attacks and alert on them, cside also makes it possible to block attacks before they touch the user's browser. It also checks the box for multiple compliance frameworks, including PCI DSS 4.0.1. We even provide deep forensics, including if an attacker bypasses our detections. Allowing you to more tightly scope the size of the incident us to make our detection capabilities better every day. No other vendor has this capability.
We believe this is the most secure way to monitor and protect your dependencies across your entire website. We've spent years in the client-side security space before we started cside, we've seen it all, this is the only way you can actually spot an attack.
Sign up or book a demo to get started.
FAQ
Q: How does cside's hybrid proxy differ from Domdog's JavaScript-based detection?
A: The fundamental difference is prevention versus detection timing. Domdog uses JavaScript-based detection that runs after scripts have already loaded in browsers, relying on behavioral analysis to catch threats post-execution. cside's hybrid proxy intercepts and analyzes scripts before they reach browsers, blocking malicious payloads proactively at the network level. We prevent attacks from happening, while Domdog detects them after they've already been delivered.
Q: Can attackers bypass cside's protection like they can with Domdog's browser-based monitoring?
A: No, because cside's core analysis happens on our proxy, completely invisible to attackers. Domdog's JavaScript monitoring runs in browsers where sophisticated attackers can detect, analyze, and potentially circumvent the detection mechanisms. Since cside's proxy analysis happens server-side before content reaches browsers, attackers have no visibility into our security mechanisms and cannot study or bypass our protection methods.
Q: What forensic evidence does cside provide compared to Domdog's behavioral analysis?
A: Domdog provides behavioral monitoring data when suspicious activity is detected, but cside captures and preserves the exact malicious code that was blocked. This gives you complete forensic evidence showing precisely what the attack looked like and what data it was designed to steal. Incident response teams get the actual attack code for analysis rather than just behavioral observations that may not capture the full threat.
Q: How do compliance and regulatory capabilities compare between the two approaches?
A: cside provides comprehensive PCI DSS compliance with immutable payload archives and detailed audit trails covering both requirements 6.4.3 and 11.6.1. Domdog's behavioral monitoring provides detection logs but lacks the forensic-grade evidence and historical tracking that regulators increasingly require. Our approach creates the complete documentation that compliance officers need for thorough regulatory reporting.
Q: Why is cside's proactive blocking better than Domdog's reactive detection?
A: Proactive blocking prevents attacks before any user data can be compromised, while reactive detection only alerts you after malicious scripts have already executed and potentially stolen information. Domdog's behavioral analysis means sensitive data can be exfiltrated before their monitoring system triggers an alert. cside ensures malicious scripts never reach browsers, providing guaranteed protection rather than post-execution detection.