Reflectiz vs cside

This article takes an honest look at the features of Reflectiz.

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, basic technical principals and our own or our customers' experiences.

We encourage vendors to reach out in case any of the below information is inaccurate. In this case we even asked Reflectiz to share any adjust we should make, but they didn't share any.

What is Reflectiz?

Reflectiz is a scanner based tool for compliance and privacy of client-side fetched dependencies on websites.

How Reflectiz works

Reflectiz offers an ‘agent-less’ approach to client-side security. Claiming it uses a “proprietary browser” which crawls the website. Mapping specific pages their users flagged but also checking pages at random following the sitemap.

There are a few problems with this approach.

While scanners can be used to address static security needs, 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 proving 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. 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.

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.

To illustrate this point

// 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.

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 if the developer tools are closed and only 5% of the time. 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. 

How they 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. 

Addressing incorrect claims made by Reflectiz about cside

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.
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, we know a thing or two about privacy laws.
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 mutliple 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 has access to customer data
   Cside does not have access to any personal information served by a site or entered by a user let alone storing it. Monitoring actions taken by scripts can be done without interacting with the payloads of such actions. We don’t have access to any sensitive content unless it is publicly accessible on the pages. Under no circumstances does cside store any PII, PHI, payment data or any user inputted information.
6. 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.
7. 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 false.
8. 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.
9. 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.
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.

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 they have decided to double down on the unsubstantiated 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.

But what about PCI DSS compliance?

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?

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.

FAQ

Q: How does cside's approach differ from Reflectiz's crawler-based/scanner-based approach?

A: The fundamental difference is real-time versus periodic protection. Reflectiz uses external crawlers that periodically scan your website from data center IPs, missing time-gated, geo-targeted, or user-specific attacks. cside's hybrid proxy handles every real visitor request in real-time, catching edge-case payloads the moment they're delivered. We provide continuous protection based on real user experience, while Reflectiz offers periodic snapshots that miss dynamic threats.

Q: Can attackers bypass cside's protection like they can with Reflectiz's crawler detection?

A: No, because cside's core analysis happens on our infrastructure combined with client-side intelligence, completely invisible to attackers.  Attackers can easily detect Reflectiz's crawlers because they come from non-human sources and can serve them clean versions of compromised scripts. Since cside processes every real user request through our proxy, attackers cannot distinguish our analysis from legitimate traffic. Our protection is invisible to attackers, while crawler-based approaches are easily identified and deceived.

Q: What forensic evidence does cside provide compared to Reflectiz's crawler reports?

A: Reflectiz provides periodic scan reports showing what their crawlers observed during scheduled visits, but cside captures and archives every script payload served to real users. This gives you complete forensic evidence of actual attacks rather than just snapshots of what crawlers saw. Our approach provides immutable proof of threats that were blocked from reaching users, not just what was visible during scanning.

Q: How do compliance capabilities compare between cside and Reflectiz?

A: cside provides superior PCI DSS compliance with continuous monitoring and immutable payload archives covering both requirements 6.4.3 and 11.6.1. Reflectiz's crawler approach provides periodic inventory reports but lacks the real-time monitoring and comprehensive forensic evidence that regulators require. Our continuous protection creates the complete audit trail that compliance officers need for thorough documentation.

Q: Why is cside's real-time protection better than Reflectiz's periodic scanning?

A: Real-time protection catches attacks the moment they're delivered to users, while periodic scanning misses threats that appear between scans or target specific user segments. Modern attackers use conditional logic to avoid detection by crawlers, serving malicious code only to real users. cside's continuous monitoring ensures no attack goes undetected, while crawler-based approaches have inherent blind spots that sophisticated attackers exploit.

Q: How is cside priced?

Our pricing simply follows pageviews and is publicly available on our website for the self service plan. Pageviews metrics should be available to any website owner through their analytics tools. We do not perform pricing on a “for you my friend special price” model, pricing is easy, predictable, and volume based discounts for large volumes is available.

