On-Demand Script Blocking for Client-Side Threats.
When your web monitoring detects a malicious third-party script, you need to block it fast, without introducing new risk to your site. Reflectiz’s Idle Blocking Script gives security leaders a controlled, reversible, CSP-based response mechanism that activates only when you need it and disappears when you don’t.
What Is On-Demand Script Blocking?
On-Demand Client-Side Script Blocking, Defined
On-demand script blocking is a threat response approach in which a security platform enables teams to block malicious third-party domains from executing on their website, without deploying persistent code, without developer involvement, and without disrupting normal site operation.
Unlike always-on blocking mechanisms that run continuously and add permanent overhead to every page load, on-demand blocking is inactive by default. It activates only when a confirmed threat requires immediate containment, and reverts the moment the threat is resolved.
Reflectiz implements on-demand blocking through what it calls the Idle Blocking Script
Reflectiz implements on-demand blocking through what it calls the Idle Blocking Script, a lightweight mechanism that enforces domain-level blocking via Content Security Policy (CSP) meta headers, controlled entirely from the Reflectiz user interface.
<head>
…
<script scr=”https://xxxxxx.blocking.reflectiz.net/blocking.min.js“></script>
…
<head>
When a Malicious Script Is Confirmed, Every Minute Counts
Third-party scripts are the most common vector for client-side attacks. When a script is compromised—whether through a supply chain attack, a Magecart injection, or unauthorized behavior change, the window between detection and containment determines the extent of the damage.
For security leaders, the blocking decision carries its own risks. Traditional blocking approaches require developer involvement, code changes, and deployment cycles that slow response time. Always-on blocking agents add persistent overhead and create new dependencies that can affect site performance and availability.
The question CISOs face is not just “can we block it?” It is “can we block it fast, safely, and reversibly—without making the cure worse than the disease?“
On-Demand Blocking Is the Safer Architecture
On-Demand vs. Always-On Blocking
The client-side security market offers two broad approaches to script blocking: always-on agents that run continuously on every page load, and on-demand mechanisms that activate only when a threat requires response. These are not equivalent.
| Capability | Always-On Blocking Agent | Reflectiz On-Demand Blocking |
|---|---|---|
| Default state | Continuously running | Idle — no code executing |
| Performance impact | Adds latency on every page load | Zero impact in idle state |
| Compliance risk | Present at all times | Eliminated during idle state |
| Compatibility risk | Ongoing | Eliminated during idle state |
| Activation | Automatic / rule-based | Triggered by confirmed alert |
| Revert capability | Complex | One-click via UI |
| Data transmission | Varies by vendor | No business or PII data transmitted |
| Developer involvement to block | Often required | Not required |
| Audit visibility | Varies | Ongoing blocked domain list in UI |
On-demand blocking does not mean slower blocking. It means blocking that is deliberate, controlled, and initiated by a human decision after a confirmed threat—rather than an automated response that may trigger incorrectly and affect legitimate site functionality.
How It Works
Four Stages. Full Control at Every Step.
The Idle Blocking Script operates through a four-stage process, initiated and controlled entirely from the Reflectiz user interface. No developer involvement is required at any stage.
What Is CSP-Based Blocking?
What Is Content Security Policy (CSP) Blocking and Why It Matters
Content Security Policy (CSP) is a browser-native security mechanism that controls which external resources a webpage is permitted to load and execute. By defining an allowlist of trusted domains, CSP prevents unauthorized scripts, iframes, and other resources from running, regardless of how they were introduced.
CSP-based blocking is widely recognized as one of the most effective and least intrusive methods for containing client-side threats. Because it operates at the browser level via HTTP or meta headers, it does not require modifying application code, and it cannot be bypassed by the blocked domain itself.
When the Reflectiz Idle Blocking Script is activated, it adds a CSP meta header to the page that explicitly excludes the malicious domain. When blocking is no longer needed, that header is removed and the page returns to its normal state.
Built for Security-First Organizations
What Makes the Idle Blocking Script Safe to Deploy
Detection + Response
Remote Monitoring Detects. On-Demand Blocking Responds.
Reflectiz’s primary architecture is remote monitoring: continuous, off-site scanning of your web environment without deploying persistent code on your site. Remote monitoring provides visibility into threats that embedded solutions structurally cannot detect: cross-origin iframes, server-side cookies, URL manipulation, and CVEs.
The Idle Blocking Script is a deliberate extension of that architecture into the response layer. It does not replace remote monitoring. It activates after remote monitoring has surfaced a confirmed threat and the security team has made a decision to act.
This sequence matters. Blocking without accurate detection leads to false positives that disrupt legitimate site functionality. Detection without a response path leaves confirmed threats active while remediation cycles play out. Together, remote monitoring and on-demand blocking give security leaders a complete, controlled threat management cycle for client-side risk.
Complete Visibility. Surgical Response. Full Control.
Reflectiz detects what other solutions miss—and gives you the tools to act the moment it matters.
FAQs
Does the blocking script send user data to Reflectiz?
No. No business data or personally identifiable information is sent to Reflectiz servers at any point. The script enforces CSP headers locally and does not transmit user data externally.
Does the Idle Blocking Script run continuously on my site?
No. The script is idle by default. No code is running on user browsers until a block request is generated. This eliminates compliance risk and compatibility issues during the idle state.
How do I block a malicious third-party script with Reflectiz?
When Reflectiz’s remote monitoring detects a threat and triggers an alert, the security team initiates a block request from the Reflectiz UI. No developer involvement or code deployment is required. The blocking script loads, adds a CSP meta header excluding the malicious domain, and blocking is active within the same session.
How do I reverse a block?
The Reflectiz UI provides an ongoing list of currently blocked domains and a one-click revert option. Selecting revert returns the script to idle mode and restores the page to its regular state.
How does blocking relate to Reflectiz’s remote monitoring architecture?
Remote monitoring is Reflectiz’s primary capability—continuous off-site scanning that detects threats without deploying persistent code on your site. The Idle Blocking Script is a complementary response layer that activates after remote monitoring surfaces a confirmed threat. Detection and response are designed to work in sequence: remote monitoring provides the intelligence, on-demand blocking provides the action.
How does CSP-based script blocking work?
Content Security Policy (CSP) is a browser security mechanism that controls which external domains a page is permitted to load resources from. When a malicious domain is identified, a CSP meta header is added to the page that excludes that domain—preventing it from executing scripts or loading resources. When blocking is no longer needed, the CSP header is removed and the page returns to normal. Reflectiz’s Idle Blocking Script automates this process, triggered and reversed from the Reflectiz user interface.
Is the Idle Blocking Script the same as an embedded security agent?
No. A persistent embedded security agent runs continuously on your site, interacts with page components, and typically transmits data to external servers. The Idle Blocking Script is inactive by default, does not interact with any other components on the website, transmits no business or PII data, and activates only on explicit demand. It is a surgical response tool, not a persistent monitoring agent.
What is on-demand script blocking in client-side security?
On-demand script blocking is a threat response approach that allows security teams to block malicious third-party domains from executing on their website without deploying persistent code. Unlike always-on blocking agents that run continuously, on-demand blocking is inactive by default and activates only when a confirmed threat requires containment. Reflectiz implements this through its Idle Blocking Script, which enforces blocking via CSP meta headers controlled from the Reflectiz UI.
What is the difference between on-demand blocking and always-on blocking?
Always-on blocking agents run continuously on every page load, adding persistent overhead, latency, and compliance risk regardless of whether a threat is present. On-demand blocking is inactive by default and activates only when a confirmed threat requires response. This eliminates performance impact during the idle state, removes ongoing compliance and compatibility risk, and ensures that blocking is a deliberate, human-initiated decision rather than an automated action that may trigger incorrectly.
What is the Reflectiz Idle Blocking Script?
The Reflectiz Idle Blocking Script is an on-demand threat response mechanism that allows security teams to block malicious domains via CSP meta headers, directly from the Reflectiz UI. It is inactive by default—no code runs on user browsers until a block request is explicitly triggered. When activated, it enforces domain-level blocking. When the threat is resolved, it reverts to idle with a single click.
