Attachment Size Limit

What Attachment Size Limits Do

Attachment size limits are a basic intake control. They define the maximum file size that a signer upload can accept, which helps keep evidence collection predictable, reduces processing overhead, and avoids oversized files consuming unnecessary storage or bandwidth.

In practice, this control sits at the boundary between user convenience and system stability. A limit that is too low can block legitimate evidence or force resubmission, while a limit that is too high can create performance bottlenecks and enlarge the attack surface for abusive uploads.

Why Size Limits Matter for Secure Uploads

File size is not just a capacity issue. Large uploads can slow request handling, increase queue backlogs, and make it harder to enforce downstream scanning, validation, and retention rules. They also create a simple abuse path for denial of service through repeated large submissions or by using large files to stress temporary storage and processing pipelines.

Good upload design treats the size limit as one layer in a broader control set, alongside content validation, type checking, and storage handling. A well-chosen limit narrows exposure without relying on the file’s extension or declared MIME type, which are not reliable security signals on their own.

How Organisations Set and Enforce the Limit

The effective limit should be enforced as early as possible, ideally before the application fully accepts or buffers the file. That reduces wasted compute and helps ensure the application, reverse proxy, and storage layer all agree on the same rule.

Teams usually set the limit from the actual evidence workflow, not from arbitrary convenience. A signer upload should accommodate expected document formats and normal business use, but it should still reject unusually large files that do not belong in the process. In well-governed upload flows, the size limit is part of the documented contract for the feature, not an incidental default.

For file-upload-specific controls, Secure File Upload Handling Guide covers how size limits fit into layered upload protection, while OWASP API Top 10 API4 Unrestricted Resource Consumption Guide explains why quotas and upload caps matter when request handling can be abused for resource exhaustion.

Operational Consequences and Monitoring

Attachment size limits should be observable in logs and metrics. Rejection rates, retry patterns, and unusually frequent near-limit uploads can show whether the cap is too strict, whether users are struggling with the workflow, or whether someone is probing the system with oversized content.

When upload limits are paired with scanning and quarantine, the size threshold can also reduce downstream load. Smaller, bounded files are easier to inspect, more predictable to process, and less likely to trigger timeout or resource exhaustion problems in malware scanning, archival handling, or evidence pipelines.

The broader security context is the same reason file upload controls are treated as a security concern in OWASP API Security Top 10, and the same principle appears in NIST SP 800-53 Rev 5 Security and Privacy Controls through controls for system integrity, access control, and configuration discipline.

Risk and Threat Considerations

Attachment size limits matter because oversized uploads can be used to degrade performance, exhaust storage, or disrupt the signing workflow. They also reduce the chance that a malformed or abusive file becomes a persistence mechanism inside an otherwise routine business process.

Failure mechanism: An attacker or careless user submits large files repeatedly, or uses unusually large content to consume request capacity, temporary storage, scanning bandwidth, or downstream processing resources until the upload path becomes unreliable.

Impact: The signing workflow can slow down, reject legitimate evidence, or become unavailable, and the organisation may lose visibility into which uploads were accepted, rejected, or only partially processed.

Practitioner Guidance

What to watch for: Set the limit from the actual document types the workflow needs, then validate that the same ceiling is enforced consistently across the front end, application layer, and storage path. If users routinely hit the cap, that is usually a workflow design issue, not a reason to remove the control.

Practitioner takeaway: The best size limit is one that users rarely notice during normal work but attackers cannot turn into a resource-exhaustion path.

Related resources from NHI Mgmt Group

• What is the difference between an attachment allowlist and a file count limit in a signing workflow?
• Hard Capture Size Limit
• IAM Policy Size Limit
• Attachment File Limit