How to Increase SecRequestBodyLimit for Large File Uploads?

How to Increase SecRequestBodyLimit for Large File Uploads

Increase SecRequestBodyLimit above the size of the complete multipart HTTP request when ModSecurity prevents a legitimate file upload. A 25 MB file should have a request-body limit greater than 25 MB because multipart boundaries, form fields, headers, and other request data add overhead. A practical 30 MB limit can provide suitable headroom for an application that accepts files up to approximately 25 MB.

ModSecurity evaluates HTTP request bodies before the backend application processes them. This means a Java, PHP, Node.js, Python, or other application can advertise support for large uploads while Apache or ModSecurity rejects the request before it reaches the application. The correct solution is therefore to identify the first layer imposing the restriction and align the infrastructure limit with the application’s documented upload requirement.

Understand how ModSecurity controls request-body size

SecRequestBodyLimit defines the maximum request-body size that ModSecurity accepts for buffering. ModSecurity’s reference documentation currently lists 134217728 bytes, or 128 MB, as the module default, while the official recommended configuration uses 13107200 bytes, or approximately 12.5 MB. This distinction matters because many production servers inherit values from the recommended configuration rather than relying on the module’s built-in default.

The recommended configuration explicitly states that applications supporting file uploads should set SecRequestBodyLimit according to the largest file they are willing to accept. It also recommends keeping the separate non-file request limit as low as practical.

A 12.5 MB limit therefore does not necessarily indicate a defect in ModSecurity. It can simply reflect a conservative configuration that is unsuitable for an application designed to accept larger multipart uploads.

Calculate the request limit from the real upload requirement

The request-body limit should represent the maximum complete HTTP request rather than only the raw file size. Multipart/form-data requests contain additional boundaries, part headers, filenames, form fields, and metadata around the uploaded file.

For example, the byte values for common file sizes are:

25 MB file  = 26,214,400 bytes
30 MB limit = 31,457,280 bytes
50 MB limit = 52,428,800 bytes
100 MB      = 104,857,600 bytes

A 30 MB request-body limit therefore gives an application accepting approximately 25 MB files additional room for multipart overhead. Applications that allow several files in a single request should calculate the limit from the maximum combined request size rather than the size of one individual file.

The correct value depends on the application’s actual request structure. A 25 MB single-file upload and a request containing five 25 MB files have very different infrastructure requirements even though both applications might describe their individual file limit as 25 MB.

Keep SecRequestBodyNoFilesLimit separate from upload size

SecRequestBodyNoFilesLimit controls the request-body portion excluding uploaded files. This directive exists so administrators can allow large file uploads without automatically permitting equally large non-file request bodies. The official ModSecurity documentation specifically recommends keeping this value low enough to reduce exposure to unnecessarily large ordinary request bodies.

This distinction is important when configuring an upload API. Increasing SecRequestBodyNoFilesLimit to 30 MB simply because the application accepts 30 MB files is generally unnecessary when the large portion of the request consists of actual file data.

For example, a configuration can use a 30 MB overall request limit while keeping the non-file request limit at 128 KB:

SecRequestBodyLimit 31457280
SecRequestBodyNoFilesLimit 131072

The exact value should reflect the application’s legitimate form-data requirements rather than being copied blindly between environments.

Do not confuse request size with memory buffering

SecRequestBodyInMemoryLimit has a different purpose from SecRequestBodyLimit. In ModSecurity 2.x, this directive controls how much request-body data is kept in memory before multipart data can be written to temporary disk storage. The documented example is 131072 bytes, or 128 KB.

libModSecurity v3 does not support SecRequestBodyInMemoryLimit as an active configuration directive. The v3 reference manual explicitly marks it as unsupported and explains that libModSecurity can work with request bodies provided through a file or buffer.

This version difference is important when troubleshooting modern Apache deployments. Adding an old ModSecurity 2.x directive to a v3 environment does not increase the permitted upload size and can create configuration confusion.

Configure a 30 MB upload ceiling

A 30 MB ModSecurity request-body ceiling corresponds to 31,457,280 bytes. If the application legitimately accepts files around 25 MB, a configuration similar to the following can provide infrastructure headroom:

<IfModule mod_security2.c>
    SecRequestBodyLimit 31457280
    SecRequestBodyNoFilesLimit 131072
    SecRequestBodyLimitAction Reject
</IfModule>

The configuration scope matters as much as the value itself. If only one application needs larger uploads, apply the change to that application’s virtual-host or supported per-domain configuration instead of raising the request-body limit globally.

A global increase affects every virtual host that inherits the setting. On a shared hosting server, that can unnecessarily increase the amount of request data accepted across unrelated applications.

Understand what happens when the limit is exceeded

SecRequestBodyLimitAction determines how ModSecurity handles a request that exceeds SecRequestBodyLimit. The available actions are Reject and ProcessPartial. With Reject, ModSecurity rejects the oversized request, normally resulting in HTTP 413. With ProcessPartial, ModSecurity processes only the portion that fits within the configured limit and allows the remainder to continue.

