From 9db0813dafd42a54fc4841a604f5d3dc8113ddaa Mon Sep 17 00:00:00 2001 From: Prajwal Raj Date: Tue, 1 Sep 2026 05:25:17 +0530 Subject: [PATCH] fix: measure GBFS response cap in bytes, not string length (#45) * fix: measure GBFS response cap in bytes, not string length The 5 MB cap compared GBFS_MAX_BODY_BYTES against body.length, which is the string's UTF-16 code-unit count rather than its byte size. Those match for ASCII but diverge for multi-byte payloads, so a large non-ASCII response could slip past the cap. Switched to Buffer.byteLength. Closes #32 * docs(changelog): move the GBFS byte-cap entry into the current Unreleased section --------- Co-authored-by: Bilawal Sidhu <106619546+bilawalsidhu@users.noreply.github.com> Co-authored-by: Bilawal Sidhu --- CHANGELOG.md | 7 +++++++ vite.config.js | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 944bffe..a7624b0 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -13,6 +13,13 @@ of current runtime behavior, see [`docs/CURRENT-STATE.md`](docs/CURRENT-STATE.md global detections while reporting each dropped source twice, once as successful with its real count and once as failed. +### Security + +- GBFS proxy body-size cap now measures the response in bytes + (`Buffer.byteLength`) instead of JavaScript string length, so the + `GBFS_MAX_BODY_BYTES` limit holds for multi-byte payloads and cannot be + overrun by non-ASCII upstream responses. + ## [0.1.0] — 2026-08-31 — One-click install, keyless boot, Provider Settings ### Added diff --git a/vite.config.js b/vite.config.js index 7a7e6c0..6edefe8 100644 --- a/vite.config.js +++ b/vite.config.js @@ -3373,7 +3373,7 @@ function gbfsProxy() { return; } const body = await upstream.text(); - if (body.length > GBFS_MAX_BODY_BYTES) { + if (Buffer.byteLength(body, 'utf8') > GBFS_MAX_BODY_BYTES) { res.writeHead(502, { 'Content-Type': 'application/json', 'Cache-Control': 'no-store' }); res.end(JSON.stringify({ error: 'GBFS upstream response too large' })); return;