What an AST adds
A syntax tree connects operators to their operands. It can expose a constant comparison, a query union or nested expressions, rather than treating each token as unrelated text.
WHY SEMANTIC SCAN
Look beyond
the keywords.
Understand
the structure.
An attack can change its spelling without changing what it does. Semantic scanning looks at the relationships inside input to find evidence that a keyword alone cannot explain.
From first principles to implementation details.
FROM TEXT TO STRUCTURE
WHERE id = 7 OR 1 = 1 OR
id = 7
Normal filter1 = 1
Always trueSTRUCTURAL EVIDENCE
One true branch can make the whole condition true.
01 / THE IDEA
The words are only part of the story.
Think of a sentence. Recognizing individual words is useful; understanding how they fit together tells you much more. A scanner can apply a similar principle to a computer language: identify its operators, expressions and potentially dangerous combinations.
The word select in a customer message is not enough to establish SQL injection. A condition that changes the logic of a query is stronger evidence. Even then, the WAF cannot know whether the backend will execute that input or safely store it as text.
EXPLORE AN EXAMPLEILLUSTRATIVE
INPUT
SELECT name FROM products WHERE id = 7 OR 1 = 1SELECT … FROMWHEREid = 7OR1 = 1
A query with an always-true condition
The OR connects a normal filter to a constant comparison. If executed as SQL, the condition can broaden the result set.
The relationship between operators and values explains the risk.These preset explanations run only in your browser. They do not submit traffic, execute SQL, or predict an actual WAF verdict. A simplistic keyword filter is the comparison here; real CRS is more sophisticated.
02 / INSIDE THE SCANNER
From a request to explainable evidence.
“Semantic” is a family of analysis techniques. WAFio uses deterministic, language-specific engines. It does not send requests to an LLM to guess a user's intent, and it does not use a complete AST parser for every category.
- 01
Extract relevant input
Separate URI, query values and body fields. Preserve where a finding came from instead of treating the whole request as one language.
- 02
Normalize supported forms
Decode supported representations so encoded punctuation can be inspected. Normalization is bounded and must be tested against backend behavior.
- 03
Analyze language structure
Use the relevant parser, tokenizer or structural checks. SQL combines AST evidence with heuristics and regular-expression safety nets for some fragments and dialect cases.
- 04
Collect evidence & apply policy
Evaluate risky constructs and configured weights. Carry the reason, affected field and score into WAFio's decision flow.
What an AST cannot add
It cannot reveal the backend's final query, authorization checks or parameter binding. An unsupported dialect or an incomplete fragment may not parse as expected.
VISIBLE TO THE WAF
Request input
Fields, syntax, encodings
and configured policies
INSIDE YOUR APPLICATION
Actual execution
Query construction, permissions,
business logic and data access
Structural detection is a protective layer. Parameterized queries, output encoding, validation and access control still belong in the application.
03 / SEMANTIC & CRS
Stronger context.
Complementary coverage.
Semantic analysis can be better than a simple keyword rule when the risk depends on how tokens relate. It can recognize supported attack structures across some surface variations and produce more specific explanations. Those are architectural advantages, not a universal accuracy or performance guarantee.
CRS is not just a keyword blacklist.
OWASP CRS uses transformations, rule conditions, anomaly scoring and paranoia levels. Coraza also supports libinjection operators for SQLi and XSS. Structural techniques and rule systems overlap; neither label alone tells you which system will detect an attack.
Coraza operator reference ↗ · CRS documentation ↗| Dimension | WAFio semantic scanning | OWASP CRS |
|---|---|---|
| Primary question | What language structure or risky operation is present? | Which configured detection conditions match this request? |
| Detection methods | Language-specific parsers, tokenizers, structural checks, heuristics and pattern fallbacks. | A maintained rule set using transformations, patterns, chained conditions and operators such as libinjection. |
| Strong use cases | Recognizing supported injection structures despite some changes in spelling or whitespace. | Broad web-attack coverage, protocol checks, multipart validation and a mature tuning ecosystem. |
| False positives | Structure can distinguish some harmless keyword use. Legitimate SQL, HTML or templates can still match. | Application exclusions and paranoia levels help control noise. Complex legitimate input can still match. |
| Blind spots | Unsupported syntax, incomplete fragments, parser differences and application context. | Coverage and transformation gaps, unfamiliar attack forms and application context. |
| Operational cost | Parser work depends on payload complexity and which engines run. Measure realistic traffic. | Cost depends on enabled rules, operators, transformations and traffic. Measure the same workload. |
| Maintenance | Parsers, normalization, evidence weights and regression cases need updates. | Rules, exclusions, engine compatibility and regression cases need updates. |
| Best deployment | A structural signal within a layered security policy. | Complementary coverage within a layered security policy. |
CRS's own anomaly thresholds and WAFio's mapped rule scores are different scoring systems. Do not compare their numeric values directly.
STRUCTURAL DEPTH
Semantic engines
Language relationships
Category-specific evidence
Layered policyReview overlapping signals
BROAD RULE COVERAGE
CRS
Attack patterns
Protocol & multipart checks
Agreement can increase confidence. Disagreement is useful investigation material. Two detectors can also share blind spots.
04 / THE WAFIO PIPELINE
How the layers actually connect.
WAFio does not simply run every detector and add every number. The current request path has early decisions, optional bypasses and sensitivity filtering. This diagram focuses on semantic and CRS processing after earlier request-policy checks.
Request & earlier policy checksSize, access and traffic controls can decide earlier
Semantic analysisRelevant engines inspect supported request input
THRESHOLD REACHED
Early blockSemantic score meets the configured block threshold
CLEAN + FAST PATH ENABLED
Skip CRSNon-multipart only; configured custom script rules still run
OTHERWISE
Coraza / CRSDetectionOnly: collect rule matches
WAFio scoring & policyMapped rules → sensitivity gate → thresholds → eligible cross-engine agreement
ALLOWLOGBLOCK
Fast paths trade coverage for less work.
With skip_coraza_when_clean=true, a clean semantic result can skip CRS entirely for non-multipart requests. CRS-only detections will not run on that path. Multipart requests are excluded from this optimization. Set the option to false when you require CRS inspection on semantic-clean requests, then measure the additional cost.
“Clean” means no configured semantic evidence was found. It does not prove a request is safe.
Expert detail: agreement does not mean adding every score
For eligible, non-log-tier semantic evidence below the blocking threshold, WAFio checks for a contributing CRS signal after sensitivity filtering. The agreement candidate uses the larger semantic or CRS score plus one-third of the block threshold. It can raise the result to BLOCK if the threshold is reached. Suppressed CRS hits alone do not qualify.
Open Redirect, Prompt Injection and Anomaly are visibility-oriented signals and are excluded as the semantic half of this boost. Path exceptions, disabled engines and other project policies also affect which branches run. Review the deployed configuration when investigating a verdict.
Implementation reference: WAFio internal/application/analyze.go, internal/engine/fastscan.go and internal/engine/decision.go. Diagram omits error handling and unrelated policy branches for readability.
05 / ENGINE COVERAGE
17 engines. Different jobs.
Different attack families need different evidence. “Semantic” does not mean every engine has the same parser, the same certainty or the same blocking behavior.
4 engines
Queries & expressions
SQL · NoSQL · LDAP · SSTI
Look for query operators, filter manipulation and template expressions. SQL uses AST evidence alongside heuristic and pattern checks.
5 engines
Browser & execution
XSS · CMD · PHP · Python · Java
Inspect markup contexts, shell syntax and language-specific execution indicators. Each engine has its own analysis techniques.
5 engines
Resources & objects
LFI · SSRF · XXE · Deserialization · Prototype Pollution
Look for traversal, suspicious fetch targets, XML entities and dangerous object manipulation. A match is evidence, not proof of backend execution.
3 engines
Visibility signals
Open Redirect · Prompt Injection · Anomaly
Surface suspicious redirects, prompt patterns and unusual input. These signals are log-tier by design and do not serve as the semantic input to cross-engine blocking.
Malicious upload detection is a separate control.
Uploaded binary files are not treated as source code by the semantic engines. Malicious Uploads Detection compares complete file hashes against available signatures, with exact hash verification. It does not unpack every archive or detect every modified malware sample.
Explore upload scanning →06 / STRENGTHS & LIMITS
Useful advantages.
Honest boundaries.
WHERE STRUCTURE HELPS
More meaningful evidence
- Fewer simplistic matches. A word can be assessed in its surrounding syntax rather than blocked in isolation.
- Variation tolerance. Supported encodings, spacing and expressions may still map to recognizable operations.
- Clearer investigations. Field-level reasons and structural evidence help explain a finding.
- Targeted policies. Category-specific tuning can match an application's expected input.
WHAT STILL NEEDS WORK
No universal understanding
- Parsing has limits. Fragments, malformed syntax and unsupported dialects can evade or confuse analysis.
- Context is incomplete. Teaching tools and code editors legitimately accept suspicious syntax.
- Resources are finite. Large or complex payloads require bounded processing and measured limits.
- Some flaws look ordinary. Broken authorization and business-logic abuse may contain no injection syntax at all.
CRS brings broad, maintained detection knowledge and an established tuning model. Its trade-offs include application-specific exclusions, potential noise from stricter settings and ongoing rule maintenance. A hybrid approach is useful only when its configuration, logs and regression tests are managed carefully.
Read the project's explanation of CRS paranoia levels and tuning ↗.
07 / EVALUATE & DEPLOY
Measure the result on your traffic.
“Better” should mean more relevant attacks caught, less legitimate traffic disrupted, and acceptable resource use on your application. There is no defensible zero-false-positive promise or universal speed claim without a defined dataset and test conditions.
1
Build a corpus
Representative legitimate requests + controlled attack cases
2
Compare modes
Semantic, CRS and hybrid with equivalent policies
3
Measure
False positives, missed attacks, p95/p99 latency, CPU & memory
4
Tune & repeat
Narrow changes, replay regression cases, keep a rollback
- Begin in a controlled environment. Include login, search, JSON APIs, rich text, non-English text and uploads. Label expected behavior independently of the WAF.
- Inspect the evidence. Record the field, category, reason, rule IDs and effective policy. Do not treat a blocked request as automatic proof of an attack.
- Tune narrowly. Scope exceptions to the necessary route or input and retain other protections. A global bypass can hide unrelated attacks.
- Roll out gradually. Review legitimate traffic impact and application errors, then expand enforcement. Re-test when the app, parser, rules or policies change.
Compare like with like.
Keep hardware, concurrency, payload sizes and configured coverage consistent. Record versions, dataset composition and warm-up conditions. A faster mode that skipped a detector is not evidence that the same coverage became faster.
08 / GLOSSARY & SOURCES
Keep exploring.
Semantic analysis
Examining structure and relationships in input to identify potentially dangerous operations. In WAFio this means deterministic analyzers, not an LLM deciding what a user intended.
Token
A meaningful piece of a language: a name, number, string, operator or keyword. A tokenizer splits input into these pieces.
AST
Abstract syntax tree: a structured representation of a parsed expression or program. It exposes relationships such as an OR expression containing two comparisons.
Normalization
Converting supported representations, such as URL encoding, into a form that a detector can inspect. Too much or too little decoding can differ from the backend.
CRS / Coraza
OWASP Core Rule Set provides detection rules. Coraza is the WAF engine that evaluates those rules. They are related components, not interchangeable names.
False positive / false negative
A false positive flags legitimate traffic. A false negative misses an attack. Reducing one can increase the other; evaluate both.
Paranoia level / sensitivity
CRS paranoia levels select additional rule coverage. WAFio sensitivity gates mapped rule contributions. These are separate controls, not equivalent scales.
DetectionOnly
Coraza evaluates and reports matches without applying disruptive rule actions. WAFio applies its own request policy and scoring decisions.
Primary references
OWASP CRS — detection, anomaly scoring and tuning ↗OWASP Coraza — SQLi and XSS operators ↗OWASP Coraza — actions and DetectionOnly behavior ↗OWASP CRS — configuration and paranoia levels ↗WAFio-specific behavior was checked against the current implementation. Illustrations explain concepts; they are not measured benchmark results. Reviewed September 2026.