Filter Laravel Package

Technical Evaluation

Architecture Fit

• Laravel’s Native Alternatives: Laravel’s built-in e() helper, Illuminate\Validation\Rules\Sanitize, and packages like htmlpurifier/htmlpurifier already address HTML sanitization. This package introduces redundancy unless Joomla-specific filtering rules (e.g., OutputFilter::stringURLSafe) are explicitly required.
• Security Focus: The package excels at XSS mitigation (e.g., stripping javascript:, data: URIs, and evasion characters) but lacks Laravel-native features like request validation pipelines or middleware integration.
• Joomla Dependency: Optional Joomla\Language dependency for stringURLSafe creates unnecessary coupling for Laravel apps not using Joomla components.
• Key Strengths:
  • Configurable tag/attribute whitelisting/blacklisting (e.g., allow <b>, <i> but block <script>).
  • Lightweight (~50KB) with no heavy dependencies (unlike HTMLPurifier).
  • Battle-tested in Joomla (though PHP-centric).

Technical Risk

• Low Stars/Dependents (15 stars, 0 dependents): Signals low adoption and potential stagnation risk. Last release (2026-05-26) suggests active but niche maintenance.
• PHP Version Lock-in:
  • v3.x requires PHP 8.1+ (blocks legacy Laravel apps).
  • v4.x requires PHP 8.3+ (may limit compatibility).
• Breaking Changes: v4.0.0+ drops support for older PHP versions; v3.x has renamed constants (e.g., TAGS_WHITELIST → ONLY_ALLOW_DEFINED_TAGS).
• Security History: CVE-2022-23800 (fixed in v1.4.4/v2.0.1) indicates past vulnerabilities; no recent CVEs suggest improved rigor.
• Testing Gaps: No Laravel-specific tests; integration risks include:
  • Conflicts with Laravel’s auto-escaping (Blade, e()).
  • Performance overhead in high-traffic APIs (not benchmarked).

Key Questions for TPM

1. Why Not Laravel Native?
   • Does the team need Joomla-specific filtering rules (e.g., stringURLSafe)?
   • Are there legacy Joomla components requiring this package?
   • Is the configurable whitelisting more flexible than htmlpurifier/htmlpurifier?
2. Maintenance Strategy
   • How will the team monitor updates (e.g., PHP 8.3+ requirement in v4.x)?
   • What’s the fallback plan if the package stagnates (e.g., fork or migrate to HTMLPurifier)?
3. Performance Impact
   • Will this be used in high-throughput endpoints (e.g., API rate-limited inputs)?
   • Has the package been benchmark-tested against Laravel’s e() or strip_tags()?
4. Security Tradeoffs
   • Does the package cover all OWASP XSS vectors (e.g., SVG, CSS injection)?
   • How will it integrate with Laravel’s CSRF protection and CORS policies?
5. Dependency Risks
   • Will the optional Joomla\Language package introduce bloat or conflicts?
   • Are there hidden dependencies (e.g., PHP extensions like mbstring)?

Integration Approach

Stack Fit

• Laravel Compatibility:
  • Pros: Composer-friendly, PHP 8.1+ aligned with Laravel 9+/10+.
  • Cons: No Laravel-specific middleware or validation rules; requires manual wrapping.
• Recommended Integration Points:
  1. Form Request Validation:

     use Joomla\Filter\InputFilter;
     use Illuminate\Validation\Rule;
     
     public function rules()
     {
         return [
             'comment' => [
                 'required',
                 Rule::custom(function ($attribute, $value, $fail) {
                     $filter = new InputFilter();
                     $filtered = $filter->clean($value, InputFilter::ONLY_ALLOW_DEFINED_TAGS, ['p', 'b', 'i']);
                     // Compare or return filtered value
                 }),
             ],
         ];
     }
     

  2. Middleware for Global Filtering:

     namespace App\Http\Middleware;
     
     use Joomla\Filter\InputFilter;
     use Closure;
     
     class SanitizeInput
     {
         public function handle($request, Closure $next)
         {
             $filter = new InputFilter();
             $request->merge([
                 'input_field' => $filter->clean($request->input_field, InputFilter::ONLY_ALLOW_DEFINED_TAGS, ['a']),
             ]);
             return $next($request);
         }
     }
     

  3. Service Provider for Reusability:

     $this->app->singleton(InputFilter::class, function ($app) {
         return new InputFilter();
     });
     

• Alternative Approaches:
  • Wrapper Package: Publish a Laravel-specific facade (e.g., laravel-joomla-filter) to abstract Joomla dependencies.
  • Hybrid Solution: Use this package for Joomla-specific rules and Laravel’s e() for general escaping.

Migration Path

1. Assessment Phase:
   • Audit all HTML input sources (e.g., forms, APIs, CMS plugins).
   • Identify critical XSS risks (e.g., user avatars, rich-text fields).
2. Pilot Integration:
   • Start with non-critical endpoints (e.g., contact forms).
   • Compare output with Laravel’s e() and strip_tags().
3. Gradual Rollout:
   • Replace strip_tags() calls with InputFilter where configurable whitelisting is needed.
   • Phase out custom regex-based sanitization.
4. Fallback Plan:
   • If performance or maintenance becomes an issue, migrate to htmlpurifier/htmlpurifier or Laravel’s native tools.

Compatibility

• PHP Version: Target v3.x for PHP 8.1+ (Laravel 9+) or v4.x for PHP 8.3+ (Laravel 10+).
• Laravel Version:
  • Test with Laravel 9/10 (PHP 8.1/8.2) for v3.x.
  • Laravel 11 (PHP 8.3+) for v4.x.
• Dependency Conflicts:
  • Check for conflicts with joomla/language if stringURLSafe is used.
  • Avoid mixing with htmlpurifier/htmlpurifier (duplicate sanitization).

Sequencing

1. Phase 1: Add package via Composer (~3.0 for stability).
2. Phase 2: Create a custom facade to hide Joomla-specific classes.
3. Phase 3: Integrate into Form Requests for critical inputs.
4. Phase 4: Add middleware for global filtering (if needed).
5. Phase 5: Deprecate custom sanitization logic.

Operational Impact

Maintenance

• Update Strategy:
  • Pin to a specific minor version (e.g., 3.0.6) to avoid breaking changes.
  • Monitor Joomla Framework releases for security patches (e.g., CVE fixes).
• Dependency Management:
  • Use composer why-not joomla/filter to check for conflicts.
  • Consider a custom fork if the package stagnates (low risk due to simple codebase).
• Documentation:
  • Maintain a runbook for:
    • Upgrading between major versions (e.g., v3 → v4).
    • Handling Joomla\Language dependency warnings.

Support

• Issue Tracking:
  • Open GitHub Issues for Laravel-specific bugs (e.g., middleware integration).
  • Engage with Joomla Framework maintainers for core filtering logic.
• Fallback Support:
  • Document workarounds for unsupported PHP versions (e.g., use strip_tags as a fallback).
  • Train devs to test with OWASP XSS payloads (e.g., "><script>).

Scaling

• Performance:
  • Benchmark against Laravel’s e() and strip_tags() for high-traffic endpoints.
  • Cache InputFilter instances in service containers (Laravel’s DI).
• Load Testing:
  • Test with 10K+ requests/sec to identify bottlenecks (e.g., regex-heavy methods).
  • Consider asynchronous filtering for non-critical paths (e.g., background jobs).
• Horizontal Scaling:
  • No known stateful dependencies; scales horizontally like Laravel.

Failure Modes

| **Failure Scenario