This project enumerates all the ways a document can cause a browser (or a mail client, a proxy, a
server-side DOM) to send an HTTP request, in one single HTML file:
leak.html (raw).
Every entry points at https://leaking.via/<element>-<attribute>, so when a request shows up you can
read off exactly which construct fired it from the path alone. The domain is not real; the file is a
corpus, not a beacon.
With "HTTP leak" we mean a situation where some combination of markup, CSS, SVG or MathML causes a request to an external resource when it should not. Think of the body of an HTML mail, where a leak tells someone that you just opened it. Not always bad, almost never good.
Typical uses:
- HTML sanitizers and filters. Feed the file through and see what still fires. Sanitizers that
strip
<script>andon*and call it a day tend to miss half of this file. - Web-mailers and reader modes. These render untrusted HTML without scripting, which is exactly
where
<noscript>, conditional comments and CSS-only leaks matter. - Web proxies and "anonymizers". A proxy that rewrites
srcandhrefbut notsrcset,ping,@importorimage-set()has no anonymity to offer. - CSP and browser testing. Check which of these your policy actually blocks, and which requests leave the browser process without ever appearing in devtools.
Nobody really knows anymore which elements and attributes can request external resources, which is why this project exists: to keep track.
The file is organised in %Section comment blocks, roughly in document order: <head> metadata,
<link> relations, images, forms, media, <object>/<embed>, script and speculation rules, frames,
Declarative Shadow DOM, <noscript>, <model>, CSS (stylesheet, inline, exotic), SVG, XSLT, MSIE data
islands, VML, MathML, and finally a block of URL spellings that sanitizers tend to misclassify.
Three kinds of entries live side by side, and the comments say which is which:
- Live leaks in current engines. The bulk of the file.
- Legacy leaks that only fire in engines that are gone from the desktop (IE, old Firefox, the
Flash and Java plugin era) but live on in mail clients and embedded webviews. Outlook still renders
VML and
[if mso]blocks. These stay in on purpose: the corpus is more useful complete. - Probes that are expected not to fire and are there as regression inputs, for example the
attr()URL restriction in CSS Values 5. Their comments say "expected: no request".
A few entries need user interaction (ping, formaction, MathML href, longdesc); the visible
text says "click me" or "hover me" where that is the case.
- Serve
leak.htmlover HTTPS from an origin that is notleaking.via. Opening it from disk changes the rules for several loaders (mixed content,file:origin, CSP<meta>handling). - Watch the network at the DNS or wildcard-listener level, not only in devtools. Several requests are made by the browser process (OpenSearch), after the page is idle (compression dictionaries), or by a prefetch/prerender pipeline, and do not all show in the Network panel.
- Run it more than once: with scripting on and off (the
<noscript>block only fires with scripting off), in each engine you care about, and in the actual client you are protecting (Outlook, a webmail sandbox, your proxy). Browser results do not transfer to mail clients and vice versa. - Later CSS declarations of the same property win, so where the file lists several
url()variants on one selector you will only see the last one fire. Split them up if you need each individually.
Pull requests with new leaks are very welcome. Please:
- Use the naming scheme:
https://leaking.via/<element>-<attribute>(or<context>-<property>for CSS), unique per entry. - Put it under the matching
%Section, or add a new one with a%comment. - Say in a comment where it fires (engine and version, or client) and whether interaction is needed. If it is a probe that should not fire, say that too.
- Do not remove legacy entries. Annotate them instead.
Ideas for other presentations of this data (JSON, per-engine tables, a scripted runner) are also welcome; the single file is the source of truth.
- DOMPurify sanitizes HTML, SVG and MathML; its hooks-proxy-demo shows how to route or drop resource-loading attributes with a hook, and the threat model explains why stopping HTTP leaks is explicitly a non-goal of a sanitizer.
- DOMFortify retrofits Trusted Types sanitization onto legacy pages; this file is a good input for testing what a sanitizer-backed policy still lets through.
Thanks @masatokinugawa, @hasegawayosuke, @masa141421356, @mramydnei, @avlidienbrunn, @orenhafif, @freddyb, @tehjh, @webtonull, @mikewest, @hackvertor, @shhnjk, @parrot409, @mtrzos, @johannburkard, @xem, @emersion, @DaKnOb, @rohansgit, @intchloe, @Boldewyn and many others for adding content and smaller fixes here and there!