DOMFortify: loading... library: fortify.js DOMPurify: loading... backend: -

DOMFortify

This page runs the real fortify.js the way a site would: a CSP turns Trusted Types on, the library claims the realm's default policy, and the deliberately-vulnerable code below is sanitized by the browser - unchanged.

npm License gzip size Build & Test CodeQL OpenSSF Scorecard Socket
The vulnerability (never touched) 
// Search the source for: THE VULNERABILITY
function renderInnerHTML(value) {
  out.innerHTML = value;   // raw XSS sink, no sanitizer call
}
The fix (all of DOMFortify) 
// Search the source for: THE FIX

Dirty input (what the vulnerable code receives)

0 chars

What landed in the DOM (after the library)

0 chars
Timing-
Removed / refused-
XSS statusnone yet

Live DOM (this document - DOMFortify protected)

innerHTML / insertAdjacentHTML target

The real top-level document. Enforcement is on and the library is installed, so every write here goes through the sanitizer first - the whole point.

Child frame - a separate realm, DOMFortify installed into it too

probed on first write

DOMFortify guards only the realm it loads in, so a bare child frame is unprotected. Under an enforcing parent (common on a hardened site) an unprotected frame makes document.write throw - it wants a trusted value and finds no policy. The fix is the per-realm rule itself: install DOMFortify in the frame too, which the demo does here - so the write is sanitized by the frame's own policy.

Environment (from DOMFortify.status())
checking...
Last run
Run a sink to see how it's handled.
Removed elements / attributes (diff, inspection only)
Run an HTML sink to inspect what was stripped.
DOMFortify events (the onViolation log - your report-only on-ramp)
no events yet

Demo for fortify.js. The removed-elements diff is for inspection, not a security signal. Inspired by Frederik Braun's "Perfect types with setHTML()", building on Jun Kokatsu's "Perfect Types".