devActivitydevActivity Logo

Securing SVG Sanitizers: A Deep Dive into Untrusted Input & Software Engineering Reports

In the world of web development, handling user-generated content, especially complex formats like SVG, presents significant security challenges. A recent GitHub discussion on the security of php-svg-optimizer, initiated by MathiasReker, brought to light critical considerations for developers aiming to create robust sanitizers. This community insight delves into the expert advice shared, offering a comprehensive guide to securing SVG processing against untrusted input, crucial for any software engineering reports on secure development practices.

Developer working on secure code with a shield protecting the system.
Developer working on secure code with a shield protecting the system.

The Challenge: Securing Untrusted SVG Input

MathiasReker sought community review for his PHP SVG sanitizer, designed to optimize and secure SVG files. His primary concern was ensuring the sanitizer could safely handle untrusted SVG input, preventing vulnerabilities like Cross-Site Scripting (XSS) and other potential attacks. The sanitizer focused on removing unsafe elements, non-standard tags, and risky attributes. He shared an example of its usage:

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

While a good starting point, the community quickly pointed out that a more rigorous approach is necessary when dealing with truly untrusted data.

Data being filtered through a whitelist, showing only safe elements passing through.
Data being filtered through a whitelist, showing only safe elements passing through.

Expert Recommendations for Bulletproof SVG Sanitization

The most comprehensive feedback came from midiakiasat, who outlined a set of stringent requirements, emphasizing that for untrusted SVG, the goal must be "no executable surface left." These recommendations are vital for any software engineering reports on application security:

1. Whitelist, Not Blacklist

  • Explicitly define allowed tags: Instead of removing "unsafe" elements, maintain a strict list of allowed tags (e.g., svg, g, path, rect, circle, defs, linearGradient). Drop everything else.
  • Attribute-per-tag whitelisting: For each allowed tag, explicitly list its permitted attributes. Many standard SVG features can be exploited.

2. Eliminate All Script Vectors

  • Remove script-related tags: Strip