Seeking Review: Security of SVG Sanitizer

[MathiasReker]

Select Topic Area

Question

Body

Hi everyone,

I’ve been working on improving the sanitizer in php-svg-optimizer and want to make sure it’s secure, especially when handling untrusted SVG input. The sanitizer currently focuses on removing unsafe elements, non-standard tags, and risky attributes, but I’d really appreciate a second set of eyes to verify that nothing is missed that could lead to XSS or other attacks.

If you have experience with SVG security, sanitization, or PHP security best practices, I’d love your feedback. You can review the relevant code here.

Example of how to use it:

<?php

declare(strict_types=1);

require_once __DIR__ . '/vendor/autoload.php';

use MathiasReker\PhpSvgOptimizer\Service\Facade\SvgOptimizerFacade;

try {
    $svgOptimizer = SvgOptimizerFacade::fromFile('path/to/source.svg')
        ->withRules(
            removeNonStandardAttributes: true,
            removeNonStandardTags: true,
            removeUnsafeElements: true,
        )
        ->allowRisky()
        ->optimize()
        ->saveToFile('path/to/output.svg');
} catch (\Exception $exception) {
    echo $exception->getMessage();
}

Any suggestions for improvements, potential pitfalls, or security holes would be extremely valuable.

Link til library: https://github.com/MathiasReker/php-svg-optimizer

Link til rules: https://github.com/MathiasReker/php-svg-optimizer/tree/develop/src/Service/Rule

Thanks in advance!

[midiakiasat]

If this is meant to handle untrusted SVG, the bar is “no executable surface left”. Removing “unsafe” or “non-standard” elements is not sufficient.

Key requirements:

1. Whitelist, not blacklist

   • Explicit allowed tag list (svg, g, path, rect, circle, defs, linearGradient, etc.).
   • Explicit allowed attributes per tag.
   • Drop everything else.
     “Non-standard” ≠ unsafe. Many standard SVG features are executable.

2. Eliminate all script vectors

   • Remove <script>, <foreignObject>, <iframe>, <object>, <embed>.
   • Strip all on* attributes (onload, onclick, etc.).
   • Reject any attribute value starting with javascript:, vbscript:, data:text/html.
   • Validate href / xlink:href strictly.

3. Block external resource loading

   • Disallow remote URLs in <image>, <use>, <feImage>, CSS url().
   • Remove @import in <style>.
   • Ideally drop <style> entirely for untrusted input.
   • No external fonts.

4. Harden XML parsing (critical)

   • Disable DTD.
   • Disable external entity resolution (XXE).
   • No entity expansion.
   • Use libxml with entity loader disabled and network disabled.

5. CSS is an execution surface
   If you allow <style>:

   • Strip expression(), url(javascript:...), @import.
   • Reject unknown properties unless explicitly allowed.
     Otherwise remove <style> entirely.

6. Namespace control

   • Reject unknown namespaces.
   • Reject embedded HTML/MathML.
   • Normalize namespaces before validation.

7. Rebuild, don’t mutate
   Parse to DOM.
   Create a new clean DOM from allowed nodes/attributes only.
   Serialize that.
   Never partially edit raw input.

8. allowRisky() is a red flag
   A sanitizer for untrusted input must not have a “risky” mode. Security must be deterministic and non-optional.