Q: Does cside have access to all customer data, passwords, credit card numbers, or PII?
A: No. Cside works in a strictly conduit fashion. We analyze only publicly accessible script contents, which do not contain sensitive information. In the browser, we observe script behavior, such as what fields it interacts with or what APIs it calls. We never see what users type. Monitoring behavior does not require access to user data. Cside does not access or store any PII, passwords, payment data, or user submitted content.

Q: Does cside become a data custodian?
A: No. Cside only interacts with script contents and script behavior. We never interact with actual user data. Even in gatekeeper mode, cside is a conduit that passes data from a third party to the user without serving that data. Cside is SOC2 Type II audited, and our team has a strong background in privacy and distributed systems. We intentionally avoid becoming a data custodian.

Q: Does it take weeks to deploy cside?
A: No. Most customers onboard within minutes. Deployment requires pasting a single script into the website. Reflectiz likely makes this claim because their scanner based approach struggles with CAPTCHAs and needs to be repeated whenever a webpage changes. Scanners require ongoing work. We offer a scanner too, and we understand the workload involved. Cside's main deployment process is fast and simple.

Q: Does cside only offer a proxy based solution?
A: No. Cside provides multiple options and we do not proxy all traffic.
• Direct mode: We check script behavior in the browser and fetch scripts on our side to verify them. We only place ourselves in the path when a customer asks for this.
• Gatekeeper mode: We monitor script behaviors and place ourselves between untrusted third parties and users. This applies only to scripts the customer has not already trusted.
• Scan mode: When a site cannot add our script, cside scans it and uses threat intelligence from thousands of websites and billions of visitors.

This combination provides the widest coverage possible. Because many scripts use caching headers, gatekeeper mode often makes script delivery faster.

Q: Does cside use a basic LLM deobfuscation method?
A: No. Cside uses several deobfuscation techniques, including open source tools we have contributed to. Deobfuscation is always a cat and mouse problem, so multiple methods are needed. When malicious scripts hide behavior in ways that are hard to deobfuscate, our self hosted LLMs are still effective at identifying harmful actions. This is one more security layer, and it works well.

Q: Does cside have access to customer data?
A: No. Cside does not access or store personal information or content entered by users. Script behavior monitoring does not require access to payloads or form submissions. We only see what is publicly visible on the page. We do not store PII, PHI, payment data, or user input under any circumstances.

Q: Does cside add catastrophic downtime risk?
A: No. If cside goes down, we fail open. This means our checking script does not run, but the customer website continues to operate normally. The system was designed this way from the beginning. We have multiple failsafe mechanisms, including our own IP ranges and the ability to route traffic through different cloud providers. We have published detailed information explaining how cside handles downtime.

Q: Does cside detect fewer components because of ad blockers?
A: No. Cside is not blocked by ad blockers. The claim comes from a Brave community post about a test domain, not real world conditions. Any client side request can theoretically be blocked, but this is not happening with cside. Reflectiz's own blocking script can be blocked by ad blockers, which would prevent their solution from working. Their statistic of 30 percent impact compared with Brave's 1.3 percent market share is not accurate.

Q: Does cside affect analytics data?
A: No. Cside does not corrupt analytics data. Analytics tools rely on their own mechanisms for collecting behavioral information, and our checks do not interfere with them. This claim ignores how analytics actually works. Open source tools like Posthog show that analytics providers do not trust request headers because they are often changed by VPNs, hotels, and ISPs.

Q: Is cside pricing based on traffic?
A: No. Cside pricing is based on pageviews to protected pages, not total traffic. Our pricing is simple and public. We do not use special pricing tactics. Paid plans start at 999 dollars per year, which is lower than most alternatives. We actively monitor script behavior instead of scanning pages occasionally. Scanning is cheaper, but it is less effective.

Q: Does cside detect fewer scripts than Reflectiz?
A: No. Scanner based systems struggle to detect targeted or advanced malicious scripts because they rely on snapshots, not live behavior. Reflectiz claims they detect 20 to 50 percent more attacks, but they provided no data to support this. No vendor can make this claim without access to the other vendor's attack statistics, and these numbers are not public.