Reflectiz vs cside

TL;DR: cside vs Reflectiz:

• Reflectiz is a scanner-based, agent-less solution. It periodically crawls your site from cloud IPs.
• cside combined real-time in browser script behaviour monitoring and an optional 'gatekeeper' engine to make sure there is full visibility on the behaviour the user sees.
• Client-side script attacks are often dynamic and highly conditional (geo, User-Agent, Time-Windowed, randomized, explicitly avoiding cloud IP addresses).
• cside can detect and prevent malicious actions by scripts in real-time. Keeping full script context for forensics but does not store any user inputted data or PII.
• In short: cside sees and protects real users in real-time. Where Reflectiz makes snapshots for a compliance check-box. Reflectiz sees 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.

Why we wrote this comparison

This article explains how Reflectiz and cside approach client-side security differently and why that difference matters in practice.

We’re clearly biased - you’re on the cside website - but the comparison is based on:

• Publicly available technical information
• Documented industry attacks (such as Polyfill and Magecart-style campaigns)
• PCI DSS 4.0.1 guidance
• Our own and our customers’ real-world experiences

We invited Reflectiz to review this page and share any factual corrections. At the time of writing, they have not provided any changes.

Comparing Reflectiz to cside

In summary:

• cside provides real-time detection, blocking, script payload logging, dynamic behavior analysis and a QSA-validated PCI dashboard.
• Reflectiz relies primarily on periodic scans, which cannot see targeted, conditional attacks delivered only to real users.
• Cside can prevent or detect many types of client-side attacks that any scanner architecture, including Reflectiz, will not see by design.

User Reviews: Reflectiz vs cside

Here’s how real users rated cside and Reflectiz based on their experience with detection accuracy, support quality, and overall reliability.

You can see the user reviews for cside on Sourceforge or G2.

“I'm glad we found their product and it's helped us in meeting PCI compliance goals that previously seemed a bit overwhelming. cside's product was exactly what we were looking for at a fraction of the price that other competitors were offering.” - Anonymized Review, Sourceforge
(Quote from Sourceforge Review of cside)

Independent QSA Validation: Reflectiz vs cside

Independent QSA validation is a key indicator of whether a vendor’s security claims have been technically verified. Here’s how Reflectiz and cside compare on third-party assessments.

cside:

• Reviewed and approved by VikingCloud, one of the largest Qualified Security Assessor (QSA) firms.
• Maintains SAQ-D certification
• Recognized by compliance consultants and used by QSA partners during PCI readiness reviews.

Reflectiz:

• No publicly available QSA approval or certification listed on their site or documentation.
• Relies on self-attested claims rather than third-party validation.

What is Reflectiz?

Reflectiz is a scanner-based, agent-less tool that focuses on compliance and privacy for client-side dependencies on websites. Instead of running code in your users’ browsers, it crawls your site from external infrastructure, analyzes which scripts are loaded, and reports issues it finds.

How Reflectiz works (Scanner architecture)

Reflectiz uses what it calls a “proprietary browser” to crawl selected pages and pages discovered via the sitemap. In practice, this means:

• Requests originate from cloud or datacenter IP ranges, not from real users.
• Pages are checked periodically, not continuously and not real-time.
• It sees the scripts that are served to its crawler at that moment, not necessarily what real users see over time.

This agent-less, scanner-only design has some advantages (no code changes required) but is not easier to implement as captcha's and bot detection needs to be bypassed or the scanner needs to be allow-listed. But also login credentials and session tokens need to be used. This also creates an easy platform for detecting the scanner which a bad actor can leverage not to perform the malicious action when the security scan is performed. The concept of a website scanner for dynamic attacks introduces an inherent blind spots when scripts behave differently for different users, locations, devices, or times. Which is exactly how many modern client-side attacks operate.

While scanners are easy to build and cheap to operate, they can be used to address static security needs, but there is a fundamental design problem with this approach in the context of dynamic scripts.

Making it unlikely to detect malicious behaviors by nefarious actors.

