TL;DR: cside vs Reflectiz
- cside uses Script Method for real-user browser visibility and also offers scanner-based Scan Method when code changes are not possible.
- Reflectiz is primarily a periodic remote scanner. Scanner-only coverage can miss attacks served only to real users, regions, devices, checkout states, or short time windows.
- The point is optionality: scanning is useful coverage, but it should not be the only way a client-side security product sees the page.
- A browser running from a cloud provider IP is not the same as a script running in the actual DOM of a real user session.
- Independent research by ISACA, security researchers at Google and Oracle, and academic research from Bournemouth University supports the same basic point: scanner-only client-side security struggles with dynamic browser-side threats.
- cside does not store user-entered passwords, card numbers, form contents, or PII.
- Public review and assurance data on this page was checked on May 20, 2026.
Quick answer
Reflectiz sees what its crawler receives. cside sees script behavior in real user browsers through Script Method and also offers Scan Method as scanner-based fallback coverage.
That difference matters because client-side attacks often adapt to the visitor. A crawler from a cloud IP can receive clean JavaScript while a real shopper receives malicious code inside the actual DOM. cside's approach creates optionality: use real-user browser visibility where possible, and use scanning where a script deployment is not possible yet.
Comparison table
| Criteria | cside | Reflectiz | Why it matters | What the consequence is |
|---|---|---|---|---|
| Approach | Script Method + Scan Method | Remote scanner | cside includes scanner-based coverage, but does not depend on scanning alone. | Teams get optionality instead of being locked into scanner-only blind spots. |
| Real-user browser visibility | Full support |
No support |
cside runs in the actual DOM of real sessions. A cloud scanner sees only what the page serves to that scanner. | A crawler can receive clean code while users receive malicious code. |
| Scanner evasion resistance | Full support |
No support |
Attackers can vary scripts by IP, device, country, user agent, login state, or time. | Remote scans can create a false sense of coverage. |
| PCI DSS 4.0.1 evidence + SAQ D | Full support |
Partial support |
PCI evidence needs to satisfy assessors and remediation reviews. | Self-described reporting may still need independent validation. |
| SOC 2 Type II | Full support |
No support |
Enterprise buyers often require independent operational assurance. | Missing SOC 2 Type II can become a procurement blocker. |
| Browser-side blocking | Full support |
Partial support |
Any browser-side blocking control must run inside the application. | Reflectiz accepts the same application-interaction class of risk it criticizes. |
| Public pricing | Full support |
No support |
Public pricing makes budget planning easier. | Hidden pricing adds buying uncertainty. |
Why cloud-browser scanning is not the same as DOM visibility
A scanner is a browser running somewhere else. In practice, that usually means a headless or automated browser from cloud infrastructure, a known IP range, a predictable user agent, and a session that does not behave like a real shopper.
cside's Script Method runs inside the actual page DOM in real user sessions. That is the meaningful difference. It lets cside observe what scripts do when they execute for the user, not only what a crawler was allowed to see during a scheduled scan.
This is also why scanner-only claims become weak against modern client-side attacks. Attackers can serve clean scripts to scanner infrastructure and malicious scripts to real users based on IP, geography, device, login state, checkout state, or time window.
User reviews
| Platform | cside | Reflectiz |
|---|---|---|
| G2 | 4.8/5, 11 reviews | 29 reviews |
| SourceForge | 4.9/5, 33 reviews and ratings | 0 native SourceForge reviews. Tooltip reports 29 verified third-party ratings, matching the 29-review count on G2. |
| Gartner Peer Insights | Vendor page with 1 review | 0 reviews and 0 products listed |
Checked May 20, 2026. SourceForge's Reflectiz tooltip says 0 SourceForge reviews and 29 verified third-party ratings. That 29-count matches Reflectiz's G2 review count, so SourceForge is not a separate Reflectiz review footprint.
Sources: cside on SourceForge, Reflectiz on SourceForge, cside on G2, Reflectiz on G2, and public Gartner Peer Insights vendor pages.
Why we are responding
Reflectiz has published unusually aggressive claims about cside. We do not know why they started doing that, but the tone is clearly hostile toward a competitor.
Security buyers should separate tone from evidence. A vendor that publishes aggressive competitor claims while not publishing SOC 2 Type II, PCI DSS SAQ D, or equivalent independent assurance gives buyers a fair reason to ask harder trust questions.
Corrections to Reflectiz claims
| Reflectiz claim | Correction |
|---|---|
| cside accesses passwords, card numbers, or PII | cside analyzes public script contents and script actions. It does not store user-entered values. |
| cside is proxy-only | cside uses Script Method and Scan Method. Script Method does not require DNS or SSL changes. |
| cside does not offer scanning | cside offers Scan Method. The difference is that cside treats scanning as one option, not the entire detection model. |
| cside takes weeks to deploy | Script Method requires one script tag. Scan Method is available when code changes are not possible. |
| cside uses hidden AI prompt injections | cside's Ask AI links are visible, user-initiated URLs with readable prompt text. You can go check this out yourself on the blog. |
| cside's blocking breaks applications | Any in-browser control can affect an application, including Reflectiz's own blocking script. |
| Cross-origin iframes are a cside blind spot | Same-origin policy applies to every vendor. Third-party payment iframes are outside the merchant's PCI DSS script-management scope, and injected iframe attacks should be handled by detecting the parent script that injected them. |
| cside detects fewer scripts | Reflectiz has not published evidence for its 20-50% claim. Scanner visibility and real-user browser visibility are not equivalent. |
The dedicated rebuttal is here: Incorrect claims made by Reflectiz about cside.
Cross-origin iframes
No vendor script on a merchant page can inspect inside a third-party cross-origin iframe such as Stripe Elements, PayPal, or Adyen during a real user session. The browser's same-origin policy prevents it. Reflectiz does not get a special exemption from that browser rule.
For PCI DSS, that point is also mostly irrelevant. A third-party payment provider's iframe is the payment provider's scope, not the merchant's script-management scope. PCI DSS 6.4.3 and 11.6.1 focus on scripts on the merchant page, the parent context around the checkout experience.
If a malicious iframe appears because another script injected it, the security control belongs one level higher: detect the script that created or controlled the injection. cside monitors parent script behavior and also runs periodic scans. For customer-owned cross-origin iframes, cside can add coverage with an additional script tag.
Independent assurance
cside has been reviewed and approved by VikingCloud for PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1. cside also publishes SOC 2 Type II certification and PCI DSS SAQ D through its Trust Center.
Reflectiz did not publish equivalent QSA approval, PCI DSS SAQ D, or SOC 2 Type II certification in the public materials reviewed on May 20, 2026.
Conclusion
Reflectiz can help with inventory and periodic review. cside also offers scanning, but combines it with runtime browser-layer detection, payload forensics, PCI evidence, and enterprise assurance. That gives buyers more deployment optionality and stronger real-world coverage.
Sign up or book a demo to get started.
Founder and CEO of cside. Building better security against client-side executed attacks, and making solutions more accessible to smaller businesses. Web security is not an enterprise only problem.
