Download websites that use RapidSec

About RapidSec

Content Security Policy is the control that every security review recommends and most teams never finish deploying. The obstacle is arithmetic rather than principle. A working policy has to enumerate every script, frame, font and image source a site loads, and any site with a marketing department loads a moving target that changes whenever a campaign ships.

RapidSec automates that problem, and doing so requires putting code in the browser. What makes the entry interesting for research is precisely that requirement. Almost every other security purchase a company makes lives at the network edge, in a build pipeline or inside a private console, and leaves nothing a crawler can observe. A policy management product has to instrument the page it protects, so it becomes one of the very few security team decisions that is visible from outside the organisation without any privileged access.

Visibility comes with instability, and the number needs that caveat. As of September 2026 we detect the agent on 40 sites. Deployments of this kind frequently cover part of an estate rather than all of it, and report only rollouts are often removed once a policy has been finalised and enforced, so a site can drop out of the list at the moment the customer succeeds. Movement in the row therefore reflects deployment stage as much as it reflects customer count, and a time series should be read with that in mind.

There is a second inference available from the same signal. A company that needs automated policy management is usually a company whose pages carry a substantial load of third party script, since a site with three scripts writes its policy once by hand and never thinks about it again. Detection therefore tends to mark larger properties with active marketing operations, complicated tag estates and a security function with enough standing to impose a control on them.

The product is Proprietary, written in JavaScript, and dates from 2019, which places it among the tools built after browser side security moved from a specialist concern to a checklist item on enterprise vendor questionnaires. Each detection points at an organisation that decided the manual route was not working and paid for the alternative, which is a specific and fairly advanced buying position. The address we hold for the vendor now redirects to another security company's site rather than to a product page, so a detection is better read as a deployment that outlived that change than as proof of a live subscription today.

Looking up a single domain tells you what headers that site sends today, and free tools already answer that question well. The Security list answers who bought a product to manage those headers, which is a different question entirely and one the headers themselves do not reveal. Security vendors doing competitive work, researchers studying policy adoption in the wild and buyers wanting references from companies at a similar maturity level all need the population rather than one site's response.