A client-side asset is highly dynamic. Purposely providing specific contents to specific devices, locations, times of the day etc. Using a combination of HTTP headers and other external signals or randomizing responses.

Bad actors use this to their advantage. Most targeted client-side attacks will be sampled or only executed under specific circumstances, and definitely not against a cloud IP address…

There are countless examples of this: the Polyfill attack only redirected users on specific mobile devices in certain European countries, older Magecart style attacks showed a similar pattern.

A crawler can try to mimic user activity, but it isn’t user activity by definition. So it does it get the exact payload of what all users receive. There are many clues left behind that indicate a scanner is a scanner and not a human, even purposely built residential proxies are easy to detect. Bad actors that target large logo vendors will invest the effort to avoid scanners and serve benign content to those scanners. We explained in detail how bypasses are engineered on our blogpost, How to Bypass JavaScript Agents, CSP, and Crawlers.

A vendor that only offers a crawler by design would have to purchase this intelligence from another source.

Cside offers a crawler for cases where a customer can not make any changes to their code but the big difference is that we use the threat intelligence we see from all other websites that use our on site services. While this approach is still not going to eliminate an attack, it sure is a lot more capable at detecting attacks than buying threat intel on the open market.

How cside works (Real-User Monitoring + Gatekeeper + Scanner)

Cside’s client-side dependency security solutions are built on a simple principle: to protect users, you must see exactly what their browsers see. Unlike scanner-only tools that crawl a site from cloud IPs, cside analyzes script behavior inside real user sessions and verifies script integrity in real time and can optionally use our proprietary ‘gatekeeper’ infrastructure. Because most modern attacks are conditional or targeted, this real-user visibility is essential.

Our team has spent decades working in browser security and actively contributes to standards bodies such as the W3C, helping shape the future of client-side security. This background informed cside’s architecture: a system that combines real-user behavioral monitoring, an optional gatekeeper layer, and an intelligence-driven scanner. Together, these approaches provide the most complete technical coverage possible for dynamic script threats.

Why a multi-layer approach is necessary

Browsers were not designed with client-side security in mind. Browsers native functionality like CSP and SRI help but alone do not cover the entire attack surface. They freely execute third-party scripts, offer attackers many signals to differentiate humans from scanners, and provide no native mechanism for continuous integrity validation.

Because of these limitations, a single technique is never enough. Cside uses layered modes that complement each other:

• Behavioral detection inside the visitor’s browser
• Optional interception of untrusted third-party scripts before delivery
• Scanning when no code changes are possible, enhanced by real-user intelligence

This ensures cside sees what real users see, even when attacks are targeted, intermittent, or engineered to avoid crawlers.

The different modes of cside

Direct Mode - Easiest

We run a lightweight behavioral detection engine directly in the user’s browser and fetch the same scripts ourselves for verification.

• No traffic rerouting (unless you specify a script you want us to serve)
• No latency added
• Just one script tag added to your site

Direct Mode gives immediate monitoring and integrity checks, without altering your delivery path.

Gatekeeper Mode - Safest

Gatekeeper places cside between untrusted third-party scripts and your users, but only for the scripts you choose.

• We inspect and optionally block malicious script payloads in real time
• We maintain full historical payload records for forensics and compliance
• Gatekeeper often improves performance due to caching behavior and can capture untrusted scripts

This mode provides the strongest security guarantees available for dynamic script environments. Reducing the reliance on browser and using the ‘gatekeeper’ as an additional service to detect script actions.

Scan Mode - Fastest

If you cannot add the cside script, we fall back to scanning.

Unlike traditional scanners, our detection engine is powered by threat intelligence learned from billions of real user sessions across thousands of sites.

Scan Mode is not a replacement for real-user monitoring, but it provides meaningful protection when code changes are not yet possible.

Why Scanners miss real-world attacks

// Illustrative pseudo-logic; not intended for production or misuse.

