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.

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.

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 dynamicness your users combined will naturally.

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. 

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, however that only 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 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: 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.

2. Incorrect claim: cside only offers a proxy-based solution

Cside does not proxy all traffic, we offer the ability to use the hybrid proxy for high risk scripts as a measure to gain ultimate control. Reflectiz mentions latency however they do not reference any sources. Given most client-side scripts allow caching through their respective cache-control headers, cside when in 'gatekeeper mode' tends to make script delivery faster.

3. Incorrect claim: cside uses a basic LLM deobfuscation method

Cside uses a range of deobfuscation mechanisms to make heavily obfuscated code human readable. 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.

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

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 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 claim 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 could be stopped by an ad blocker, stopping them from blocking scripts on sites.

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 hybrid proxy 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.

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.

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

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.

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.

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 approach 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 or our hybrid proxy, 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.