potiuk opened a new pull request, #1242: URL: https://github.com/apache/pekko-http/pull/1242
### Motivation The Pekko PMC asked the ASF Security team for a draft threat model to refine, as preparation for a Claude security scan. This is the companion to [the same change in `apache/pekko`](https://github.com/apache/pekko/pulls) — that model covers the actor, stream, remoting and cluster layers, and this one does not restate them. `docs/src/main/paradox/security.md` already carries a **"Security model"** section, and it makes the most consequential statement in this document: applications *"should not be exposed to the public internet directly"*, and DoS resistance is claimed only as *"pretty well under most known Denial of Service attacks"*. But that is three sentences, and the quantitative envelope that actually bounds untrusted input — the parsing limits in `http-core`'s `reference.conf` — is not connected to it anywhere. Separately, the `AGENTS.md` → `SECURITY.md` chain that a scanning agent follows to locate a project's model does not resolve today: there is no `SECURITY.md` in the repo. ### Modification - **`THREAT_MODEL.md`** — a v0 draft. **§5a** collects the shipped parsing limits, timeouts and CORS defaults as the model's quantitative spine; **§8** states the six default-on properties they underwrite. Every claim is tagged `(documented)` with a citation or `(inferred)` with a matching question in §14. - **`SECURITY.md`** — reporting policy (`[email protected]`; Pekko does not operate a separate project security list), plus the three points that catch most reporters. - **`AGENTS.md`** — a two-line `## Security` section pointing at both. Nothing `security.md` asserts has been dropped or weakened — **§15 back-maps** each existing statement to the section that now carries it. ### Result The chain `AGENTS.md` → `SECURITY.md` → `THREAT_MODEL.md` resolves on `main`, and triagers get a citable document with a closed set of dispositions (§13). Worth noting in contrast to the `apache/pekko` model: **every §8 property here is default-on**. Pekko HTTP's parsing limits, timeouts, strict URI/cookie parsing and response-splitting protection all ship enabled. The soft spot is not the defaults, it is the boundary of the DoS claim. **§14 holds 10 questions, each stated as a proposed answer** — confirming or correcting is enough. The two worth reading first: - **Q1 — where exactly is the DoS line?** `security.md`'s claim is deliberately graded, and triage needs a split. *Proposed:* a request **within** all §5a limits that causes super-linear CPU or memory is `VALID`; anything requiring limits to be raised, or requiring request *volume* rather than request *content*, is out of model because volume defence is the fronting proxy's job. Is that the intended reading? - **Q2 — the `http-cors` defaults.** The module ships `allowed-origins = "*"` together with `allow-credentials = yes`. Per its own `reference.conf`, that combination does **not** send a literal `*` — it echoes the request's `Origin` and allows credentials. Two things bound how alarming that is: `cors()` is opt-in, and the interaction is documented. Is the default deliberate, or should it change? **This is a draft and should not be treated as canonical until at least Q1 and Q2 are answered.** Happy to fold answers in, or hand it over entirely — the PMC owns the document. ### Tests Not run - docs only ### References None - requested by the Pekko PMC chair on the ASF security scan thread -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
