docs: clarify filter matching behavior and point injection blocking to Shield

[davidmytton]

Summary

Adds a Matching behavior section to the Filters reference documenting how filter expressions match request fields, addressing arcjet/arcjet#8614.

• Explains that string comparisons (eq, ne, contains) are literal, case-sensitive byte matches with no normalization, and how to match case-insensitively via lower()/upper() or matches with a (?i) regex flag.
• Documents that http.request.uri.args values are percent-decoded before matching, while http.request.uri.path is matched raw/still-encoded.
• Adds guidance that hand-written filters are not an effective way to block injection-style attacks (SQLi/XSS) since matching is literal, and directs users to Shield as the purpose-built WAF to use alongside filters.

Also updates the page ajToc and the regenerated reference screenshots.

Closes arcjet/arcjet#8614

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
arcjet-docs	Ready	Preview, Comment	Jul 23, 2026 11:18pm

[arcjet-review]

Arcjet Review — 🟢 Low Risk

Decision: Approved

Rationale: This is a documentation-only change clarifying filter matching semantics and directing users toward Shield for injection-style attack detection. No escalation triggers fired, no secrets or executable logic were introduced, and the security guidance generally reduces risk by discouraging brittle hand-written injection filters.

Summary of Changes

Adds a new 'Matching behavior' section to the filters reference explaining literal, case-sensitive matching, decoded versus raw fields, and why Arcjet Shield should be used for SQLi/XSS-style attack detection instead of custom filters.

_{Review: c1c14817 | Model: openai/gpt-5.5 | Powered by Arcjet Review}