SecurityInputFilter is the request-level input guard for high-confidence XSS detection. It inspects GET and POST values before controller logic runs, canonicalizes user input to reduce encoding bypasses, and blocks the request when a known dangerous pattern is detected.

Overview

Where it runs

The filter is globally registered in app/Config/Filters.php in the before chain, which means it runs for normal incoming web requests unless the route is explicitly excluded.

'SecurityInputFilter' => SecurityInputFilter::class,

'before' => [
    'SecurityInputFilter' => [
        'except' => [
            '/client/notification/create',
            '/ticket/crud_mail_template/*',
            'test_mail',
            'leads/sendMail',
            'ticket/reply'
        ]
    ],
]

The filter only reads:

• $request->getGet()
• $request->getPost()

It does not inspect uploaded file contents. File uploads are handled by the separate GlobalPostFileUploadGuard filter.

What it checks

The filter uses a focused list of high-confidence XSS patterns to reduce false positives while still blocking obvious injection attempts.

Canonicalization

Before pattern matching, the filter canonicalizes each value:

1. URL decode

   Helps catch encoded payloads that would otherwise bypass naive matching.

2. HTML entity decode

   Turns entity-encoded payloads into their real characters before detection.

3. Strip invisible control characters

   Removes null bytes and other control characters from the evaluation string.

4. Trim the final value

   Reduces noise before regex evaluation.

private function canonicalize(string $value): string
{
    $value = urldecode($value);
    $value = html_entity_decode($value, ENT_QUOTES | ENT_HTML5, 'UTF-8');

    return preg_replace('/[\x00-\x1F\x7F]/u', '', $value);
}

Array inputs are converted to JSON first, then canonicalized as a string.

Block behavior

When a pattern matches, the filter logs security metadata and immediately returns a JSON 403 response:

The raw input value is not logged directly. The filter logs intent metadata and a hash instead.

{
  "status": 403,
  "error": "Forbidden",
  "message": "Malicious input detected"
}

Filter exceptions

Some routes are explicitly excluded from the global security-input filter:

Developer steps

When building a new form, endpoint, or feature that accepts user input, follow this checklist:

1. Assume GET and POST are inspected automatically

   If your route is not in the exception list, the filter already evaluates GET and POST fields before controller code runs.

2. Do not rely on this filter as your only validation

   Business validation, field-level validation, and output escaping are still required.

3. Be careful with HTML-capable inputs

   If a feature legitimately accepts formatted HTML, do not silently fight the filter. Design a safe path for that route and document why it needs special handling.

4. Only add filter exceptions deliberately

   If you exclude a route in Filters.php, add compensating server-side sanitization or allowlist logic in the receiving code.

5. Test encoded attack strings too

   Because the filter canonicalizes input, test URL-encoded and HTML-entity-encoded payloads in addition to plain strings.

6. Watch the logs when troubleshooting blocks

   The filter logs a structured critical event named SECURITY_BLOCKED_REQUEST with a payload hash and field name.

Common pitfalls