Data Loss Prevention

Your data leaves from the browser. Your DLP watches your network.

When a page sends data straight from a visitor's browser to a third party, it never crosses your network at all. Nothing in your perimeter sees it. Report URI watches the place the data actually leaves from, and tells you when a new destination appears.

Start Free Trial Documentation →
What's at Stake

Traditional DLP is positioned between your servers and the internet. The data does not go that way.

Data loss prevention was designed around a shape of application that no longer describes the web. Endpoint agents, mail gateways and network inspection all assume the sensitive value passes through infrastructure you operate. On a modern site it frequently does not: the visitor types a card number, and a script on the page sends it directly from their browser to somewhere else. Your servers were never involved, so nothing you have deployed on them can see it happen.

Wrong Vantage Point

Browser to third party bypasses your perimeter

A request made by JavaScript on your page goes from the visitor's machine to whatever host it names. It does not traverse your network, appear in your egress logs, or pass any inspection you have configured. Your controls are watching a pipe the data never enters.

Repointed Forms

A single attribute changes where data is submitted

Altering where a form posts, or adding a listener that copies its fields, is a very small change to make and produces no visible difference to the user. The page looks identical and behaves identically, and the data now has a second recipient.

Invited Third Parties

Much of it is code you asked for

Analytics, session replay, chat widgets and advertising tags all send data outward by design. The question is rarely whether they transmit, but what they transmit and to where — and that answer changes when a vendor ships an update.

How We Help

Watch the point of departure, not the perimeter

The browser knows every destination your pages send data to, and will report them. That produces an inventory of where your data goes, an alert when the list changes, and a way to refuse destinations you never authorised.

Destination Inventory

Every place your pages send data, listed

Data Watch builds and maintains a record of the destinations your site transmits to, gathered from real browser sessions. Most organisations find the list longer than expected, and finding that out is the point — a baseline you did not have to assemble by hand is what makes the next new entry meaningful.

Learn more about Data Watch →
Enforcement

Name the destinations you allow, refuse the rest

A Content Security Policy does not only control what loads. connect-src governs where the page may send requests and form-action governs where a form may submit. Restricting both cuts off a skimmer's route out, because the browser refuses the transmission regardless of what the injected script intended.

Learn more about Content Security Policy →
Two Halves of One Signal

New script, then new destination

An attacker needs both: their code on the page, and somewhere to send what it collects. Script Watch reports the first and Data Watch reports the second, and the two arriving together is about as clear an indication of compromise as client-side monitoring produces.

Learn more about Script Watch →
Get Started

Find out where your data actually goes. Then decide where it may.

One header. No code. Your destination list starts building from the first visitor.

Start Free Trial Talk to our team →

30-day free trial  ·  One header  ·  No code  ·  Cancel anytime

Detection

Where data can leave a page

There are a limited number of ways a browser can transmit outward, and a policy can speak to each of them. Knowing which is which is most of knowing what your policy covers.

Route out What governs it
fetch and XMLHttpRequest connect-src — the usual route for a script sending collected data
Form submission form-action — where the page is permitted to post a form
WebSocket connections connect-src — a persistent channel rather than one request
Beacons sent on unload connect-src — frequently used to transmit as the user leaves
A new destination appearing Data Watch — alerting when the observed list changes
An unexpected destination blocked Your enforcing policy, reporting what it refused

Reporting tells you which destinations are in use before you restrict anything, so the allowlist you enforce is drawn from how your site actually behaves.

Architecture

One header. No code. No crawlers.

This works because the browser is the one component that sees every transmission a page makes. Nothing of ours runs on your pages and no traffic is routed through us — the browser reports where it was asked to send data, including from pages behind a login that no external scan reaches.

Start in report-only and nothing is blocked. Allowing your own origin keeps the report volume sensible while the baseline builds.

Minimal setup — no existing CSP
Content-Security-Policy-Report-Only: default-src * 'unsafe-inline' 'unsafe-eval';
  connect-src 'self'; form-action 'self';
  report-uri https://your-subdomain.report-uri.com/r/d/csp/reportOnly

As you identify legitimate destinations, add them to the policy. Reports for those stop, the volume falls, and the monitoring for anything new stays exactly as effective.

No code added to your pages

No traffic routed through us

Sees transmissions that never touch your network

Covers authenticated pages an external scan can't reach

Report-only mode blocks nothing while the baseline builds

Compliance

Knowing where data goes is increasingly the requirement

Regulation has moved steadily towards asking organisations to account for where personal and payment data ends up, not merely to promise it is protected. PCI DSS 4.0.1 asks you to know and justify what runs on a payment page and to detect unauthorised change to it. Data protection regimes ask where personal data is transmitted and on what basis.

A destination inventory drawn from real browser sessions answers both in the same artefact, and it is a record rather than an assertion.

PCI DSS Compliance →
Scope

One layer in the stack. Here's how it fits.

This covers data leaving the browser. It does not classify the contents of what is sent, and it does not replace controls on your servers or endpoints — it is the client-side egress layer, and it works alongside the rest.

Covers Using
Where your pages transmit data Data Watch for destination inventory and alerting
Refusing unauthorised destinations CSP for connect-src and form-action enforcement
What code is doing the sending Script Watch for dependency inventory and change detection
Whether a destination is known bad Threat Intelligence for indicator matching

Together, these form the client-side security visibility layer that sits between your CSP policy and your incident response process.