Eduvos ITDTA4 / 2026
Two request guards at the web boundary
Study two web-boundary guards: request-method rejection and SQL-pattern filtering, with clear limits on what a WAF rule can protect.
RETAINED CONFIGURATION / NEW EXPLANATORY DIAGRAM
- 01
HTTP request
Method, URI, headers and argument fields
- 02
Phase 1 / method guard
The retained TRACE rule denies matching requests with HTTP 403.
- 03
Phase 2 / pattern guard
A case-insensitive rule checks selected SQL-like markers and denies matches with HTTP 403.
- 04
Remaining rules / upstream
The rest of the rule set, gateway and services were not recovered.
ENGINEERING PERSPECTIVE
Inside the work
Study a narrow web boundary control and its limits. Request filtering complements, but cannot replace, secure query construction and application-level authorization.
- ModSecurity configuration
- Two retained deny/status:403/log rules target TRACE and SQL-like markers.
- Request fields / phases
- Phase 1 examines the method; phase 2 inspects selected request arguments, names, headers and URI.
Inspect the method
The phase-1 rule rejects TRACE requests.
- Defence in depth
- A matching guard does not prove the application itself is safe.
- False positives and bypasses
- Pattern matching needs representative allowed/blocked test cases and cannot guarantee SQL-injection prevention.
- Configuration vs execution
- Rule text establishes intended behaviour, not a successful running WAF deployment.
What the demonstration establishes
The diagram explains the two inspected rules. No container stack, runtime request test or personal rule authorship is established by the file alone.
Evidence behind this page
One retained 412-byte ITDTA4 configuration; no proprietary application source or service stack is published.
How it works
One phase1 rule rejects TRACE. A second phase2 rule examines arguments, argument names, headers and URI for a case-insensitive set of SQL-like markers; both use deny,status:403,log.
Results & recovery
- One 412-byte configuration file with two explicit rules was recovered.
- The original rule IDs and phases establish the narrow request-filtering flow shown above.
Technical limitations
No Docker Compose, Flask/auth services, PostgreSQL schema, TLS setup, container-hardening configuration or original end-to-end test evidence was found. No complete secure stack or runtime WAF test is claimed. Pattern matching alone is not robust SQL-injection prevention.
What I would improve now
Recover the full lab source and permission evidence, validate rules in a disposable local WAF and retain false-positive/regression tests. Enforce parameterised database queries independently of request filtering.