feat(backend): support compressed request bodies with zip-bomb safety…

[adepoju2006]

Close #1137

Summary

Adds support for compressed request bodies (gzip/deflate) so clients sending large JSON payloads — bulk operations, evidence metadata — can reduce upload bandwidth. Decompression is guarded with strict safety limits to prevent zip-bomb attacks.

This is inbound request-body decompression. It does not change the existing outbound response compression in main.ts.

How it works

Express's body parser already inflates gzip/deflate bodies, and body-parser/raw-body enforce the size limit against the decompressed stream — aborting with 413 the moment inflated output exceeds the limit, without fully buffering. This PR leverages that battle-tested path and adds an explicit policy layer on top:

• A new RequestDecompressionGuard middleware runs before body parsing and:
  • allows only gzip / deflate / identity encodings,
  • rejects unsupported encodings (e.g. br) with 415,
  • rejects stacked encodings (gzip, gzip — a nested-bomb vector) with 415,
  • rejects all compressed bodies with 415 when the feature is disabled.
• The body parser is wired with inflate + a limit equal to the configured max decompressed size (zip-bomb cap).

Changes

File	Change
src/common/middleware/request-decompression.middleware.ts	New guard middleware + typed error codes
src/main.ts	Register guard; wire inflate + decompressed-size limit into body parsers
src/config/configuration.ts	New compression.request config (enabled, allowedEncodings, maxDecompressedSize)
src/config/env.validation.ts	Joi validation for compression env vars
.env.example	Documented compression env vars
docs/REQUEST_COMPRESSION.md	Usage, supported encodings, safety limits, config, error reference
src/common/middleware/request-decompression.middleware.spec.ts	Test suite (10 tests)

Configuration

Env var	Default	Description
REQUEST_DECOMPRESSION_ENABLED	true	When false, any non-identity Content-Encoding → 415
REQUEST_ALLOWED_ENCODINGS	gzip,deflate	Allow-list of accepted request encodings
REQUEST_MAX_DECOMPRESSED_SIZE	JSON_BODY_LIMIT	Max decompressed body size; enforced with 413

Acceptance Criteria

• Compressed request support added with safety limits
• Tests verify rejected zip-bomb scenarios

Testing

All 10 tests pass; production build typechecks; lint + prettier clean.

• gzip and deflate zip bombs (tiny payload inflating to ~10MB vs 1mb limit) → 413
• valid gzip/deflate bodies within limit inflate correctly → 200
• unsupported (br), stacked, and disabled-feature encodings → 415
• plain / identity bodies pass through unchanged

# Send a gzip-compressed JSON request
gzip -c payload.json | curl -X POST https://api.nestera.io/api/v2/<endpoint> \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -H "Content-Encoding: gzip" \
  --data-binary @-

Notes

• No changes to outbound response compression.
• Backwards compatible: uncompressed requests behave exactly as before.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
nestera	Skipped		Jun 30, 2026 8:19am

[drips-wave]

@adepoju2006 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits