One thing which has come out of discussions about stemming the tide of LLM reports is having a security model written down which a) the LLMs can read, and b) we can use when assessing poor/slop reports.
Most importantly the "we" in (b) should include the [email protected] team who can hopefully use it to filter out the slop before "we" (this project's committers on [email protected]) see it. I find this task difficult to scope properly... it's hard to know what should/should not be covered here. And there's probably an academic discipline behind this topic of which I'm ignorant. Anyway I took a first stab, attached, definitely a lot missing. I'm thinking we put this at ./docs/security-model.md or somewhere while it's a WIP. Ideally I think it ends up in docs/manual too when we're happy with it, but we probably need to keep a canonical version in markdown for the LLMs, so there's another problem to solve. Thoughts? (I only started using RFC 2119-style MUST/SHOULD half way through editing so it's not consistent on that style) Regards, Joe
# Apache httpd Security Model This document provides an overview of the security model for Apache httpd. Security vulnerabilities reported to the project need to demonstrate how an attacker can violate the security model in some way. If an issue is reported against an aspect of the security model which is not documented here, it MUST be accompanied by a clear description of that model, showing why a trust boundary exists and how it is violated. Any security vulnerability SHOULD be reproducible: 1. under a reasonable, supported configuration. 2. without using third-party modules, or modules explicitly designed for debugging. 3. under a standard build on a supported platform. Issues which are reproducible only using instrumented builds (such as ASAN, or under valgrind) should be clearly explained as such. ## Basic model Processing of requests by remote untrusted users (HTTP clients) MUST NOT crash or prematurely terminate server processes, nor gain code execution privileges. In the default configuration, timeouts are applied to most aspects of HTTP request handling such that a single client SHOULD NOT tie up a single processing thread or process indefinitely. It is the responsibility of the server administrator to tune and configure httpd appropriately to the operating environment, for example adjusting MPM limits (see https://httpd.apache.org/docs/trunk/misc/security_tips.html). Denial of service attacks are expected to be mitigated at firewall or network level. It is expected that an attacker who is able to establish multiple simultaneous connections to the server will, to some extent, deny service to other remote users. Example vulnerabilities which violated the model: CVE-2026-23918, CVE-2004-0786. ## Resource Consumption Handling requests requires resource consumption (for example CPU, memory, disk space for logs). It is expected that resource consumption by the server is at worst proportional to the volume of network traffic. Memory consumption by a single request should be capped, with configurable limits; e.g. LimitRequestFields limits the RAM consumption by HTTP headers, LimitXMLRequestBody limits the RAM consumption by parsing XML request documents. Example vulnerabilities which violated the model: CVE-2004-0942 ## Privilege separation on Unix platforms On Unix platforms, when httpd is started as the root user, child processes (and threads) which handle incoming connections run as a less-privileged server user configured via the "User" directive. https://httpd.apache.org/docs/2.4/mod/mod_unixd.html#user The less-privileged user: * cannot obtain root privileges, * cannot read or truncate log files, * retains access to e.g. any private TLS key data loaded in memory. Any site author or local user able to execute arbitrary code as the less-privileged user can, for example, deny service completely to remote clients. Examples of such are Lua scripts executed by `mod_lua`, or use of `mod_php` to run PHP scripts. Example vulnerabilities which violated the model: CVE-2007-3304, CVE-2012-0031. ## Delegated Configuration Server configuration can be delegated to trusted local site authors by allowing use of .htaccess files in non-default configurations. Local site authors are trusted to not attack the server with malformed or malicious .htaccess files (for example, files of excessive size). In configurations supporting in-process scripting language interpreters which are not sandboxed, such as `mod_lua` or `mod_php`, local site authors have equivalent privileges to the less-privileged server user. (### TODO something about AllowOverride) ## Dependent Services Many configurations depend on backend servers or services which are trusted entities. * Backend servers accessed in a proxy configuration should not be able to influence HTTP protocol framing logic in the frontend (client) ("response splitting" attacks). * Services used for authentication or caching privileged/protected data (Redis/Valkey servers, database or LDAP servers) are trusted not to attack the web server. Example vulnerabilities which violated the model: CVE-2026-33523, CVE-2024-42516.
