Without limits, an attacker (or a genuine mistake) could send extremely large requests, consuming excessive bandwidth, disk space, or memory. This guide covers configuring appropriate request size limits.
Why This Matters
An unlimited upload endpoint is a potential vector for denial-of-service abuse (filling disk space or exhausting memory with oversized requests) even without any other vulnerability being exploited — a basic, easily-overlooked hardening measure.
Setting a Global Maximum Request Body Size
http {
client_max_body_size 10m;
}Requests exceeding this size receive a 413 Request Entity Too Large response immediately, before consuming resources processing the full oversized request.
Setting Different Limits for Different Paths
location /api/upload {
client_max_body_size 50m;
}
location / {
client_max_body_size 1m;
}
An upload-specific endpoint might legitimately need a higher limit, while most of your site (form submissions, API calls) needs much less — avoid a single generous limit applied everywhere unnecessarily.
Choosing an Appropriate Limit
Set the limit based on your actual legitimate use case's realistic maximum, with modest headroom — not an arbitrarily large "just in case" value that provides little real protection.
Limiting Request Header Size
large_client_header_buffers 4 8k;Protects against abuse via excessively large headers, a less common but still real vector.
Rate Limiting Uploads (Beyond Just Size)
Size limits alone don't prevent an abuser from sending many rapid requests at the maximum allowed size — combine with request rate limiting (see How to Rate Limit an API with Nginx) for comprehensive protection.
Testing Your Limit
curl -X POST -F "[email protected]" https://yourdomain.com/api/uploadVerify requests exceeding your configured limit correctly receive a 413 response rather than being processed or causing an error elsewhere in the stack.
Handling the 413 Error Gracefully
error_page 413 /413.html;See How to Configure Custom Error Pages in Nginx/Apache — a friendly error message explaining the size limit is more helpful to legitimate users than a bare error response.
Considerations for Legitimate Large Uploads
If your application genuinely needs to support large file uploads (video, large documents), consider whether a direct-to-object-storage upload pattern (bypassing your application server entirely for the actual file transfer) might be more appropriate than routing large files through Nginx/your application at all — see object storage guides for this pattern.
Application-Level Validation Too
Nginx-level limits are a first line of defense — your application should still validate uploaded content (file type, actual content matching claimed type, virus scanning if appropriate) rather than relying solely on the size limit for security.
Common Errors
Legitimate uploads failing with 413 — verify the limit is actually appropriate for your real use case; check whether the limit needs to be set at multiple levels (Nginx AND your application/language runtime, which may have its own separate, potentially lower default limit).
Continue Reading
- How to Rate Limit an API with Nginx
- How to Set Up Self-Hosted S3-Compatible Object Storage with MinIO
- How to Configure Custom Error Pages in Nginx/Apache
Browse more articles in Web Servers.