ProcessPartial can make troubleshooting more difficult because an oversized request does not necessarily present as a clean application-level upload rejection. The backend may receive an incomplete request, or the transaction may fail later during multipart processing.

ModSecurity also notes that ProcessPartial is automatically used when the engine operates in DetectionOnly mode so that request-body limits do not disrupt traffic during passive monitoring.

For a production blocking configuration, administrators should understand exactly which behavior their security policy requires rather than switching to ProcessPartial simply to make uploads appear to work.

Verify the effective configuration before changing anything

The effective Apache configuration matters more than the contents of one ModSecurity configuration file. Apache can load configuration from multiple files, virtual-host includes, rule sets, vendor configurations, and hosting-control-panel generated files.

A basic configuration search can identify configured request-body directives:

grep -RniE "SecRequestBody(Limit|NoFilesLimit|InMemoryLimit)|SecRequestBodyLimitAction" /etc/apache2 2>/dev/null

On cPanel servers, administrators should also consider generated Apache configuration and supported userdata or include mechanisms before making persistent changes. Directly modifying generated configuration files can cause a working change to disappear after an Apache rebuild or configuration update.

The correct workflow is to identify where the active directive originates, determine its scope, make the persistent change in the supported configuration location, validate Apache syntax, and then reload or restart Apache as required.

Diagnose the upload at the correct endpoint

A ModSecurity event on one URL does not prove that another URL is responsible for an upload failure. Login pages, OAuth callbacks, REST APIs, WordPress requests, and multipart upload endpoints can trigger completely different ModSecurity processing paths.

The investigation should therefore correlate the exact hostname, URI, HTTP method, client IP, timestamp, response status, and request size. For a Java API, the upload endpoint should be examined independently from unrelated ModSecurity alerts.

This distinction is particularly important on production servers where several applications share the same Apache instance. A 403 generated by a security rule on an OAuth callback should not automatically be treated as evidence that a multipart upload is being blocked by SecRequestBodyLimit.

Trace the request through Apache and Tomcat

A Java upload can fail before Tomcat receives the request. In a typical Apache-to-Tomcat architecture, the request travels through several layers:

Client
  ↓
Apache HTTP Server
  ↓
ModSecurity
  ↓
VirtualHost / Proxy Configuration
  ↓
mod_jk or Another Connector
  ↓
Tomcat
  ↓
Java Application

Each layer can impose a different restriction. ModSecurity can enforce request-body security limits, Apache can apply request and connection policies, the connector can impose timeout behavior, Tomcat can enforce connector-level constraints, and the application can enforce its own business-level upload limit.

A request that never appears in the Tomcat access log should therefore be investigated upstream before changing Java application code.

Separate upload-size failures from timeout failures

Request-size limits and connection timeouts solve different problems. A timeout determines how long a connection or operation can remain active, while SecRequestBodyLimit determines how much request-body data ModSecurity accepts for buffering.

Increasing a proxy timeout from 30 seconds to 300 seconds will not fix a request-body ceiling of 13 MB. Conversely, increasing SecRequestBodyLimit will not prevent a slow client or connector from timing out before the upload completes.

This distinction is critical for production troubleshooting because large uploads can expose both problems at the same time. A 25 MB file may require more request-body capacity and more transfer time than a 2 MB file, but those requirements should be investigated independently.

Understand why multipart requests need special attention

Multipart/form-data combines file content and form metadata into a single HTTP request. ModSecurity must parse the multipart structure so that security rules can inspect the request and identify its components.

The request contains more than the binary file itself:

HTTP headers
Multipart boundary
Part headers
Form fields
Filename metadata
File content
Multipart boundary
Additional fields

The additional data is usually small compared with the file, but it explains why the infrastructure limit should not be set exactly equal to the application’s advertised file size.

The official recommended ModSecurity configuration explicitly states that the overall request-body limit must be large enough for the largest file an application is designed to accept.

Treat temporary storage as part of the upload architecture

Large request bodies can involve temporary storage during request processing. This means a server can have adequate RAM and still fail large uploads if the relevant temporary filesystem lacks sufficient free space or has unsuitable permissions.

This becomes especially important for high-volume upload applications. Several concurrent uploads can consume significant disk space even when each individual request remains below the configured request-body limit.

Production monitoring should therefore include temporary filesystem capacity, disk I/O, CPU utilization, connection counts, and request duration rather than monitoring only application memory.

Apply domain-specific limits in shared hosting environments

A domain-specific request-body policy is usually safer than changing the global limit for a single application’s requirement. A shared server may host dozens or hundreds of websites with completely different request patterns.

Suppose one Java application requires 30 MB uploads while the remaining websites primarily process small HTML forms and API requests. A global 30 MB request-body policy expands the accepted request size for every application even though only one requires it.

