Filter Laravel Package

Technical Evaluation

Architecture Fit

• Overlap with Laravel’s Ecosystem: Laravel already provides robust input sanitization via:
  • Blade auto-escaping (XSS protection by default).
  • Illuminate\Validation (built-in sanitization rules like sanitize).
  • e() helper (HTML entity encoding).
  • Third-party packages (e.g., htmlpurifier/htmlpurifier for advanced HTML filtering).
• Joomla-Specific Assumptions: The package assumes Joomla’s architecture (e.g., OutputFilter::stringURLSafe requires Joomla\Language), creating friction in Laravel’s dependency graph.
• Use Case Alignment: Best suited for legacy Joomla migrations or projects requiring Joomla-specific filtering logic. For Laravel, it offers no clear advantage over existing tools unless:
  • You need Joomla’s exact tag/attribute whitelisting (e.g., for migrating Joomla content).
  • You’re building a multi-CMS hybrid app where Joomla’s filtering rules must be replicated.

Integration Feasibility

• Composer Compatibility: ✅ No major conflicts (PHP 8.1+ required for v3.x, 8.3+ for v4.x).
• Laravel Service Provider Integration:
  • Can be wrapped in a custom service provider (e.g., FilterServiceProvider) to expose InputFilter as a singleton or per-request binding.
  • Example:

    $this->app->bind('joomla.filter', function () {
        return new \Joomla\Filter\InputFilter([], [], InputFilter::ONLY_ALLOW_DEFINED_TAGS);
    });
    

• Request Pipeline Hooks:
  • Integrate with Laravel’s middleware (e.g., SanitizeInputMiddleware) to filter $request->input() before validation.
  • Use form requests to apply filtering in handle():

    public function handle()
    {
        $this->merge([
            'cleaned_content' => InputFilter::clean($this->input('content'), 'html'),
        ]);
    }
    

• Validation Rules:
  • Extend Illuminate\Validation\Rules\Rule to encapsulate InputFilter logic:

    class SanitizeHtml implements Rule {
        public function passes($attribute, $value) {
            return InputFilter::clean($value, 'html') !== false;
        }
    }
    

Technical Risk

Key Questions for Stakeholders

1. Why not Laravel’s built-in tools?
   • Does this package provide Joomla-specific filtering rules (e.g., legacy CMS whitelists) that Laravel lacks?
   • Are you migrating Joomla content and need to preserve its sanitization behavior?
2. Security Trade-offs
   • Have you audited the package against OWASP XSS?
   • Is the CVE-2022-23800 fix sufficient, or do you need additional hardening (e.g., CSP headers)?
3. Long-Term Viability
   • Will Joomla’s shift to PHP 8.3+ impact this package’s maintenance? (Risk: Abandonware if Joomla deprioritizes it.)
   • Do you have a fallback plan if the package becomes unmaintained? (e.g., fork or migrate to htmlpurifier?)
4. Integration Complexity
   • Will this require custom middleware, validation rules, or service providers? (Adds dev overhead.)
   • How will you test edge cases (e.g., nested <script> tags, SVG XSS)?

Integration Approach

Stack Fit

public function handle($request, Closure $next) {
    $request->merge([
        'safe_content' => InputFilter::clean($request->input('content'), 'html'),
    ]);
    return $next($request);
}
```                                                                                                      |

| Validation | Custom validation rules (e.g., SanitizeHtml). | php 'content' => ['required', new SanitizeHtml], | | Forms/Requests | Override handle() in FormRequest to sanitize before validation. | php public function rules() { return ['content' => 'required|sanitize_html']; } protected function prepareForValidation() { $this->merge(['content' => InputFilter::clean($this->content, 'html')]); } | | Blade Templates | Use {{ $safeHtml }} (auto-escaped) or @php($filtered = InputFilter::clean($html, 'html')). | blade {!! $filtered !!} <!-- Safe if filtered with ONLY_ALLOW_DEFINED_TAGS --> | | API Responses | Filter data before JSON serialization (e.g., in AppServiceProvider). | php Event::listen('illuminate.query.executed', function ($query) { if ($query->getQuery()->from === 'posts') { $query->selectRaw('InputFilter::clean(body, "html") as safe_body'); } }); | | Database Storage | Use database observers or model events to sanitize before save(). | php protected static function booted() { static::saving(function ($model) { $model->content = InputFilter::clean($model->content, 'html'); }); } |

Migration Path

1. Pilot Phase (Low Risk)

   • Step 1: Install in a non-production environment:

     composer require joomla/filter:^4.0 --dev
     

   • Step 2: Test critical user inputs (e.g., comments, forum posts) with:
     • Known XSS payloads (e.g., <script>alert(1)</script>).
     • Edge cases (e.g., nested <iframe>, SVG vectors).
   • Step 3: Compare output with Laravel’s e() and strip_tags() for regressions.

2. Gradual Rollout (Medium Risk)

   • Phase A: Replace strip_tags() in non-critical paths (e.g., user profiles).
   • Phase B: Integrate into validation rules (e.g., SanitizeHtml).
   • Phase C: Add middleware for global request filtering.

3. Full Adoption (High Risk)

   • Step 1: Fork the package to remove Joomla dependencies (e.g., OutputFilter).
   • Step 2: Extend InputFilter to support Laravel events (e.g., illuminate.events).
   • Step 3: Publish as a custom package (e.g., vendor/laravel-filter) for maintainability.