Dom Sanitizer Laravel Package

Technical Evaluation

Architecture Fit

• Laravel/PHP Integration: Seamlessly integrates with Laravel’s dependency injection and service container. Can be registered as a singleton or bound to interfaces for modular use.
• DOM-Based Sanitization: Leverages PHP’s native DOMDocument for parsing and validation, ensuring compatibility with Laravel’s existing DOM manipulation tools (e.g., str_get_html, DOMDocument extensions).
• Security-First Design: Hardened against XXE, CSS injection, and entity-based bypasses, aligning with Laravel’s security best practices (e.g., Blade escaping, htmlspecialchars).
• Extensibility: Customizable allowlists for tags/attributes enable fine-grained control, useful for Laravel’s dynamic content systems (e.g., CMS plugins, user-generated widgets).

Integration Feasibility

• Low Friction: Composer-based installation with zero Laravel-specific configuration required. Can be instantiated anywhere in the stack (controllers, services, middleware).
• Middleware Potential: Ideal for sanitizing incoming requests (e.g., FormRequest, API payloads) or outgoing responses (e.g., SVG/XML exports).
• Service Provider Pattern: Can be wrapped in a Laravel service provider to centralize configuration (e.g., default allowlists for HTML/SVG/MathML).
• Event Hooks: Can be triggered via Laravel events (e.g., illuminate.queue.working, illuminate.auth.attempting) for pre/post-processing.

Technical Risk

• False Positives/Negatives: Risk of over-sanitization (e.g., stripping valid SVG entities like &) or under-sanitization (e.g., missing edge-case XSS vectors). Mitigate via:
  • Testing: Unit tests for custom allowlists (e.g., phpunit assertions on sanitized output).
  • Canary Releases: Gradual rollout to monitor for broken SVGs/XML.
• Performance: DOM parsing may introduce latency for high-volume XML/HTML. Benchmark with:
  • Laravel Queues: Offload sanitization to background jobs for large payloads.
  • Caching: Cache sanitized outputs if inputs are repetitive (e.g., static SVGs).
• PHP Version Lock: Requires PHP 7.3+, but Laravel’s minimum version (8.0+) is compatible. No risk for modern stacks.
• Dependency Conflicts: No known conflicts with Laravel’s core or popular packages (e.g., spatie/laravel-html, laravelcollective/html).

Key Questions

1. Scope of Sanitization:
   • Where in the Laravel stack will this be applied? (e.g., API requests, Blade templates, file uploads, database storage).
   • Are there legacy systems using custom XML parsers (e.g., simplexml_load_string) that need migration?
2. Customization Needs:
   • Do we need to extend the allowlists for specific SVG/MathML features (e.g., custom entities, namespaces)?
   • Should we whitelist/blacklist additional tags/attributes beyond defaults?
3. Error Handling:
   • How should malformed XML/HTML be handled? (e.g., return empty string, throw exception, log and retry).
   • Will we need to customize error messages for user-facing scenarios (e.g., "Invalid SVG uploaded")?
4. Performance:
   • What is the expected volume of XML/HTML/SVG to be sanitized? (e.g., 100s vs. 100,000s of requests/day).
   • Are there bottlenecks in current sanitization (e.g., regex, custom logic) that this could replace?
5. Compliance:
   • Are there industry-specific requirements (e.g., HIPAA, PCI-DSS) for XML sanitization that this must address?
   • Do we need audit logs for sanitization actions (e.g., "Blocked <script> tag in user upload")?
6. Testing:
   • What test coverage is required for custom allowlists? (e.g., fuzz testing for XXE bypasses).
   • Should we mock the sanitizer in unit tests for critical paths (e.g., payment processing)?

Integration Approach

Stack Fit

• Laravel Ecosystem:
  • Controllers/Middleware: Sanitize incoming requests (e.g., FormRequest::sanitize()).
  • Services: Encapsulate sanitization logic in a dedicated service (e.g., XmlSanitizerService).
  • Blade Directives: Create a custom Blade directive (e.g., @sanitize) for templating.
  • Artisan Commands: Pre-sanitize XML/HTML assets during deployment.
• PHP Extensions:
  • DOM Extensions: Ensure php-dom and php-xml are enabled (Laravel’s default).
  • LibXML: Verify libxml_disable_entity_loader() is supported (PHP 7.3+).
• Database:
  • Sanitize XML/HTML fields before storage (e.g., beforeSave Eloquent observer).
  • Use Laravel’s Attribute Casting to auto-sanitize on retrieval.

Migration Path

1. Assessment Phase:
   • Audit all XML/HTML/SVG processing points (e.g., file uploads, API endpoints, Blade templates).
   • Identify custom sanitization logic (e.g., regex, strip_tags) that can be replaced.
2. Pilot Phase:
   • Replace one high-risk component (e.g., SVG upload handler) with DOMSanitizer.
   • Test with real-world inputs (e.g., complex SVGs, malformed XML).
3. Gradual Rollout:
   • Phase 1: Core sanitization (e.g., user uploads, API payloads).
   • Phase 2: Dynamic content (e.g., CMS widgets, Blade templates).
   • Phase 3: Legacy systems (e.g., custom XML parsers).
4. Deprecation:
   • Phase out custom sanitization logic via deprecation warnings in logs.
   • Use Laravel’s Deprecates trait for custom methods.

Compatibility

• Laravel Versions: Compatible with Laravel 8.0+ (PHP 7.3+ requirement).
• Package Conflicts: No known conflicts with:
  • spatie/laravel-html (use DOMSanitizer for XML/SVG, spatie for HTML).
  • laravelcollective/html (sanitize separately if both are needed).
  • dompdf/dompdf (sanitize inputs before PDF generation).
• Third-Party Integrations:
  • SVG Libraries: Works with svg/svgo, intervention/image (for SVG thumbnails).
  • API Clients: Sanitize XML responses from external services (e.g., SOAP APIs).

Sequencing

1. Core Integration:
   • Register the sanitizer as a Laravel service provider:

     // app/Providers/AppServiceProvider.php
     public function register()
     {
         $this->app->singleton(DOMSanitizer::class, function () {
             return new DOMSanitizer(DOMSanitizer::HTML);
         });
     }
     

2. Middleware:
   • Create middleware to sanitize incoming requests:

     // app/Http/Middleware/SanitizeXml.php
     public function handle($request, Closure $next)
     {
         if ($request->has('xml_content')) {
             $request->merge([
                 'sanitized_xml' => app(DOMSanitizer::class)->sanitize($request->xml_content)
             ]);
         }
         return $next($request);
     }
     

3. Service Layer:
   • Wrap sanitization in a service for reusability:

     // app/Services/XmlSanitizerService.php
     public function sanitizeHtml(string $input): string
     {
         return app(DOMSanitizer::class)->sanitize($input, [
             'remove-html-tags' => false,
         ]);
     }
     

4. Testing:
   • Add PHPUnit tests for sanitization edge cases:

     public function testSanitizesXxe()
     {
         $input = '<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]><svg><use>&xxe;</use></svg>';
         $output = $this->sanitizer->sanitize($input);
         $this->assertNotContains('xxe', $output);
     }
     

5. Monitoring:
   • Log sanitization events (e.g., blocked tags) using Laravel’s logging:

     \Log::debug('Sanitized XML', ['input' => $input, 'output' => $output]);
     

Operational Impact

Maintenance

• Updates: Monitor for security patches (e.g., new XXE vectors) via GitHub releases. Laravel’s composer update will handle upgrades.
• Custom Rules: Maintain a centralized config file (e.g., config/sanitizer.php) for allowlists to avoid duplication: