Anti Xss Laravel Package

Getting Started

Install via composer require voku/anti-xss. Instantiate the class once (e.g., in a service provider or as a singleton) and use xss_clean() on untrusted strings just before output, especially when rendering raw HTML (e.g., from rich text editors or user comments). For quick validation in Blade:

{!! $antiXss->xss_clean($comment->body) !!}

⚠️ Do not use this in place of Blade’s auto-escaping ({{ $var }}). Reserve it for known-safe contexts where HTML is expected but must be sanitized.

Implementation Patterns

• Output-Time Sanitization: Sanitize before rendering, not before storage. Store raw HTML (e.g., from a WYSIWYG editor), then clean on output to preserve format integrity.
• Context-Aware Usage: Pass optional context flags:

  $antiXss->xss_clean($input, $isAttribute = true); // For src="" / href=""  
  $antiXss->xss_clean($input, $isScript = true);    // For inline JS  
  

• Laravel Helper/Blade Directive: Create a safe wrapper to avoid coupling views to the class:

  // In AppServiceProvider  
  Blade::directive('antiXss', fn ($expr) => "<?php echo \\voku\\helper\\AntiXSS::xss_clean($expr); ?>";  
  

  Then use: @antiXss($html)
• Middleware Only for Debugging: Avoid global request sanitization—use middleware sparingly (e.g., in dev) to log sanitized inputs, not for production data integrity.

Gotchas and Tips

• Encoding Snowball Effect: Double-encoding (e.g., & → &) is common. Test with ©,  , and emoji—sanitize after decoding if necessary.
• Over-Sanitization Risks: xss_clean() may strip legitimate content (e.g., < in math expressions becomes <). Validate output manually for edge-case content types.
• Not for Non-HTML Contexts: Avoid using it to sanitize JSON, XML, or plain-text DB fields—it’s designed only for HTML/JS/CSS output.
• Complementary Tools: For WYSIWYG content, pair with HTMLPurifier (via htmlpurifier/laravel-html-purifier) for tag/attr whitelisting, while voku/anti-xss handles protocol/attribute neutralization (e.g., javascript:).
• No Configuration File: Tuning requires patching the library (via fork/PR). Prefer defaults unless critical—test custom rules exhaustively to avoid security regressions.