The essentials in 30 seconds
- Shadow IT goes first through the browser: an unapproved service, a web form, a copy and paste or an extension is enough to get data out without any DLP alert.
- No single control covers these four paths; TLS exclusions and rules designed for files create the blind spots.
- You need to map the usage, then replay synthetic exits and record what is blocked, alerted on or ignored.
Shadow IT refers to the applications, accounts and services used in the company without approval from the IT department. On the data leakage side, its main vector is the browser: a web form, a copy and paste into an online tool or an extension installed in two clicks is enough to get sensitive information out without any DLP rule being triggered. To reduce this risk, you need to discover these usages, then actively test whether your controls actually see these paths.
Why the browser has become the first channel of shadow IT
Fifteen years ago, shadow IT meant software installed on a workstation or a server hidden under a desk. Today, almost everything goes through a tab. PDF converter, translation tool, shared spreadsheet, file transfer service, writing assistant: no installation, no administrator rights, no request to the IT department.
The problem is not bad faith on the part of users. They want to move fast. The problem is that most DLP systems were designed around known channels: email, USB devices, network shares, a few sanctioned SaaS applications. The browser, for its part, opens an infinite number of destinations, encrypted, often hosted on perfectly legitimate cloud infrastructure.
The four exfiltration paths you do not see
Diagram · four egress paths
1. Unapproved applications
A personal account on a storage service, a consumer project management tool, an electronic signature platform chosen by a business department. Each one is an egress destination. If your CASB or your proxy does not know the application, or classifies it in an allowed category (“productivity”, “hosting”), the flow gets through. The topic of everyday collaboration tools is covered in detail in our article on personal cloud, Teams and Slack.
2. Web forms
This is the most underestimated path. A text field in a contact, support, ticket or survey form often accepts several thousand characters. A user who pastes an extract of the customer database into a quote request form at a supplier is not performing a “file upload”. Many policies only monitor attachments and file uploads. The text typed into an HTTPS request then remains invisible if the inspection does not analyse the content of forms.
3. Copy and paste
Copy a table from an internal document, paste it into an online tool: this is the basic gesture of generative AI, automatic translators and formatting tools. Some endpoint DLP agents control the clipboard, others do not, and many only do so for certain destination applications. The specific case of conversational assistants is covered in Generative AI and data leakage.
4. Browser extensions
A spell-checking, screen capture or note-taking extension can read the content of the pages visited, including internal applications. The data then leaves from the browser process, towards the servers of the extension’s publisher, without any conscious action by the user. It is the most silent path of the four: there is not even a human gesture to detect.
What each control sees (and does not see)
No tool covers these four paths on its own. The table below gives a qualitative reading of the common blind spots. It obviously depends on your products and their configuration: that is precisely what needs to be verified by testing.
| Path | Endpoint DLP | Proxy / web gateway | CASB | Typical blind spot |
|---|---|---|---|---|
| Unapproved application | Partial | Depending on categorisation | If the application is known | Recent or poorly categorised service |
| Web form | Rarely | If TLS inspection and body analysis | Rarely outside sanctioned SaaS | Typed text rather than a file |
| Copy and paste | If clipboard control is enabled | Indirectly, on sending | No | Browser excluded from the rule |
| Extension | Rarely | If the publisher’s domain is filtered | No | Flow sent without user action |
Two points come up often: TLS inspection exclusions (set for performance or privacy reasons) and rules written for files when the data gets out as text. On the first topic, see the blind spots of TLS inspection.
Discovering shadow IT before testing it
You can only test well what you have mapped. Discovery does not need to be perfect, it needs to be sufficient to choose realistic scenarios.
- Proxy and DNS logs: list the most contacted domains outside sanctioned applications, in particular those receiving large upload (POST) volumes.
- Extension inventory: most managed browsers allow you to export the list of installed extensions. Spot those that request access to all pages.
- CASB discovery: if you have a CASB, its discovery module gives a first list of unapproved applications.
- Interviews with business teams: ask the teams which online tools they use “to get by”. You will learn more in an hour than from many reports.
- Expense claims and purchasing cards: subscriptions paid outside IT purchasing often reveal unlisted SaaS applications.
A concrete scenario: the HR department and the online converter
An HR officer needs to send a salary table in PDF format. The installed software does not produce the export she wants. She searches for “convert Excel to PDF”, lands on an online service, uploads the file, retrieves the PDF. Thirty seconds.
What your DLP should have done: recognise a file classified as confidential, identify an unauthorised destination, block or at least alert. What often happens: the converter’s domain is categorised as “online tools”, allowed; the endpoint DLP rule only monitors email and USB; the classification label is not applied to this file. Nobody will know, unless you replay this scenario yourself. The importance of labelling is developed in why DLP depends on data classification.
Next step
Do your controls see the browser paths?
A 30-minute guided demo, on pre-built result sets: the campaign across the 8 channels covered, the report and its detail, nothing to install. The POC then replays one standard scenario with synthetic data, from a representative machine in your network, through your real egress controls. What actually gets out through your egress paths is what the pilot shows you.
Test plan: the browser paths
The principle is that of data exfiltration testing: replay realistic exits with synthetic data, from a representative production workstation, and record what is blocked, alerted on or ignored.
- Prepare realistic decoys: fake social security numbers in the right format, fake IBANs, fake contract extracts, files labelled confidential.
- Upload a decoy file to an unapproved application, then to a sanctioned application but with a personal account.
- Paste a decoy extract into a web form field, with no file attached.
- Copy decoy content from an internal application and paste it into an online tool, in each of the authorised browsers.
- Check the behaviour with and without TLS inspection on the destination, in particular for excluded domains.
- Check what an authorised extension can read on an internal page containing decoys (an inventory of permissions rather than an attempt at circumvention).
- For each scenario, record three distinct results: blocked, alerted (and did the alert reach the SOC?), ignored.
- Replay after every change: new browser version, new rule, new exclusion. A result that was true in January is not necessarily still true in March.
What to do with the findings?
Blocking all shadow IT is illusory, and often counterproductive: usage moves to even less visible tools. The realistic approach is to offer an approved alternative for recurring needs (conversion, translation, transfer), to restrict extensions with an allow list, to extend DLP rules to typed text and the clipboard on browsers, and to prioritise according to the sensitivity of the data actually exposed. A finding on health data is not handled at the same pace as a finding on sales brochures.
Frequently asked questions
Is shadow IT necessarily a data leak?
No. It is a risk, not an incident. It becomes a leak when sensitive data leaves for a destination the company does not control, with no contract and no guarantees on how it is processed.
Should all browser extensions be blocked?
An allow list is more sustainable than a total block. Authorise useful extensions after reviewing their permissions, and refuse by default those that request access to all pages.
Is a CASB enough to cover shadow IT?
It helps a lot for discovery and known applications. It covers generic web forms, copy and paste and extensions poorly. Only a test tells you where its coverage ends in your environment.
Can these paths be tested without exposing real data?
Yes, it is even essential: synthetic data in the right format triggers the same rules as real data, without exposing any real data if it gets out.