This article takes an honest look at the features of Feroot.
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, objective technology analysis and our own or our customers' experiences.
If you want to verify their claims yourself, please navigate to their product page.
| Criteria | c/side | Feroot | Why It Matters | What the Consequences Are |
|---|---|---|---|---|
| Approaches used | Proxy | JS-Based Detection | ||
| Real-time Protection | Attacks can occur between scans or in the excluded data when sampled | Delayed detection = active data breaches | ||
| Full Payload Analysis | Ensures deep visibility into malicious behaviors within script code itself | Threats go unnoticed unless the source is known on a threat feed | ||
| Dynamic Threat Detection | Identifies attacks that change based on user, time, or location | Missed detection of targeted attacks | ||
| DOM-Level Threat Detection | Tracks changes to the DOM and observes how scripts behave during runtime | Unable to identify sophisticated DOM-based attacks | ||
| 100% Historical Tracking & Forensics | Needed for incident response, auditing, and compliance | Needed for incident response, auditing, and compliance | ||
| Bypass Protection | Stops attackers from circumventing controls via DOM obfuscation or evasion | Stealthy threats continue undetected | ||
| Certainty the Script Seen by User is Monitored | Aligns analysis with what actually executes in the browser | Gaps between what's reviewed and what's actually executed | ||
| AI-driven Script Analysis | Detects novel or evolving threats through behavior modeling | Reliance on manual updates, threat feeds or rules = slow and error-prone detection | ||
| QSA validated PCI dash | The most reliable way to ensure a solution is PCI compliant is to conduct a thorough audit by an independent QSA | Without QSA validation, you rely entirely on marketing claims, which could result in failing an audit | ||
| SOC 2 Type II | Shows consistent operational security controls over time | Lacks verified security control validation, making it a risky vendor | ||
| PCI specific UI | An easy interface for quick script review and justification via one click or AI automation | Mundane tasks and manual research on what all the scripts do, which takes hours or days |
What is Feroot?
Feroot was founded to create a client-side security solution protecting dependencies, similar to cside back in 2017. They combine two approaches to deliver their security claims.
How Feroot works
Feroot’s offering is split into two products: “PageGuard” and “Inspector”.
Feroot PageGuard
Their PageGuard page reads:
“PageGuard deploys security permissions and policies to JavaScript-based web applications to continuously protect them from malicious client-side activities, malware, and third-party scripts.”
And:
“PageGuard overwrites certain main and core JavaScript code to protect your web application from client-side cyber threats.”
It’s clear they largely follow the same approach as most of our competitors. They use permissions and a form on an allow-list where you pre-approve which scripts are allowed to run on which pages.
There are a few problems with this approach.
If only the source of the script is checked using an allow-list, it has no clue which code get's served.
PageGuard would not have caught the biggest client-side attack of 2024, the Polyfill attack. Here a domain changed ownership and suddenly the script code changed. If only the source of the script is checked using an allow-list, it has no clue which code get's served. Solely relying on this is not safe.
Feroot Inspector
Their “Inspector”, deploys synthetic users disguised as honeypot customers, to simulate real user behavior. Inspector’s synthetic users are able to complete real user tasks and are able to identify malicious scripts and unauthorized actions on JavaScript web assets. This is a somewhat similar approach to Reflectiz.
This is effectively a crawler that does periodic checks on pages. A crawler can easily be avoided by only serving malicious scripts to residential IP adressess. Based on various parameters, like different user agents, different client-side scripts are served.
A crawler on its own can not meet PCI DSS requirements since one of the requirements is implementing 'a mechanism to prevent unauthorized scripts'.
How cside goes further
Cside primarily offers a hybrid proxy approach which sits in between the user session and the 3rd party service. It analyzes the served dependencies code in real-time before serving it to the user.
This 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. We even provide deep forensics, including if an attacker bypasses our detections. Allowing you to more tightly scope the size of the incident us to make our detection capabilities better every day. No other vendor has this capability.
We believe 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've seen it all, this is the only way you can actually spot an attack.
Sign up or book a demo to get started.
