flawopen.com/XSS in JavaScript/DOMPurify

Is DOMPurify enough to make innerHTML safe?

Reference page — draft, pending review
Short answer

Yes, when it runs on the untrusted string immediately before assignment and is kept up to date. The risk comes back if sanitization is skipped for any code path, or the library is configured to allow script-bearing tags/attributes.

STILL RISKY
// sanitized once at save time,
// trusted forever after — a gap
saveToDb(DOMPurify.sanitize(input));
// ...later, rendered without re-checking
el.innerHTML = fetchedFromDb;
SAFE
el.innerHTML = DOMPurify.sanitize(
  untrustedHtml
);

Why "sanitize once at input" is a weaker pattern

Sanitizing when data is first saved and trusting it forever afterward misses cases where the sanitizer's rules get updated later, or where a bug elsewhere in the pipeline lets unsanitized data slip through before the save. Sanitizing at render time — immediately before the value reaches innerHTML — means every render benefits from the current, patched version of the sanitizer.

Configuration matters

DOMPurify's default configuration is a reasonable starting point, but a permissive custom configuration (allowing <script>, event-handler attributes, or javascript: URIs) reopens exactly the hole the library exists to close. Stick to the defaults unless you have a specific, reviewed reason to widen them.

References