This article takes an honest look at some of the features of Human Security vs c/side. Please note that you’re on the c/side website. While we have a natural bias, we present both tools in the same light. To complete your research, please visit the Human Security product pages.
For the purposes of this comparison, we only look at Human Security’s client-side and PCI DSS security features.
This is already an important aspect. Human Security started in the bots detection space, and are well known for creating very sophisticated and lauded tools to tackle those issues. They’ve since expanded and offer products in the client-side and other spaces too.
You should know that Human Security announced a merger with PerimeterX in July of 2022. They were then backed by a $100 million debt facility from Blackstone Credit, a Private Equity firm.
The differences between Human Security and c/side
| c/side | Human Security | |
|---|---|---|
| Doesn't rely on CSP policies | ✅ | ✅ |
| Doesn't cause errors in the browser terminal | ✅ | ✅ |
| Client side JS script detection | ✅ | ✅ |
| Uses threat feed intel | ✅ | |
| Monitors Who-is records | ✅ | |
| Monitors SSL | ✅ | |
| Able to detect inline scripts | ✅ | ✅ |
| Uses AI to analyse scripts | ✅ | ✅ |
| Is able to block scripts without creating an allow list | ✅ | ✅ |
| Proxies scripts | ✅ | |
| Stores script content for future review | ✅ | ✅ |
| 100% certainty that the script reviewed is the one seen by the browser of the user | ✅ | ✅ |
| Stores historical script content to improve detections and help investigations | ✅ | ✅ |
| Performance enhances scripts | ✅ |
What we don’t like about Human Security
Their offering seems to be most focussed on PCI DSS 4.0. Similar to c/side, they do all that’s required to ensure PCI DSS 4.0 compliance when it comes to third-party script management:
- Discover, maintain, and detect changes to the script inventory on payment pages
- Give a method to authorize, justify, and assure the integrity of those scripts.
Only, the approach to get there is different, and that comes with a few differences we’ll get into now.
In their solution brief which can be found publicly on their site, they talk about “proactive automated policies” to block scripts. And also “Policy rules [to] enable proactive mitigation, such as blocking entire scripts/domains, surgically restricting access to sensitive form fields, and denying undesired cookies”.
This reveals that they use a similar approach to most of our competitors, that of a pre-approved allow-list. This is better than doing nothing, but it doesn’t stop 0-day attacks since it fundamentally “doesn’t know what it doesn’t know”.
In that solution brief, they claim they “detect risky and anomalous script behaviors, security and privacy vulnerabilities, HTTP security header modifications, and risk-scored incidents” but don’t explain in detail how they do that exactly.
They also claim their solution runs in every consumer browser session, which should be applauded as it goes a step beyond most other tools in the space.
Combining both then, we speculate that in every session these scripts are scanned against the latest-checked versions.
This is how c/side works too, without one key element: the proxy. At c/side, all your scripts are run in a proxy before they’re loaded in the browser of the user. When our detection engine spots anything, we’re able to mitigate that before the user is potentially attacked.
We then also optimize scripts, to counteract any latency caused by the proxy. In most cases speeding up scripts rather than slowing them down.
From what we can see, Human Security’s solution does not do the proxy approach. So they must do their checks while the scripts are being loaded in the browser, not before. This makes them unable to step in while the attack happens. At best killing the session as soon as they detect anything, but we haven’t seen evidence of that. Client-side blocking is easily circumventable and as such this approach may not work.
This is also not a perfect solution, since client-side attacks are often extremely targeted and as such the bad actor will go out of their way to avoid the detections that were implemented. As we saw in the Polyfill attack, it only triggered when certain conditions were met.
It should be noted that they go beyond other competitors in also publicly stating they save scripts for analysis, and use a mixture of AI and LLMs to their detection methods, similarly to c/side.
Finally, their client-side protection tool is part of the “Application Protection” package. So it seems it can’t be used outside of that package. Neither is there an easy call to action to get started or any pricing publicly available to complete your research.
At c/side, we vouch for security to be accessible to all. And for users to take action on their own behalf te securite their operations and serve their customers in a safer way.