In July 2025, a domain previously used by a content delivery network (**CDN**) was re-registered after its expiration. Despite the **CDN** having ceased operations years prior, thousands of websites, code repositories, and documentation pages still harbored hard-coded references to hostnames under this now-reclaimed domain. The new owner, leveraging wildcard DNS, now controls any hostname under this domain. While the apex currently serves an ad-heavy media downloader, the critical issue is that a stranger now dictates what content those thousands of pages load next. Crucially, this shift went unnoticed by affected parties because, from an external perspective, nothing appeared broken. This isn't a hypothetical scenario. In June 2024, the **polyfill.io** domain, a JavaScript shim embedded in over 110,000 sites, changed ownership. It subsequently began serving conditional redirects to mobile visitors. The websites utilizing this script were not hacked; they had simply outsourced a `<script>` tag years ago and never revisited that decision. Both cases highlight a significant blind spot for most security teams: malicious code was never on their servers, arriving long after the last deployment. ## Server-Side Tooling Looks in the Wrong Place Traditional security tools like static analysis, dependency scanning, and software composition analysis primarily examine what an organization builds and ships. However, a third-party script falls outside this scope. It's fetched by the visitor's browser from a server an organization doesn't control, live on every page view. This dynamic makes it uniquely challenging for conventional testing. Responses can vary based on geography, user agent, referrer, time of day, and session. A crawler might retrieve a clean version from a data-center IP, while a shopper on a mobile network in another country receives something far more sinister. Furthermore, third-party scripts possess the same privileges as first-party code. They can read the **DOM**, capture form field inputs character by character, access cookies and local storage, and make outbound requests to any destination. Client-side attacks, such as those seen in **Magecart** campaigns, don't require a server breach; they only need one approved script tag to behave maliciously. ## The Browser Sees Everything The browser is the one constant observer for every page view. While **Content Security Policy (CSP)** is widely recognized as a defense against cross-site scripting, its secondary function is invaluable for security teams unaware of all the code running on their sites. A **CSP** can control what code is permitted to execute, block unauthorized scripts, and alert you when such events occur. These alerts originate from real user sessions, in real geographies, on actual devices. A malicious payload that only targets logged-in users in a specific country will still be reported because the browser executing it sends the alert. This isn't just a theoretical advantage. In September 2026, alerts collected by **Report URI** exposed a cluster of compromised e-commerce sites engaged in a "**ClickFix**" social-engineering campaign. Base64-encoded loaders were embedded within **CMS** content following an administrative compromise. These loaders chained through a redirector to a fake "verify you are human" overlay, which then placed a **PowerShell** command on the victim's clipboard and persisted it as a scheduled task. The attacker-controlled hostnames appeared in victim browser alerts even while several of these domains were still rated clean by mainstream reputation services. No scanner flagged the pages because, on the server, they appeared innocuous. ## Starting with CSP Without Breaking Your Site The common apprehension about **CSP** is that it might disrupt website functionality. However, in report-only mode, this concern is mitigated. **Content-Security-Policy-Report-Only** enforces nothing, blocks nothing, and alters no behavior; it merely reports what a policy *would* have blocked. This allows for a safe initial deployment as a measurement exercise, enabling the collection of comprehensive data on all code running on your site. For many organizations, this list is often far more extensive than anticipated. ## Compliance Makes This an Obligation For any entity handling card payments on their site, this discussion is no longer optional. **PCI DSS v4.0.1** requirements 6.4.3 and 11.6.1 transitioned from best practice to mandatory on March 31, 2025. These requirements collectively mandate that every script on a payment page must be authorized, its integrity assured, and a written inventory with business justification maintained. Furthermore, a mechanism must detect and alert on unauthorized modifications of payment page content and **HTTP** headers. A **QSA** (Qualified Security Assessor) will request the inventory, the alerting mechanism, and the evidence trail it produces. **Report URI** can provide all three. ## What a Working Deployment Looks Like 1. Deploy and gather initial data for a week. 2. Build your inventory from the reported data. 3. Monitor changes over time and approve or deny those changes. A ten-year daily crawl of the top one million sites reveals **CSP** adoption has grown over 12,000% across the decade. This reflects organizations' increasing awareness of its benefits and a broader shift in the required visibility: not just into what they deploy, but into what code their users’ browsers actually execute. ## Where Report URI Fits In **Report URI** is a client-side security platform designed to answer critical questions security teams often cannot address about their own sites: Which third parties are executing code on your pages? Which have changed since yesterday? Which are exfiltrating data or communicating with known hostile infrastructure? Scripts served to real users are hashed and archived, enabling post-incident identification and investigation of changes. Hostnames are cross-referenced against threat intelligence, and policies are monitored for drift, bridging the gap between approved code and what's actually running on your site. Deployment requires no additional JavaScript on your page, nor any agent, module, or **SDK** added to your stack. The first step is simple: add an **HTTP** response header and analyze the data returned over the next 48 hours. The list of entities executing code in your customers' browsers is seldom what anyone expects!