SVG XSS Lab: Slip Script Past a Tag-Stripping Sanitiser

This article examines a critical vulnerability in web applications that accept user-uploaded SVG files: naive sanitizers that only strip tags fail to prevent XSS attacks because SVG is XML with numerous alternative execution paths. The ProfilePics lab demonstrates how event-handler attributes embedded in SVG elements bypass tag-stripping sanitizers and execute JavaScript when the image loads, illustrating why blocklist-based sanitization fundamentally cannot secure rich formats.

• SVG is executable XML, not inert imagesSVG files render as live XML documents in the browser with support for event-handler attributes and other constructs that execute JavaScript. This means an inline SVG is an active document capable of running code, not a passive picture file. Unlike flat image formats, any SVG rendered inline becomes a potential attack surface for script execution.
• Event handlers bypass tag-strip sanitizersThe ProfilePics sanitizer removes tags but leaves all other content intact, including SVG element attributes. An attacker creates an SVG with an event-handler attribute (such as onload) that calls a JavaScript function. When the browser renders the SVG inline, the handler fires automatically without requiring a script tag, completely bypassing the sanitizer's single-pattern blocklist.
• Blocklist sanitizers cannot enumerate all threatsSVG has too many execution paths to feasibly list and block them all. A sanitizer that targets only one pattern (script tags) assumes that pattern covers the entire threat, but SVG supports multiple execution sinks beyond script tags. This fundamental flaw means blocklist approaches always leave some attack vector unaddressed in rich formats.
• Real-world prevalence in user-submitted contentSVG-based XSS recurs wherever user images render inline, including avatars, logos, and document thumbnails. Regex or tag-stripping sanitizers are repeatedly bypassed in production because developers underestimate the format's complexity. XSS through injection is categorized under A03 in the OWASP Top 10 (2021).
• Allowlist sanitizers with dedicated librariesThe recommended defense is to use a hardened, allowlist-based SVG sanitizer such as DOMPurify configured for SVG, rather than implementing custom tag-stripping logic. These libraries explicitly permit only known-safe elements and attributes, inverting the blocklist logic to deny everything except what is explicitly approved.
• Separate origin with attachment deliveryAn alternative mitigation is to serve user uploads from a separate origin with the HTTP header Content-Disposition: attachment, which causes the browser to download the file instead of rendering it inline. This eliminates the attack surface by preventing the SVG from executing in the context of the application page.
• Content-Security-Policy as a backstop controlA strict Content-Security-Policy can limit what injected script is capable of doing, providing defense in depth. However, CSP alone is not sufficient; it must be combined with proper sanitization or inert serving methods rather than used as the sole control.
• Rasterization eliminates active contentWhen the application only needs a picture and not an interactive graphic, converting uploads to rasterized PNG format drops all active content, making the file inert regardless of the original SVG structure. This removes the execution threat entirely by changing the file format.

Bottom line: Do not attempt to sanitize rich formats like SVG with custom tag-stripping logic; instead use dedicated allowlist-based libraries, serve uploads as attachments from a separate origin, or rasterize them to inert formats. Blocklist sanitizers inherently fail against formats with multiple execution paths because they can never enumerate all possible attack vectors.