## Problem Most API security incidents over the past year have been malformed JSON payloads causing denial of service in varied and creative ways. Rails is difficult to harden against this because it trusts its input by design, and nothing validates or rejects requests before they reach it. Each incident pulls the team onto unplanned work that displaces roadmap commitments, and because the problem is cross-cutting it cannot be handed to another team. Responsible disclosure and HackerOne SLAs mean it cannot be deferred either. The team absorbs this work reactively, and the work is largely invisible above the team level. ## Goal ### First iteration Deliverable without depending on any other epic: 1. Classify the past year of API security incidents by whether validation at the edge would have prevented them. This is the go/no-go for the rest of the epic. If the answer is "few of them", the epic stops here and that is a useful result. 2. Compare Workhorse and Envoy Proxy as the enforcement point: cost to build, self-managed implications, and who owns it operationally. 3. Prototype one rule at the chosen point — payload size or nesting depth — and replay a real past incident against it. ### Long-term outcome Reached in combination with the sibling epics, not blocking the above: - The OpenAPI spec is the validation source of truth, so rules are derived from the API definition rather than hand-written per endpoint. - One enforcement point covers both the monolith and modular components (e.g., **API Gateway**), which also gives endpoints a stable front to move behind during decomposition. - A measurable reduction in unplanned security work, making the remaining security effort visible as a deliberate investment rather than an interruption. ## Technical considerations - Envoy **Proxy**, not Envoy **Gateway**. Gateway is an ingress controller and cannot be required on self-managed clusters; Proxy can be shipped and configured wherever GitLab runs. - Envoy will run in front of GitLab regardless, as part of the authentication proxy work, including in Omnibus. That work is a stakeholder in any decision here. - Workhorse is the boring option and is explicitly in scope, since it already exists and ships everywhere; the argument against is that it moves complexity to another layer rather than removing it. - Out of scope: standardizing on Kubernetes Gateway API. GitLab relies on TCP routes for SSH, which is alpha in that specification and unlikely to be adopted, so this is a separate discussion from this epic. ## Links **Contacts**: Matthias Käppler (authentication proxy and Envoy in self-managed) Incident data for first iteration point 1 (confidential): https://gitlab.com/groups/gitlab-org/quality/-/epics/260 Workhorse: https://gitlab.com/gitlab-org/gitlab/-/tree/master/workhorse