TL;DR:
Reflectiz published a comparison webpage implying that cside is unsafe, complicated, or ineffective.
None of those claims stand up to technical scrutiny.
- Reflectiz is a scanner-based, agent-less solution. It periodically crawls your site from cloud IPs. This method is ineffective against many easy circumvention techniques. Scanners see what attackers allow them to see; cside sees what attackers actually send to your users.
- 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 does not access customer data
- cside deploys in minutes
- cside is not a proxy-only solution
- cside performs deep static, dynamic, and behavioral analysis that scanner-only tools cannot match
- Reflectiz’s statements rely on misunderstandings of how modern client-side security must operate to meet current attack patterns and PCI DSS 4.0.1 requirements
This post breaks down each allegation and explains why the claims are inaccurate or misleading.
Introduction
Client-side attacks have advanced significantly in recent years. As the threat landscape and regulatory requirements have evolved, legacy approaches such as crawler-based scanning have failed to keep pace. The result is predictable: attackers take advantage of where scanners cannot see. These gaps are exactly why cside was created.
Recently, Reflectiz published comparisons asserting that cside is either unsafe, overly complex, or architecturally limited. These claims do not reflect how cside works, and in several cases present an incorrect understanding of client-side security as a discipline. This is particularly surprising because cside holds a SOC2 type 2 attestation and PCI SAQ-D where Reflectiz does neither and as such there is no 3rd party validated evidence their company operates in a secure manner.
Because accuracy matters in security, and because organizations make operational decisions based on available information, we are addressing each claim directly and explaining the architecture involved.
Reflectiz’s Inaccurate Claims About cside
False claim: cside accesses customer data
Reflectiz suggests that cside, by monitoring script behavior, accesses passwords, payment data, or other sensitive user inputs.
This is incorrect.
- cside does not monitor user-entered data.
- cside does not have visibility into what users type.
- cside does not store, transmit, or process passwords, credit card numbers, or personal information.
The platform evaluates the scripts themselves, not the content users submit through a website. cside monitors what scripts attempt to access, what APIs they use, what external endpoints they call, and whether their behavior changes between versions or across different execution contexts. All of this occurs without touching user inputs.
Cside’s gatekeeper solution acts as ‘pure conduit’ meaning we are a passthrough provider of the script service itself.
This is a fundamental architectural principle. We enforce strict separation between script-level observation and data-level content, which is a baseline requirement for customer privacy and regulatory compliance.
False claim: cside takes weeks to deploy
Reflectiz describes cside as a heavy, complex solution that requires weeks of setup or extensive engineering involvement.
This is not accurate.
Most customers deploy cside in minutes by adding a single script to their site. Nothing else is required in the vast majority of cases. For more advanced environments, cside supports additional modes, such as selective proxying of untrusted third-party scripts or a fallback scanning mode for environments where code cannot be modified. These options are provided for flexibility, not because the platform demands complexity.
- There is no DNS configuration.
- There is no SSL configuration.
- There is no infrastructure migration.
Customers regularly move from initial evaluation to production deployment within the same day. The suggestion that cside requires long integration cycles has no basis in how the product is used in practice.
False Claim: cside is a proxy-centric solution
Reflectiz frames cside as a proxy-centric architecture, implying limited design flexibility and potential performance or reliability issues.
This is incorrect and incomplete.
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 proxying at all. Instead, they rely on runtime behavior monitoring, static analysis, script inventorying, version tracking, and real-time alerts. These capabilities do not require proxying.
Labeling cside as “a proxy solution” ignores most of the platform.
False claim: cside can cause downtime or disrupt analytics
Reflectiz raises concerns that using cside could create operational risks or interfere with analytics platforms.
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.
Analytics systems are unaffected because cside does not alter payloads, does not rewrite event data, and does not interfere with instrumentation logic. 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.
False claim: Reflectiz detects more scripts than cside
Reflectiz claims that it detects 20 to 50 percent more scripts than cside. No methodology, dataset, repeatable test results, or documentation accompanies this assertion.
More importantly, script detection in a laboratory environment is not equal to effective protection in real-world traffic. Scanner-based approaches inherently miss the exact types of threats that modern attackers use:
- Conditional injections
- Geo-targeted payloads
- Time-windowed attacks
- User-agent-specific behavior
- Checkout-only malware
- Scripts that appear only to human users
A crawler sees the same environment every time. Attackers exploit that predictability.
cside does not rely on a crawler. cside monitors script behavior in real time across real user traffic. If a malicious payload appears only for users in a certain region, or only for users who have reached a certain point in the checkout funnel, cside will see it. A scanner will not.
This architectural gap is the core problem with scanner-only solutions. It is not a matter of comparing “number of scripts detected.” It is a matter of whether a tool can observe the conditions in which attacks actually occur.
Why These Misrepresentations Matter
The issue is not whether one vendor outperforms another in a controlled environment. The issue is that real attacks do not behave like controlled environments. They are conditional, dynamic, user-specific, context-specific, and often designed to hide from scanners.
When vendors make inaccurate claims about how competitor tools function, they mislead organizations that rely on accurate information to protect their users. This increases risk.
Security decisions must be informed by architecture, not by selectively framed 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. This approach worked reasonably well a decade ago. It is no longer sufficient.
Attackers today:
- Inject payloads only at specific user actions
- Serve different code to different geographic regions
- Modify behavior dynamically after fingerprinting the user
- Use short-lived endpoints
- Split malicious logic across multiple scripts
- Trigger payloads only under checkout or payment conditions
- These behaviors are invisible to scanners.
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. Our emphasis on runtime behavior, correlated script activity, and version-level tracking ensures visibility into the precise execution context where threats occur. We do not attempt to force modern attacks into outdated scanning models. We observe what scripts actually do when executed on real pages by real users.
This is the only defensible approach to client-side security at modern scale.
Conclusion
cside exists because the architecture of client-side attacks has changed, and traditional scanning approaches cannot keep up with how those attacks manifest today. The claims made by Reflectiz misrepresent the design, capabilities, and operational behavior of the cside platform.
Effective security depends on accurate information. 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, behavior-focused visibility that aligns with how modern attacks operate.
Choosing Between cside and Reflectiz
This article was written to clarify several inaccurate statements that Reflectiz has been promoting about how cside works. If you are evaluating solutions and would prefer a structured, side-by-side comparison including feature differences, protection capabilities, and why security and compliance teams adopt cside over scanner-based platforms you can read our full comparison guide: cside vs Reflectiz
