What is Heimdall Shield
Introduction
Heimdall Shield is a custom security engine written in Go that runs as the backend behind HAProxy. HAProxy does transport only — TLS termination, routing, connection pooling, health checks, high availability, L4/L7 rate limiting — and contains no security logic at all: no WAF rules, no regex, no detection, no AI. Every security decision lives in the Go engine.
Not a regex WAF
Heimdall is deliberately not a signature/regex WAF, and it is not built on ModSecurity or Coraza. Instead of matching strings against a rule language, it:
- Parses the true wire bytes with its own HTTP engine (it does not use Go's
net/http), so it sees exactly what the client sent — which is what makes request-smuggling and framing attacks detectable in the first place. - Reduces every request to a single Canonical Request Model in which all equivalent encodings of the same input collapse to one value.
- Runs specialized detection engines that reason about structure and intent over that canonical form.
The canonical step is the whole idea. UNION, uNiOn, UN/**/ION, %55NION
and <script> written as &lt;script&gt; all normalize to one canonical
value before any engine looks at them. Detection then runs once, against the
truth — which is what keeps false positives low and makes every verdict
explainable.
The pipeline
Raw request → Normalization → Protocol parser → Canonical Request Model → Feature extraction → specialized Detection engines (SQLi, XSS, SSRF, command injection, path traversal, header, protocol, API, rate, auth — none of which block; each returns risk / confidence / evidence) → Risk engine (aggregates into one score) → Decision engine (Allow / Monitor / Throttle / Challenge / Block / Drop) → origin.
Each stage has its own page under Engines; the full end-to-end walk is in Request lifecycle.
What surrounds the core
Around that deterministic path sit several higher-order capabilities:
- Endpoint Intelligence — learns how each endpoint normally behaves (methods, parameter counts, body sizes, frequency) and surfaces deviation.
- Browser Identity & Reputation — TLS/HTTP fingerprinting and reputation-over-time, so decisions have context beyond a single IP.
- Challenge / anti-scraping — a first-party proof-of-work challenge with a branded interstitial. No CAPTCHA, no third-party JavaScript.
- Offline AI/ML — a data lake plus anomaly detection, attack clustering and an LLM analyst that produce human-gated rule suggestions.
Two hard invariants
AI never decides in real time
All AI/ML is offline only. Learning, clustering and LLM analysis run against the data lake and emit rule suggestions that a human approves before they ever affect live traffic. The real-time path is fully deterministic.
Monitor-first
Heimdall runs in shadow mode by default: every request is fully inspected, scored and recorded, but nothing is blocked. Each decision also carries the action enforcement would have taken, so you can validate the false-positive rate against your own traffic before turning enforcement on.
Open-core
The deterministic core is open source (Community Edition, EUPL-1.2). Everything that is about scale, learning, or regulation — the AI/ML tier, Browser Identity/Reputation, anti-bot, threat-intel feeds, clustering and central management — is Enterprise, and it attaches to the core only through an out-of-process plugin SDK (gRPC), never by in-process linking. The core is a complete, production-grade single-node security edge on its own; it is never crippleware. See Intelligence plugins for the boundary.
Design priorities throughout: performance and security over simplicity — zero-copy and streaming on hot paths, zero-allocation engines, fixed-point math (no floats), hardened against malicious input, and fuzzed.