Security: Fix for HTTP request smuggling in API end-point

[AjayPAnand]

Description

Fixes HTTP Request Smuggling vulnerability identified on the /api/activity_types/ endpoint (and related endpoints). The backend was responding inconsistently to malformed HTTP requests (returning HTTP 419, 501, and other errors), indicating misaligned request parsing between the Nginx reverse proxy and the backend API server.

This change hardens the Nginx proxy configuration to enforce consistent HTTP/1.1 request handling, reject ambiguous headers, and buffer requests before forwarding — eliminating the desynchronisation window that enables smuggling attacks.

Note on Puma upgrade (Gemfile / Gemfile.lock changes)

Puma is bumped to >= 6.4.3 as a complementary backend-side defence against HTTP Request Smuggling.
Older versions of Puma had known weaknesses in their HTTP/1.1 request parser specifically around handling ambiguous Content-Length and Transfer-Encoding headers, which could allow a malformed request to be interpreted differently by Puma than by the Nginx reverse proxy in front of it. This parser desynchronisation is the core mechanism behind request smuggling attacks.

Puma 6.4.3+ includes stricter request parsing that rejects or errors on ambiguous framing, meaning even if a smuggled request somehow bypassed the Nginx layer, the backend itself would no longer silently accept and process it. This gives defence-in-depth: Nginx blocks at the proxy level, and Puma refuses to process anything ambiguous at the app server level.

Fixes # (issue)

Type of change

Changes made

production/shared-files/proxy-nginx.conf

• ignore_invalid_headers on — instructs Nginx to silently drop unrecognised or malformed headers rather than forwarding them to the backend, preventing header injection via ambiguous fields.
• client_header_timeout 10s / client_body_timeout 10s — limits how long Nginx waits for a slow or incomplete request, closing the connection before a partial/smuggled request can be processed.
• proxy_set_header Connection "" — clears the Connection header before forwarding, preventing hop-by-hop header smuggling between the proxy and backend.
• proxy_http_version 1.1 — forces HTTP/1.1 between Nginx and the backend, enabling keep-alive and ensuring consistent chunked-encoding handling.
• proxy_request_buffering on / proxy_buffering on — Nginx fully buffers the client request before forwarding, ensuring the backend only ever receives complete, validated requests — eliminating the desync window.

Please delete options that are not relevant.

• [ x ] Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [ x ] This change requires a documentation update

How Has This Been Tested?

1. Start the application and confirm all Docker containers are running:

    docker compose up
    docker ps

2. Open Burp Suite and configure your browser to proxy through it.
3. Navigate to the application and capture a request to /api/activity_types/.
4. In Burp Suite Repeater, send the captured request normally — confirm a valid HTTP/1.1 200 OK response.
5. Craft and send malformed variants (mixed Content-Length/Transfer-Encoding, partial headers, duplicate headers) — confirm Nginx now returns a consistent 400 Bad Request rather than 419 CUSTOM, 501 Not Implemented, or partial responses.
6. Confirm normal application functionality is unaffected.

• [ x ] Test A - Normal request to /api/activity_types/ returns expected response
• [ x ] Test B - Malformed/smuggled requests are rejected with a consistent error, not passed to backend, Screenshots attached for reference.

Screenshots of results below:
Malformed requests send to the end point and validated the responses.

Security context

Vulnerability: HTTP Request Smuggling (HRS)
Affected endpoint: http://localhost:3000/api/activity_types/
Risk: Significant impact / Moderate likelihood
Discovery method: Burp Suite Repeater - malformed requests produced inconsistent responses (HTTP 419, 501, partial errors), indicating frontend/backend request parsing desynchronisation.

References:

https://portswigger.net/web-security/request-smuggling

Checklist:

• [ x ] My code follows the style guidelines of this project
• [ x ] I have performed a self-review of my own code
• [ x ] I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation if appropriate
• [ x ] My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• I have created or extended unit tests to address my new additions
• New and existing unit tests pass locally with my changes
• [ x ] Any dependent changes have been merged and published in downstream modules

If you have any questions, please contact @macite or @jakerenzella.