A domain-specific configuration keeps the exception tied to the application that needs it and makes the infrastructure easier to document and audit.

Validate the entire upload path after the change

A configuration change is not complete until the upload succeeds through every infrastructure layer. Testing should include files below the application limit, files close to the limit, and files above the application limit.

For a 25 MB application policy, a useful validation sequence is:

5 MB upload       → should succeed
20 MB upload      → should succeed
~25 MB upload     → should succeed
>25 MB upload     → should be rejected by the intended policy

The important distinction is where the rejection occurs. A file exceeding the application’s documented 25 MB business limit should be rejected intentionally by the application or designated policy layer, not fail unpredictably because an unrelated 13 MB ModSecurity ceiling was reached first.

Administrators should also confirm that the successful upload appears in the expected Tomcat and application logs and that ModSecurity does not report a request-body-limit violation for legitimate traffic.

Learn from a common production failure

A Java application can remain completely healthy while Apache prevents its upload API from receiving larger multipart requests. Consider a production application that accepts files up to 25 MB while the effective ModSecurity configuration limits request bodies to 13,107,200 bytes.

Small uploads succeed because they remain below the security layer’s limit. Larger uploads fail before Tomcat processes the endpoint. Application developers may therefore see no corresponding upload exception because their application never received the complete request.

The infrastructure team might initially investigate Tomcat, Java heap usage, application configuration, or proxy timeouts. The actual problem, however, exists earlier in the request path.

The correct remediation is not to disable ModSecurity globally. The infrastructure team should identify the effective SecRequestBodyLimit, confirm the application’s maximum request size, increase the limit with appropriate headroom, retain a sensible SecRequestBodyNoFilesLimit, validate the Apache configuration, and test the complete request path.

Protect the server when increasing upload limits

Increasing SecRequestBodyLimit also increases the amount of request data the infrastructure must be prepared to receive and process. A larger limit should therefore correspond to a documented application requirement rather than an arbitrary value such as 500 MB or 1 GB.

The security impact also depends on request concurrency. Ten simultaneous 30 MB requests represent a very different workload from one occasional 30 MB request. Network bandwidth, Apache workers, temporary storage, backend processing, disk throughput, and application concurrency all become relevant when large uploads are common.

The official ModSecurity documentation also describes SecRequestBodyNoFilesLimit as a mechanism for reducing exposure to unnecessarily large non-file request bodies while still allowing applications to support large file uploads.

Document the complete upload policy

The application’s upload limit should be documented together with every infrastructure limit that supports it. A useful production record should identify the maximum file size, maximum combined request size, ModSecurity request-body limit, web-server policy, reverse-proxy or connector timeout, Tomcat configuration, application limit, and temporary-storage requirements.

This prevents future administrators from troubleshooting the same incident repeatedly. It also avoids the common situation where an application is upgraded from a 5 MB upload policy to 25 MB while the infrastructure continues using an old security configuration.

For managed environments, documenting these dependencies is particularly valuable because upload capacity is an infrastructure requirement rather than an isolated application setting.

Build a predictable large-upload architecture

Reliable file uploads require every layer to support the same documented request envelope. The application should enforce its business limit, Apache should accept the required request size, ModSecurity should have sufficient request-body capacity to inspect legitimate traffic, connector timeouts should accommodate expected transfer times, Tomcat should accept the request, and the server should have sufficient temporary storage.

For a 25 MB application upload policy, a 30 MB ModSecurity request-body ceiling can provide useful infrastructure headroom while keeping the application-level 25 MB rule intact.

The goal is not to make ModSecurity accept the largest request possible. The goal is to make the security layer, web server, connector, backend, and application agree on the legitimate traffic they need to support.

How ActSupport can help with ModSecurity upload failures

ActSupport can troubleshoot the complete request path when ModSecurity, Apache, proxy connectors, or backend infrastructure prevents legitimate uploads from reaching an application. Infrastructure teams can correlate security events with Apache behavior, connector activity, backend logs, configuration scope, and resource utilization to identify the first layer that interrupts the request.

For organizations operating production hosting and cloud environments, this approach is useful for managed server support services, outsourced server management, cloud infrastructure management services, Linux server management services, and 24/7 server management services where application requirements must remain aligned with the underlying infrastructure.

Final takeaway

SecRequestBodyLimit should be sized around the largest legitimate complete HTTP request rather than the raw file size alone. SecRequestBodyNoFilesLimit should remain appropriately restrictive for non-file request data, while memory-buffering behavior must be considered according to the ModSecurity version in use.

For a 25 MB multipart upload, a 30 MB request-body ceiling can provide practical headroom, but the correct value ultimately depends on the complete request structure and application architecture.

The safest production approach is to verify the effective configuration, identify the first failing layer, configure the smallest limit that satisfies the application, preserve appropriate ModSecurity protections, and validate the upload from the client through Apache and the backend application.