const CLOUD_ASNS = new Set([
  // Common Cloud provider ASNs. Add more if needed
  16509, // AMAZON-02
  14618, // AMAZON-AES
  24940, // HETZNER
  212317, // HETZNER
  398657, // MICROSOFT AZURE DEDICATED
]);

export default {
  async fetch(request) {
    // server adds network info on the request
    const asn = request.xyz?.asn;

    const body = CLOUD_ASNS
      ? `console.log("we're good");\n`
      : `console.log("we're bad");\n`;

    return new Response(body, {
      headers: {
        "content-type": "application/javascript; charset=utf-8",
        "cache-control": "no-store",
      },
    });
  },
};

The above example can be on any type of web server including simple PaaS platforms that can be ran for free without any credit card information and/or traceability to the bad actor.

What the above script does is rather simple. When a request is made from a cloud provider, serve a clean script. Any other request gets a bad script.

Of course, the bad actor could add more logic. Like, only serve the bad script to 5% of the requests and if the developer tools are closed. Making it harder to detect by manual review.

Reflectiz may state 'but we scan from various locations and various user agents'.

Firstly, we can not verify if that is true.

Secondly, bad actors can do the reverse and target human only IP addresses, the IPv4 webspace covers 4.3 billion IP addresses. No scanner can accurately manufacture the level of entropy your users combined will naturally. Artificial behaviour is not human behaviour.

Using a residential proxy to appear like a normal residential user is unlikely to make a significant difference. A bad actor can still detect the use of a residential proxy and or look for basic indicators by timing pagetimes, checking how selectors are accessed, screensizes and combining all the factors in a comparison tree to detect mismatches between UserAgent, operating system used through checking the TCP package indicators etc. 

Independent Research Confirms Scanner Limitations

