This article takes an honest look at the features of Feroot.
Since you’re on the c/side website, we acknowledge our bias. That said, we’ve built our case honestly and based our analysis on publicly available information, industry information, and our own or our customers' experiences.
If you want to verify their claims yourself, please navigate to their product page.
What is Feroot?
Feroot was specifically founded to create a client-side security solution protecting dependencies, similar to c/side. 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 (likely periodic) check on pages. A crawler can somewhat easily be avoided since JavaScript is dynamic. Based on various parameters, it serves different versions of the script. The versatility of the crawler will eventually be what matters.
c/side however, uses a proxy approach which sits in between every actual user session. It checks the actual payload of every page view, and analyzes the served dependencies code in real-time before serving it to the user.
This allows us to not only spot 0-day attacks and alert, c/side 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 believe this is the most secure way to monitor and protect your dependencies across your entire website.
Sign up or book a demo to get started.