Nginx Client Max Body Size Upload Auditor

The Incident (What Does the Error Mean?)

Your Nginx error log shows one or both of these:

2024/01/15 03:42:17 [error] 1234#1234: *891 upstream prematurely closed connection
while reading response headers from upstream, client: 10.0.1.45,
server: api.example.com, request: "POST /upload/video HTTP/1.1",
upstream: "http://127.0.0.1:8080/upload/video", host: "api.example.com"

2024/01/15 03:42:17 [error] 1234#1234: *891 client intended to send too large body: 157286400 bytes

The client receives an HTTP 502 Bad Gateway (sometimes a 413 Request Entity Too Large if Nginx kills it before proxying). The upload fails completely. There is no partial recovery — the user sees a hard failure.

Immediate consequence: Every file upload above the default client_max_body_size of 1MB is silently dropped or causes the upstream process (Node, Gunicorn, uWSGI, Rails Puma) to receive a broken pipe and crash its request handler — sometimes taking down the worker thread entirely.

The Attack Vector / Blast Radius

This is a dual-failure mode — it's both an operational outage and a latent security misconfiguration:

Failure Path 1 — Nginx kills it (413): Nginx enforces client_max_body_size before the upstream ever sees the request. The upstream worker is never invoked. Clean failure, but users are blocked.

Failure Path 2 — Nginx buffers it (502, the dangerous one): With proxy_request_buffering on (the default), Nginx reads the entire client request body into a temp file on disk before opening a connection to the upstream. For a 500MB video upload over a slow mobile connection, this buffer phase can take minutes. The upstream application has its own read timeout (e.g., uwsgi_read_timeout 60s). The upstream opens the connection, waits for headers that never arrive (Nginx is still buffering), hits its own timeout, and closes the socket. Nginx then reports 502.

Cascading failure risk:

• Upstream worker threads pile up waiting for connections that never complete → thread pool exhaustion
• Nginx temp file buffer fills /var/cache/nginx or /tmp → disk saturation on high-concurrency upload endpoints
• Broken pipe signals to uWSGI/Gunicorn workers can trigger worker respawn storms if not handled gracefully
• If client_body_temp_path is on the OS root partition, a large upload spike can cause full disk → total service outage

Security angle: A client_max_body_size 0 (unlimited) misconfiguration — sometimes set by a developer to "just make uploads work" — removes all upload size enforcement. An unauthenticated attacker can POST unbounded payloads, filling disk and exhausting memory on the upstream app server. This is a trivial disk-fill DoS vector.

Prevention in CI/CD

This class of misconfiguration is 100% detectable before it hits production.

1. Nginx Config Linting (Pre-commit)

# Run nginx -t in a container as part of your pre-commit hook
nginx -t -c /repo/nginx/nginx.conf

# Or use gixy — the Nginx static security analyzer
pip install gixy
gixy /repo/nginx/nginx.conf
# Gixy will flag: proxy_request_buffering on + large client_max_body_size as a risk

2. Checkov for IaC-Managed Nginx (Terraform/Helm)

If your Nginx config is rendered via Helm values.yaml or a Terraform templatefile:

# .checkov.yaml — custom check
checks:
  - id: CKV_NGINX_UPLOAD_001
    name: "Nginx upload locations must disable proxy_request_buffering"
    resource: nginx_location
    attribute: proxy_request_buffering
    operator: equals
    value: "off"
    severity: HIGH

3. OPA/Conftest Policy

# policy/nginx_upload.rego
package nginx.upload

deny[msg] {
    input.location[loc]
    contains(loc.path, "upload")
    loc.proxy_request_buffering != "off"
    msg := sprintf(
        "Location '%v' handles uploads but proxy_request_buffering is not 'off'. This causes 502 on slow clients.",
        [loc.path]
    )
}

deny[msg] {
    to_number(input.http.client_max_body_size) == 0
    msg := "client_max_body_size 0 (unlimited) is a disk-fill DoS vector. Set an explicit limit."
}

# Run in CI pipeline
conftest test nginx.conf --policy policy/nginx_upload.rego

4. Load Test Upload Paths Before Every Release

# k6 smoke test — validate 100MB upload returns 200, not 502/413
k6 run --vus 5 --duration 30s - <<'EOF'
import http from 'k6/http';
import { check } from 'k6';

export default function () {
  const payload = open('/tmp/test-100mb.bin', 'b');
  const res = http.post('https://api.example.com/upload/test', payload, {
    headers: { 'Content-Type': 'application/octet-stream' },
    timeout: '120s',
  });
  check(res, { 'upload status is 200': (r) => r.status === 200 });
}
EOF

If this k6 test fails in staging, the deployment is blocked. No exceptions.