Independent research consistently shows that scanner-based client-side security cannot keep pace with modern, dynamic browser-side threats. Industry analysis from ISACA confirms that traditional scanning fails to address risks that occur exclusively at runtime in the user’s browser, while academic studies demonstrate that crawlers and black-box scanners routinely miss DOM-based vulnerabilities, dynamic execution paths, and conditional malware designed to evade automated tools (e.g., https://arxiv.org/abs/1410.4207, https://arxiv.org/abs/2004.06292).

Additional research highlights widespread false negatives due to modern anti-bot evasion tactics (https://arxiv.org/abs/2212.12308).

In contrast, independent evaluations of runtime protection including RASP-focused research (https://en.wikipedia.org/wiki/Runtime_application_self-protection) show that real-time monitoring is far more effective at detecting and blocking threats that scanners never observe.

Real-world breach analyses (British Airways, Ticketmaster, Newegg, Polyfill[.]io and others) further confirm that attackers intentionally deliver malicious scripts only to real users under specific geolocation, timing, and device conditions, ensuring scanners never see the payload.

Collectively, these sources validate that continuous, real-time browser monitoring is the only reliable way to detect modern client-side supply-chain and JavaScript-based attacks, while scanner-only tools leave inherent blind spots.

Going through a few attack methods used to avoid scanner based detections.

Geofenced attacks

What they are:
Geofenced attacks only serve a malicious script to users in specific locations or IP ranges (for example, certain mobile carrier ranges in the UK or EU) and serve a benign script to everyone else.

Why scanners miss them:

• Scanners, crawlers, and “agent-less” tools almost always run from cloud provider IPs or known proxy ranges.
• Attackers can easily maintain a list of cloud ASNs and avoid sending malicious payloads to those IPs.
• As a result, the scanner repeatedly sees the “clean” script and never observes the real attack.

Why cside detects them:

• cside observes scripts as they execute in real users’ browsers, on real residential and mobile networks.
• If a script behaves maliciously for any real user, cside can detect the behavior, and in gatekeeper mode, even block the payload before it executes.

In other words, Reflectiz sees what attackers allow their scanners to see; cside sees what attackers actually send to your users.

User-Agent Targeted Attacks

Are attacks where a malicious payload is only injected on certain browsers, for example selenium, Safari, Chromium or a specific operating system.

Most scanners, crawlers and in this case 'agent less' solutions will originate from a range of predictable User-Agent strings. They rarely emulate mobile device headers.

And in the rare cases that a scanner changes its User-Agents, the agent usually does not align with the actual request payloads. Scanners usually run on Linux based operating systems meaning a bad actor will notice based on the TCP request packet what operating system is actually being used. Resulting in the malicious payload not to be sent to the scanner as Linux is rarely used by an actual human user.

Why cside's approach works best here: we detect behaviors in the browser and our gate-keeper can act as a deterrent. If we don't see the malicious payload, your user also didn't get the malicious payload. We are constantly looking for attacks as they execute and do not sample detections.

Time-Windowed Attacks

Are attacks that only execute at specific times of the day. For example: after office hours when the security teams are not present. Scanners run periodically, so a time boxed approach can easily result in the benign script being scanned, but not the malicious script.

Why cside's approach works best here: we actually detect behaviors in the browser actively as they happen. We don't sample detections, we're there where your user is.

Cloaked or Conditional Code Execution

Are attacks that leverage user actions to inject a malicious script. The entire extent of browser APIs can be used here, for example checking for mouse m0vements, requiring a certain rhythm in keyboard input, verifying cookie existence, timing analysis (used to detect headless browsers)...

Commonly this method is used to only serve the malicious payload once, so that a security researcher wouldn't be able to find the malicious payload again. This is particularly challenging as developer tools on browsers often do not store previous states from before the developer tools were opened. Making a refresh necessary.

A scanner will never be able to emulate real user behaviour the same way a real user would.

Why cside's approach works best here: a real user naturally satisfies these requirement and we're always watching for a malicious action whether developer tools are opened or not. In theory a bad actor can look for our script presence on the webpage and serve the benign script contents, but in that case your user wouldn't become victim to the attack making our solution work effectively as the antidote.

Per-Session Dynamic Payloads

Are attacks where the bad actor generates unique malicious payloads for each real user automatically using technique like wrapping scripts with dynamic keys, polymorphic JavaScript, A/B testing style logic... Often using the user's authentication indicators as a condition to inject the malicious paylods.

Why cside's approach works best here: we're actively running in the browser as scripts execute their actions. Resulting in us detecting the malicious actions as they happen. Our optional gatekeeper approach even keeps copies of payloads giving you full forensics capabilities.

Intermittent Supply-Chain Poisoning

This is an extremely common method used in Magecart style attacks. A bad actor can simply sample the attack to only serve the malicious script content to 1% of users. This method makes it a lot harder for a visitor to notice the attack as the totally random injection of the script make reproducing the attack a lot more difficult.

Why cside's approach works better here: whether an attack targets 0,1% of users or every user, we're actively monitoring the script actions.

Attackers combining techniques

If a bad actor injects a malicious script 5% of the time, after office hours only to residential IPs in the UK, no scanner will be able to capture the malicious script in the act. And for a bad actor that targets a high value target, this is a low effort act. Reflectiz's claims that they detect "20-50%" more attacks is an unsubstantiated and technically unlikely statement as explained above.

The reality is simple: when a scan is performed, but the scan can easily be detected, expect the scan to see different results from real users...

How Reflectiz block scripts

Reflectiz differentiates itself by positioning itself as an easy process to onboard without impacting the application.

It is correct that a scanner (or in modern times called an agent) does not impact web performance. However, its not necessarily faster to implement. Contrary so, their team offers implementing the scanner for you because the complexity can be severe. A lot of websites require cookies or session tokens to get to the payment pages. Those values have an expiration timeframe. More crucially, without doing a code change or adding anything to the website, it's not possible to block a malicious actor. 

Reflectiz optionally offers a client-side script to block scripts defined by its customers. You still need to add a script in the end if you wish to block scripts. So that defeats the entire "agent-less you don't need to change any code concept". The fact that you need a script to block also proves what we have been saying here: a client-side script is necessary if you wish to actually act on a threat. Their blocking capabilities are limited to blocking domains. Other vendors including cside block behaviors, urls, hashes and in the case of cside can even roll back to safe versions of scripts.

PCI DSS 4.0.1 and Client-Side Script integrity

PCI DSS compliance is not as subjective as it should be. QSA's have personal views. A pass by one QSA can be a fail by another. However, the PCI SSC releases helpful documentation with suggestions.

On requirements 6.4.3 the below guidance is shared:

As you can tell, scanner based approaches are not mentioned. That is of course because they have no ability to prevent scripts from loading or analyze script behaviors at runtime making for it unable to guarantee security.

If your QSA signs off on an approach, but an attack does happen, you find yourself in noncompliance remediation. In such scenarios credit card brands have the power to require one of their trusted QSA's to do another assessment.

Those QSA's will be a lot more particular about the technology choice and approaches used as at that point their role is to make sure no corners are cut.

So why take the risk?

Addressing incorrect claims made by Reflectiz about cside

Given the amount of false claims, we made a dedicated blogpost about them which you can read here.

One of the core management principles of cside is to take action to make a safer web. That is why we contribute to standards bodies like the w3c and the PCI SSC. 

When we compare to vendors, we do so in a technical manner and focus on the objective design principles they have followed.

Unfortunately, this code of conduct is not followed by all vendors. Sharing false statistics, making up claims and self contradicting in the same blogpost. While we’d like to ignore the untruthful claims made by Reflectiz, it's important to set things right.

To set the record straight on the allegations made by Reflectiz:

1. Incorrect claim: cside has access to all you customer data, password, credit card numbers and PII
   The way our solution works is rather straight forward: we have the scripts running through our infrastructure in a 'scrictly conduit' fashion. Meaning, we analyse the script contents on our end. These scripts are publicly accessible already and do not contain any sensitive information.
   In the browser we then check how a script behaves. What input fields it tries to interact with, what browser APIs it attempts to access, the connections it opens to other services... Monitoring the actions the script takes has nothing to do with the content a user types. We're in a totally different dimension. This is a categorically false statement.
   Reflectiz only has data on the scans they did. Which is part of the problem, they do not have real user context on how scripts behave.
2. Incorrect claim: cside becomes a data custodian
   Cside interacts purely with the script contents and their actions and in no way interacts with actual user data. Therefore, we are not a data custodian. Even when using our gatekeeper solution, cside acts as 'strictly conduit' meaning we are not the serving party and act purely as pipework to deliver a service by another solution provider. As a SOC2 Type 2 audited US company with a team mostly Europe based team that worked on distributed systems, privacy laws is an area we have a lot of first hand experience with.
3. Incorrect claim: It takes weeks to deploy cside 
   Most of our customers onboard within minutes. It does not take weeks to months to implement cside, contrary to the claims made by Reflectiz. You can find information about our implementation steps on our docs site. All you have to do is copy paste a script. On the other hand, Reflectiz does onboarding for you because bypassing captcha's to scan a page is a fiddly task that needs to be redone when things change on the webpage. With a scanner, if you website changes more work needs to be done. It never ends. We know, because we also provide a scanner based option and have implemented AI reasoning models to help with this..
4. Incorrect claim: cside only offers a proxy-based solution

Cside offers a range of options and never proxies all traffic. The fact is: browsers were not built for client-side security so offering multiple approaches is the best way forward.

• 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.
Given most client-side scripts allow caching through their respective cache-control headers, cside when is in 'gatekeeper mode' tends to make script delivery faster.

4. Incorrect claim: cside uses a basic LLM deobfuscation method
   Cside uses a range of deobfuscation mechanisms to make heavily obfuscated code human readable. In fact, we even contributed to open source ones for years... Deobfuscation is a complex subject, by design deobfuscation is a cat and mouse game. Open source deobfuscation projects are widely available. On top of deobfuscation, in cases where a malicious script attempts to hide malicious behaviours in a hard to deobfuscate manner, our self hosted (non publicly accessible) LLMs are surprisingly capable at capturing the malicious behaviors still. Security is about layering, this additional layer has proven rather effective.
5. Incorrect claim: cside adds catastrophic downtime risk
   If cside were to go down, we fail open because the very script on the webpage that does the checks would not serve. Customer's websites are never impacted by our infrastructure status, we built our services to cover this concern from day 1 as we knew what we were getting into. We have a detailed blogpost about how cside handles downtime incidents. We also have a range of failsafe mechanisms, even including our own IP ranges which allow us to route traffic to different cloud providers if required.
6. Incorrect claim: cside detects less components due to ad blockers
   Cside is not blocked by ad blockers. They quote a claim for 2024 in a Brave community blogpost related to a test domain. Any client-side fetched asset can be blocked by an ad-blocker but at present, that is not the case for cside. Reflectiz'es own client-side script needed for blocking could be stopped by an ad blocker, stopping them from blocking scripts on sites. They claim 30%, Brave has 1,3% market share. These stats are not supported by any evidence or publicly available data and conflict with the market share of Brave.
7. Incorrect claim: cside affects your analytics data
   Cside does not corrupt any analytics data. The way analytics scripts exfiltrate behavioral data is not impacted in any way by our client-side checks or gatekeeper approach. This claim is also unsupported and ignores basic technical factualities on how analytics tools work. A great way to find out how analytics tools work is by reviewing the inner workings of open source tools like Posthog. Analytics tools never trust request headers because corporate VPNs, hotel WiFi and even some ISPs fiddle with these values.
   
   Something that ofcourse does affect analytics data is a scanner that behaves 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.
8. Incorrect claim: cside pricing is traffic based
   Our pricing is built to be simple, based on pageviews to relevant protected pages (not overall traffic) and is public on our website. We do not perform pricing on a “for you my friend special price” model. We are one of the only vendors with public pricing on our webpages. Cside's paid plans start at $999 per year which is cheaper than most competitors and we actively check the application and don't just scan it periodically. Scanning a page is ofcourse a lot cheaper than being on the page monitoring each script behaviour.
9. Incorrect claim: cside has no visibility into iframes
   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.
10. Incorrect claim: cside detects less scripts than Reflectiz
    As explained above, it’s incredibly unlikely that a scanner based architecture is able to detect targeted or advanced malicious scripts. Reflectiz claims to catch 20-50% more attacks but did not support this claim by any data nor is that a statistic that any vendor can make if the opposite party in question doesn't publicly share attack statistics.
11. Incorrect claim: with cside you have to deal with complex DNS and SSL setups
    This is incorrect, cside is just a script on the webpage. These statements reflect misunderstandings of how modern client-side technologies work.

Conclusion

Most of the statements made in their blogpost about cside are baseless and inaccurate. We've reached out to Reflectiz to rectify these claims but so far we have not received any data supporting these claims not have they cooperated in the correction of these claims.

We condemn vendors spreading misinformation about others in an attempt for commercial gain. Especially when it comes to subjects related to the security of consumers online. When opportunism and solutions with easy bypasses discredit the hard work others do, we all become a little less safe online.

You don’t have to take our word for it, ask ChatGPT, ask ClaudeAI or ask Perplexity.

How cside goes further

cside offers a highly flexible approach to client-side security. Whether we monitor script behaviors client-side and check the scripts more deeply on our end through client-side reporting on our engine, cside gets the full picture. It analyzes the served dependencies code in real-time helping you prevent unwanted behaviours from causing major business impact.

Our approach 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, HIPAA, GDPR, CPRA...

We even provide deep forensics, including if an attacker attempts to bypass our detections. We even store data on missed attacks allowing us to make detections better. Giving you the control you need in an easy to use format.

Dealing with the limitations of browsers, we know 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 know the limitations on browsers and invest time contributing to standards bodies to natively supported make security capabilities better and more easy to use. 

Sign up or book a demo to get started.