flare's security posture is layered. Each row below lists what that layer enforces — by default, on every request, with no opt-in needed.

The criticism that drove this:

A request to /users/<script>alert(1)</script> would echo that string in the 400 body with Content-Type: text/plain. Plain text is safe in a browser, but logs that auto-link or terminals that ANSI-interpret can be surprised. More importantly: parser-error messages are a DoS / log-poisoning surface and should be sanitised or replaced with status-code-only responses.

Default behaviour:

• 400 / 4xx responses use a fixed status reason as the body (e.g. "Bad Request", "Not Found"). The raised error message is not copied into the response.
• The full message (including any user input the extractor was parsing) is logged to stderr with the request id, so production debugging works. A line looks like [flare:bad-request] rid=<id> <message>; the id is the inbound X-Request-Id header, or - when the request carried none (an id that RequestId generates itself is not known at the error site). Control bytes in the id and the message are escaped, so a hostile value cannot split or forge a log line.
• 500 (handler raise) is the same: fixed body, full message logged with request id as [flare:handler-error] rid=<id> <message>. This holds on the HTTP/1.1, HTTP/2 and HTTP/3 paths. A handler that raises HttpStatusError chose its message for the client, so that one is sent as is and not logged.

Local-development opt-in:

var srv = HttpServer.bind(SocketAddr.localhost(8080), ServerConfig(
    expose_error_messages=True,
))

Flipping expose_error_messages to True echoes the raised message into the response body. Use it locally; do not use it in production.

The fuzz harness fuzz/fuzz_extractors.mojo includes a property that generates URLs with high-bit / control / HTML-ish payloads and asserts the response body equals the fixed reason — i.e., that no fuzzer-generated input ever escapes into a 400 body. The property runs at every release tag.

63 harnesses today (59 fuzz + 4 property), covering:

• HTTP parsing (request, response, headers, URL, cookies, auth)
• WebSocket frames (mask, opcode, close codes)
• Router paths (linear scan)
• Comptime route trie (oracle: 500K-run check that ComptimeRouter and Router agree on every status code for every path)
• Reactor / connection state machine (chunk boundaries, churn, shutdown)
• Multicore scheduler shutdown
• Typed extractors
• SIMD header scanner
• QUIC and HTTP/3: varint, long header, packet decrypt, initial handshake, transport parameters, connection id, migration and its amplification limit, retry, early-data length and replay strike, h3 frame, h3 server, h3 response reader, QPACK decode and its dynamic table
• HTTP/2 denial of service: the CONTINUATION flood and the rapid-reset shape of CVE-2023-44487
• Property tests on the timer wheel, headers, auth, WebSocket round-trip

63 harnesses, 9M+ runs combined, zero crashes to date.

All 63 run nightly. Until v0.11 the scheduled job ran ten of them by name, so the entire QUIC, HTTP/3 and QPACK family and both HTTP/2 denial-of-service harnesses had never run on a schedule -- only when someone ran fuzz-all by hand. The corpus is cached between runs, so each night starts from what the last one found rather than rediscovering it.

Real soak tests as release gates: slow-client, churn, mixed-load. These do not produce a number to brag about. They produce the answer to "can I run this in production?"

Harness, gates, and the three-tier (smoke / extended / 24-hour release-gate) shape live with the rest of the performance work in benchmark.md.

Fuzzing samples inputs; the Lean 4 models in formal/ prove properties for all of them. The codecs, the HTTP/1.1, HTTP/2, WebSocket, QUIC and HTTP/3 state machines, and the scheduler are transliterated into Lean and checked against specs written from the RFCs. Differential tests then run the models against the Mojo code, so a transliteration error shows up too. The 0.12 audit (formal/REPORT.md) found 138 issues this way, all fixed. Anchors on every model and a pre-commit gate keep the proofs about the code that ships.

For security issues, please open a private security advisory on GitHub or email the maintainer directly. Do not file a public issue for vulnerabilities.

flare has zero known production deployments. Treat the maturity gap honestly: nginx, Go net/http, hyper, and axum all shipped CVEs in their first two years, and the HTTP/2 HPACK parser is one of the highest-CVE-risk subsystems in any HTTP server. flare's HPACK is covered by a dedicated fuzz harness for that reason.