Svg Sanitize Laravel Package

Product Decisions This Supports

• Feature feasibility: "Can we let users upload SVGs?" This package converts a hard "no" (SVG is XML, can carry <script>, onload, external xlink:href fetches) into a scoped "yes, with a server-side gate." That unblocks logos, avatars, icons, badges, and diagram exports in Laravel apps where raster-only uploads were previously the safe default.
• Build vs. buy. An SVG allowlist sanitizer is deceptively deep work (attribute casing, xlink namespaces, <use>/<foreignObject> abuse, entity expansion, quadratic parse times on element-dense files). Adopting a library that has absorbed those fixes — including the 1.0.0 performance and href/xlink:href correctness patches — is cheaper than a homegrown regex/DOM filter that will silently under-sanitize.
• Roadmap sequencing. The integration is one Composer package plus a validation rule or middleware, so it can be scheduled inside an existing upload-hardening epic rather than as a standalone initiative. It also fits a broader "untrusted file intake" workstream alongside image re-encoding and MIME sniffing.
• Security and compliance posture. SVG XSS is a recognized injection class; having a documented, tested sanitization step in the upload path is concrete evidence for security questionnaires, OWASP-aligned reviews, and penetration-test remediation items. getXmlIssues() gives you auditable rejection reasons rather than opaque failures.
• Licensing as a product decision, not a footnote. GPL-2.0 is the single biggest PM-level constraint here. For a distributed proprietary Laravel product this is a legal gate that can reshape the plan (isolate the sanitizer behind a service boundary, or pick a permissive alternative). For GPL-compatible or internal-only deployments, it is a non-issue.
• Scoping what this does not buy you. Sanitization ≠ renderability ≠ image processing. A "clean" SVG can still render blank; conversion to PNG or raster fallbacks remains a separate decision (Intervention Image, ImageMagick, rsvg-convert) and a separate line item.
• Prior-art confidence signal. Default SVG sanitizer in TYPO3 core since v9, backing the WordPress Safe SVG plugin, plus a Drupal module — three independent CMS ecosystems betting their upload security on it. That is unusually strong validation for a 553-star package and is the strongest argument in any build-vs-buy memo.

When to Consider This Package

Adopt when:

• Your stack is PHP 7.2+ (Laravel fits cleanly) with ext-dom/ext-libxml available — no framework coupling, no service dependency, no vendor lock-in beyond Composer.
• You accept user-submitted SVGs anywhere in the product and want them sanitized before Storage::put(), not filtered at render time.
• You need a small, auditable API surface: sanitize(), setAllowedTags()/setAllowedAttrs(), removeRemoteReferences(true), minify(true), getXmlIssues().
• You can live with community-only support and are willing to own critical fixes internally.
• Your license model tolerates GPL-2.0, or you can architecturally isolate the dependency.

Look elsewhere when:

• GPL-2.0 is incompatible with your distribution model and isolation is impractical. This is a hard stop, not a risk to weigh — evaluate permissively licensed alternatives or client-side DOMPurify for the browser-facing path.
• Your sanitization surface is not PHP (Node/edge functions, SPA uploads) — DOMPurify is the reference implementation this package borrows from and is the better fit there.
• You need more than sanitization: rendering, rasterization, SVG editing, icon sprite compilation, or font subsetting. Pair this with a converter; don't expect it to grow into that.
• You need throughput guarantees. Sanitization is CPU-bound; blocking at >~50 SVGs/sec without a queue or cache is a design smell, and this library will not solve it for you.
• You require enterprise support, an SLA, or evidence of an active maintenance cadence. Release metadata here looks anomalous and community activity is thin — plan for the possibility that you are the maintainer of last resort.
• You want schema-level guarantees. Malformed XML returns false with no repair; if your users routinely upload broken exports from design tools, budget for a pre-parse validation and a user-facing rejection message.

How to Pitch It (Stakeholders)

To executives: "SVG uploads are a known XSS vector — a single malicious logo can execute script in an admin's session. This library is the sanitizer already shipping inside TYPO3's core and powering the WordPress Safe SVG plugin, so we're adopting a control three other CMS ecosystems already trust rather than inventing one. Cost is a Composer dependency and roughly a day of engineering; the alternative is a bespoke security filter we'd have to maintain and get audited. One caveat needs a decision from legal: the license is GPL-2.0, which affects how we ship it in a closed-source product."

To engineering: "One composer require, one singleton binding, one sanitize call in the upload pipeline before persistence. Wrap it in a custom validation rule or middleware, reuse the instance, enable removeRemoteReferences(true) to block outbound fetches and minify(true) in production, and always log getXmlIssues() on a false return — silent failures are the main operational trap. Add mixed-case xlink:Href and malformed-XML fixtures to the test suite, and push high-volume paths onto a queue."

To legal/compliance: "GPL-2.0 dependency, invoked as a library in our upload path. We need a determination on derivative-work exposure for our distribution model before this ships, with two fallbacks prepared: isolate sanitization behind a service boundary, or substitute a permissively licensed sanitizer. The security benefit is real, but we should not commit the roadmap to it before this is settled."