PCI Compliance & Regulations
Does c/side satisfy PCI DSS 4.0.1 controls 6.4.3 and 11.6.1?
Yes. VikingCloud’s independent assessment confirms that, when properly configured, both the (hybrid) proxy and crawler modes fulfil these requirements by continuously hashing, analysing, and, if necessary, blocking scripts in real‑time.
Read our VikingCloud assessment here.
How exactly does c/side meet PCI?
The (hybrid) proxy hashes and analyses every script on every page‑load, while the crawler performs twice‑daily inventories. New or modified hashes trigger the full AI/static‑analysis pipeline, and policy controls can immediately block malicious scripts.
How does c/side's solution help meet the new script‑monitoring requirements?
By providing real‑time payload inspection, automated blocking, full historical payload storage, and auditor‑ready reports that map directly to the testing procedures in PCI DSS 4.0.1
How do you detect and handle conditional script injections?
Because every payload is hashed for every browser session, even variants served to a small subset of users are flagged instantly as new hashes and re‑analyzed.
Sign up or book a demo to get started.
How does c/side compare to other solutions?
How does c/side compare to CSP‑only solutions (Cloudflare Page Shield, Report URI)?
CSP products let you list “good” domains and tell the browser to block everything else. That stops obvious out-of-scope hosts and ticks PCI 6.4.3, but it never looks at the JavaScript itself. If an attacker slips bad code onto an approved CDN or spins up a brand-new domain malware can run until someone updates the policy.
c/side works the other way around: every third-party script is fetched through our edge, hashed, scanned, and either served clean or blocked before the browser sees it. Because we keep the full payload and header record, we also cover PCI 11.6.1 without any manual lists to maintain.
Note: We support CSP as an optional overlay at no extra cost with our free CSP endpoint.
How does c/side compare to JavaScript “trap” products (Akamai, JScrambler, Human, Datadome, Feroot)?
Trap systems inject decoy objects or DOM hooks into the page and hope malicious code will interact with them; if the trap fires, the tool sends an alert from the browser. Attackers can simply ignore or delete those decoys, or block the callback endpoint, so sophisticated skimmers slip through. Detection also happens after the script has already reached the client, leaving no immutable copy for forensics if the beacon never fires.
In contrast, c/side’s proxy prevents the bad payload from reaching the browser in the first place: every script is fetched, hashed, scanned by static rules and an on-prem LLM, and either served clean or blocked. Because we capture and archive the exact bytes that were attempted, auditors and incident-response teams get a complete, replay-ready record far more useful than a “trap triggered” log entry. Because traps are so easy to bypass, we saw them miss more than 300 000 compromised sites in Q1 2025 alone, one of the findings that pushed us to build c/side in the first place.
Read more on our compare page.
Note: If you can’t proxy a particular script or page, c/side can fall back to a non-proxy (or hybrid-proxy) mode. In that setting we let the browser fetch the script, then immediately upload the full payload to the platform for analysis and long-term storage. You still gain far more visibility than a trap-based agent because we capture and archive the actual code, not just a beacon that may or may not fire while keeping the option to switch any script back to true inline blocking whenever you’re ready.
How does c/side compare to Crawler/Agentless approaches (like Reflectiz)?
External crawlers visit your site from a data-centre IP once in a while and record what they see. They’re fine for a basic inventory but blind to anything time-gated, geo-targeted, or shown to just a slice of users. Attackers can even detect the crawler and serve it a clean version. Because c/side’s proxy handles every real visitor request, those edge-case payloads show up the moment they’re delivered, and we can block them instantly. A scheduled crawler still runs in the background to pick up dormant scripts, but real-time defense happens inline.
Note: We offer a crawler-based service for teams with limited engineering resources and, unlike other crawlers, it re-uses live attack intel from our proxy fleet rather than third-party threat feeds like VirusTotal. Customers can upload LocalStorage, SessionStorage and cookies so we can reach the payment page.
How does c/side’s (hybrid) proxy works?
c/side sits in the path of every third-party request, fetches the actual JavaScript, and inspects it in real time. So malicious code is blocked before the browser can execute a single line. Because we keep the full payload, not just a hash or domain name, you get a byte-perfect copy of what each user was served: rock-solid evidence for audits and a “replay” record for forensics. Static scripts are cached at our edge and usually load faster than origin; dynamic calls add only 8–20 ms, well under a human blink. This design lets you shut down threats instantly, maintain complete visibility into what visitors really see, and watch every change over time to spot patterns or emerging risks. And because the platform is truly hybrid, you decide on a script-by-script basis which calls run through the proxy and which do not; any script you leave un-proxied is still captured and uploaded right after it’s served, and analyzed and logged for the same forensic trail.
How does c/side impact website performance and load times?
Typical added latency for dynamic scripts is 8–20 ms, often offset by edge caching and HTTP/3 optimization. Static scripts are cached and load faster.
How do you handle high‑traffic sites?
Autoscaling clusters behind the edge handle spikes; the service carries a 99.99 % SLA with a fail‑open design so we would never affect your website, payment pages or checkouts in case of an incident.
Sign up or book a demo to get started.
Data Collection & Privacy
Are you collecting or selling our end‑user data for advertising purposes?
No. Proxy and crawler only store the requester’s IP address for incident scoping; that data is never brokered or used for advertising. The website and dashboard use standard analytics tools (GA4, Clarity, etc.) that may place cookies, but that data is completely separate from customer traffic.
Is any proxy or crawler data used for advertising?
No. Proxy/crawler data is used exclusively for security analysis and forensic replay.
What data can be collected from the scripts you provide?
Aside from the requester IP, no personal data is collected. Full script payloads are stored solely for security analysis and compliance evidence.
Where is that data processed and stored?
All proxy and crawler data remains in c/side‑managed clusters hosted in AWS.
Do you use third‑party LLM APIs?
No. The detection engine uses an open‑source LLM that runs entirely inside the same AWS environment.
Sign up or book a demo to get started.
Implementation Options
Crawler vs (hybrid) Proxy. What’s the difference?
Proxy gives full inline coverage and blocking by routing third‑party requests through c/side’s edge; the crawler is a bot that inventories scripts on a schedule without code changes but cannot block in real‑time.
How easy is it to implement c/side, and can it be tested with a proof‑of‑concept?
Proxy PoC: add one <script> tag and watch live data within minutes.
Crawler PoC: add the domain in the dashboard; the first scan starts automatically.
Can you explain the proxy‑based approach for script monitoring and its benefits?
The proxy inserts a lightweight script that rewrites every third‑party fetch through a secure edge endpoint where the payload is hashed, analyzed, cached, and, if malicious, blocked before it reaches the browser.
How does c/side handle different types of websites, including React, Angular or SPAs?
Because c/side operates at the browser layer, framework‑generated script tags are rewritten and analyzed just like any other resource.
Can c/side work with self‑signed certificates?
Yes. The proxy terminates TLS at the edge, so the origin may retain a self‑signed certificate as long as a secure tunnel can be established.
Sign up or book a demo to get started.
Integration with Existing Tools
Can we integrate c/side with our SIEM?
Yes. c/side offers webhooks and API connectors for SIEMs
Do you push alerts to cloud storage?
Logs can be exported to an S3 bucket under your control.