TL;DR:
Reflectiz published a comparison webpage claim that cside is ineffective.
None of those claims stand up to technical scrutiny.
- Reflectiz is a scanner/crawler solution. They call this 'agentless' which in the age of agentic browser is a confusing term. They periodically scan your site from cloud IPs. This method is ineffective against most client-side threats. Attackers simply serve clean scripts to security scanners and attack the rest. Scanners see what attackers allow them to see because attackers see the scanner. Cside sees what attackers actually sends to your users, because cside runs in the application.
- Don't trust us, this is a basic design fact. Independent research by ISACA, Security Researchers at Google and Oracle but also academic research by Bournemouth University concludes consistently that scanners are unable to keep pace with modern dynamic client-side threats.
- cside does not access customer data. Seeing what fields a script attempts to access does not mean the content entered in those fields itself is exposed to cside.
- To implement cside you paste 1 script into your code. Where Reflectiz needs to bypass bot detection needs user credentials and will regularly break when checkout flows or product inventory changes.
- cside does not impact your marketing stats because cside never interacts with data exfiltration. A scan acting like a user does impact analytics, as it attempts to act like a user.
- cside is not a proxy only solution. We have a direct mode, Gatekeeper and also a scanner for sites where code changes are not possible.
- cside performs deep dynamic and behavioral analysis that scanner tools cannot match.
This post breaks down some of the allegations and explains why the claims are inaccurate.
Introduction
Web security is facing new challenges. Supply-chain attacks are constantly in the new and an important part of the supply-chain are dependencies that execute in the browser of the user where you have no visibility. Those attacks have progressed significantly in recent years. As the threat landscape has evolved easily to bypass approaches become irrelevant.
Leading to a predictable outcome: attackers don't serve attacks to security scanners.
Recently, Reflectiz published comparisons asserting that cside is somehow less powerful than their scanner. These claims do not reflect basic technological facts. They present an incorrect understanding of client-side security as a discipline and how cside works.
As an important part of context: cside holds a SOC2 type 2 attestation and PCI SAQ-D. Reflectiz does neither, there is no 3rd party validated evidence their company operates in a secure manner.
Accuracy matters especially in the context of security. When an opportunistic security solution endangers users, we're all worse off.
Reflectiz’s Inaccurate Claims About cside
False claim: cside collects sensitive customer data
Reflectiz suggests that cside is collecting sensitive user data like passwords and credit card information. In reality cside is monitoring script behavior and doesn't have any access to user inputs. The concept of seeing data or seeing which scripts attempt to access which input fields or APIs is an entirely different dimension.
- Cside does not monitor user entered data. We do not have visibility into what a user types.
- Cside monitors the events of a script.
This may sound repetitive but:
We don't interact with the data a user submits through a form on a website. Cside monitors what scripts attempt to access.
Our solutions monitors the browser APIs a script attempts to use, what form fields it is looking for and where data is being sent to.
All of this occurs without touching user inputs.
Even the Gatekeeper solution acts as ‘pure conduit’ meaning we are a passthrough provider of the script contents from the 3rd party server to the user. We might be part of the URL the script is coming from but not the exfil flow. Where the data is sent is purely monitored as an endpoint.
There is a fundamental separation between script actions and user actions in a browser, especially when it comes to entering data. They are literally different dimensions. This is an essential design choice to help with customer privacy and regulatory compliance.
Keep in mind, cside has a SOC2 type 2 attestation and PCI SAQ-D. Reflectiz has neither. The intent of a vendor without any 3rd party security verification making claims about others data collection practices is at best questionable.
False claim: it takes weeks to deploy cside
Most customers deploy cside in minutes by adding a single script to their site. Nothing else is required. Cside supports additional configuration such as selective Gatekeeping of untrusted scripts or scripts that operate in extra sensitive areas. These options are provided for flexibility not because the platform demands it.
There is no DNS or SSL configuration and no infrastructure migration.
The suggestion that cside requires long integration cycles has no basis in how the product is used in practice.
On the flip side Reflectiz'es scanner needs to implement logic to bypass captchas. Sometimes will even require you to allowlist their IPs on your bot detection solution and will require user-credentials to access the payment pages. On top of that websites change. During sale season the flow will look different from a normal day to day shopping experience. These changes can break their scans. While not needing to add a script may sound easier, that is not the full picture. Often maintaining what is required to scan the page reliably over time requires significant and continued effort.
False Claim: cside is a proxy only solution
Reflectiz frames cside as purely a proxy architecture. Implying limited design flexibility and potential performance or reliability issues.
The cside ‘gatekeeper mode’ is optional. It is one of several mechanisms available to organizations that want additional control over the scripts loaded into their environment. Many customers do not use the Gatekeeping service at all. Instead they rely on runtime behavior monitoring.
Labeling cside as “a proxy solution” ignores most of the platform.
False claim: cside can cause downtime or disrupt analytics
Cside uses a fail-open design. If the cside service ever becomes unavailable, the customer’s site loads normally. There is no blocking of script execution and no impact on page functionality. If cside goes down, the script that would make traffic flow to or through cside would not serve. This is a basic dead-man switch architecture. Low tech but highly efficient in failure scenarios.
We wrote an entire blogpost about this here.
Analytics systems are unaffected because cside does not interact with the data that is sent to them. Monitoring script behavior is not the same as intercepting or modifying data streams.
The suggestion that analytics would be disrupted reflects a misunderstanding of cside’s architecture.
Something that ofcourse does affect analytics data is a scanner that attempts to behave somewhat like a user. You will see those requests come in, they will fill up a cart to get to the payment page. And then the payment is abandoned which will skew your metrics. This is one of the issues you will face when using a scanner based solution.
False claim: Reflectiz detects more scripts than cside
Reflectiz claims that it detects 20 to 50 percent more scripts than cside. No methodology, sources or documentation accompanies this assertion.
They also claim that cside doesn't have visibility into iframes which is incorrect. We collect iframe URLs and review the contents inside the iframe session using an async check. On top of that, malicious iframes are usually injected through parent script tags. The focus on iframes isn't as relevant in the real world as the iframe object in an attack is rarely natively present. Its usually a subrequest of a scripts.
More importantly, script detections in a cloud environment is not equal to effective protection in real-world traffic. Scanners inherently miss the exact types of threats that modern attackers use:
- User-agent targeted attacks
- Attacks that target web-views only
- Conditional injections
- Geo-targeted attacks
- Time-windowed attacks
Cside monitors script behavior in the browser using real time action analysis. If a malicious payload appears only for users in a certain region or only for users who cside will see it. A scanner will not.
The scripts you have to worry about are not going to fall for a scanner.
There is an undeniable architectural gap between the core problem and how a scanner works. It is not a matter of comparing “number of scripts detected”. It is a matter of whether a tool by design can observe the conditions in which attacks actually occurs.
Why These Misrepresentations Matter
When vendors make inaccurate claims about how competitor tools function, they mislead organizations that rely on accurate information to protect their users.
Reflectiz decided on the path of least effort for the customer which certainly appeals to some. This approach has pro's and con's. They chose the approach of least effort but that approach on the flipside is easy to bypass.
The problem is that they claim to be most accurate and that is objectively false.
Security decisions must be informed by architecture, not by incorrect marketing statements.
Scanner Tools Do Not Catch Modern Client-side Threats
A crawler periodically snapshots a site and attempts to classify scripts by their URL or known signatures.
Attackers today:
- Inject payloads only at specific user actions
- Serve different code to different geographic regions
- Modify behavior dynamically after fingerprinting the user
- Split malicious logic across multiple scripts
- Trigger payloads only under checkout or payment conditions where a user is authenticated, avoiding credentials used in automation scenarios.
These behaviors are invisible to scanners. To dig deeper check out our article on how to bypass scanner tools.
Independent research by ISACA, Security Researchers at Google and Oracle but also academic research by Bournemouth University consistently concludes that scanner-based client-side security cannot keep pace with modern, dynamic browser-side threats.
Cside was designed with these realities in mind. The significant extra effort we take to build a runtime behavior platform isn't for nothing, it's because we saw scanners fail time and time again. We observe what scripts actually do when executed on real pages by real users because we know that is the only way to actually detect a live attack.
This is the only defensible approach to client-side security at modern scale.
Conclusion
The claims made by Reflectiz are very obviously AI generated with little concern for accuracy or legitimacy.
Reflectiz chose to build a solution they could implement for their customers.
Making it simpler for people to adopt. Building a scanner is a lot cheaper and easier than building a runtime service. These are legitimate design choices. The problem is that they claim their solution, which is designed to be easy, is more accurate. And that is simply not true. The technology choice of a scanner is a point in time check. For a static issue, that may be OK. But client-side security is a dynamic issue.
Its important that accurate information is shared, even in competitor reviews. It also depends on acknowledging that attackers adapt quickly and rely on the blind spots created by outdated tooling. cside is designed to eliminate those blind spots through real-time visibility that aligns with how modern attacks operate.
Choosing Between cside and Reflectiz
We would rather not have to write this article but the misleading information Reflectiz posted about us was too outrageous to ignore. We have a more detailed post about the comparison between our solutions which you can find here: cside vs Reflectiz
Over time I think every professional finds itself with a competitors that rather invests their time and energy in spreading misinformation and aggressive tactics to discredit others instead of improving their own product. This is one of those situations.
