fix(server): bound request body size to prevent upload memory DoS #97

Merged

icub3d merged 3 commits from feature/80-body-size-limit into main 2026-07-09 03:05:56 +00:00

Conversation 0 Commits 3 Files changed 3 +58 -1

icub3d commented 2026-07-08 03:45:29 +00:00

Owner

Copy link

Summary

Fixes #80. Multipart uploads bypass axum's DefaultBodyLimit, and the handlers buffered each field via field.bytes() with the max_file_size check applied only after the whole field was in memory. With no RequestBodyLimitLayer configured, a single huge field — or many fields in one request (the attachment loop accumulates) — could stream unbounded bytes into memory.

Fix

Add a RequestBodyLimitLayer (tower-http limit feature) sized to max_file_size + 8 KiB framing overhead, applied to the whole router. This caps the entire request body at the HTTP layer, so no field can exceed what we are willing to buffer, and returns 413 Payload Too Large (immediately when Content-Length exceeds the cap). JSON/text endpoints stay bounded by axum's smaller DefaultBodyLimit.

Note: the cap bounds the whole request, so a single upload request is effectively bounded to one max-size file plus framing. This matches the issue's concern about the multi-field accumulation; a dedicated multi-file budget can be a follow-up if needed.

Tests

• oversized_request_body_is_rejected: over-limit body → 413 (before auth/routing); a small body is not rejected.

Full server suite green (116 tests); clippy -D warnings clean.

Closes #80

## Summary Fixes #80. Multipart uploads bypass axum's `DefaultBodyLimit`, and the handlers buffered each field via `field.bytes()` with the `max_file_size` check applied only *after* the whole field was in memory. With no `RequestBodyLimitLayer` configured, a single huge field — or many fields in one request (the attachment loop accumulates) — could stream unbounded bytes into memory. ## Fix Add a `RequestBodyLimitLayer` (tower-http `limit` feature) sized to `max_file_size + 8 KiB` framing overhead, applied to the whole router. This caps the entire request body at the HTTP layer, so no field can exceed what we are willing to buffer, and returns `413 Payload Too Large` (immediately when `Content-Length` exceeds the cap). JSON/text endpoints stay bounded by axum's smaller `DefaultBodyLimit`. Note: the cap bounds the *whole* request, so a single upload request is effectively bounded to one max-size file plus framing. This matches the issue's concern about the multi-field accumulation; a dedicated multi-file budget can be a follow-up if needed. ## Tests - `oversized_request_body_is_rejected`: over-limit body → 413 (before auth/routing); a small body is not rejected. Full server suite green (116 tests); `clippy -D warnings` clean. Closes #80

icub3d added 1 commit 2026-07-08 03:45:29 +00:00

fix(server): bound request body size to prevent upload memory DoS ... f4012bf7c7

Multipart uploads bypass axum's DefaultBodyLimit and were buffered field
by field via field.bytes() with the max_file_size check applied only after
the full field was in memory. No RequestBodyLimitLayer was configured, so a
single large field or many fields could stream unbounded bytes into memory.

Add a RequestBodyLimitLayer sized to max_file_size + 8 KiB framing overhead
(enabling tower-http's "limit" feature). This caps the whole request at the
HTTP layer, so a field can never exceed what we're willing to buffer. JSON
and text endpoints remain bounded by axum's smaller DefaultBodyLimit.

Test: an over-limit body returns 413 before auth/routing; a small body is
not rejected.

Closes #80

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

icub3d added the

area:api

type:bug

labels 2026-07-08 03:45:32 +00:00

icub3d added 1 commit 2026-07-09 03:01:26 +00:00

Merge branch 'main' into feature/80-body-size-limit ... 884910a968

# Conflicts:
#	server/src/main.rs

icub3d added 1 commit 2026-07-09 03:05:47 +00:00

Merge branch 'main' into feature/80-body-size-limit ... fde99a0117

# Conflicts:
#	server/src/main.rs

icub3d merged commit e95fa022bc into main 2026-07-09 03:05:56 +00:00

icub3d deleted branch feature/80-body-size-limit 2026-07-09 03:05:57 +00:00

icub3d referenced this pull request from a commit 2026-07-09 03:05:58 +00:00

Merge pull request 'fix(server): bound request body size to prevent upload memory DoS' (#97) from feature/80-body-size-limit into main

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

area:api

Backend endpoints, REST, DB, Gateway

  

area:core

Shared Rust logic, crypto, Tauri shell

  

area:docs

Documentation, OpenAPI specs, architecture

  

area:infra

Deployment, Docker, build tools

  

area:ux

Frontend UI, React components, Tailwind

  

dependencies

Pull requests that update a dependency file

  

documentation

Improvements or additions to documentation

  

duplicate

This issue or pull request already exists

  

good first issue

Good for newcomers

  

help wanted

Extra attention is needed

  

invalid

This doesn't seem right

  

question

Further information is requested

  

rust

Pull requests that update rust code

  

status:complete

Feature fully implemented

  

status:partial

Partially implemented (server done, client pending)

  

status:planned

Not yet started

  

type:bug

Bug fixes

  

type:design

Architectural changes, major design decisions

  

type:feature

New features

  

type:infra

Infrastructure and CI/CD changes

  

type:refactor

Code improvements without behavioral changes

  

type:refactor

Code improvements without behavioral changes

  

type:research

Spikes, investigating new tech

  

type:ux

User experience improvements

  

wontfix

This will not be worked on

No labels

area:api

area:core

area:docs

area:infra

area:ux

dependencies

documentation

duplicate

good first issue

help wanted

invalid

question

rust

status:complete

status:partial

status:planned

type:bug

type:design

type:feature

type:infra

type:refactor

type:refactor

type:research

type:ux

wontfix

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

icub3d/decentcom!97

No description provided.