Rules Hub
Coding Rules Library
Rule priority, scope & exceptions
Use this to align rules with the senior-level structure (P0/P1/P2, scope, exceptions/tradeoffs).
Set an explicit, tight request body size limit on every body-accepting endpoint
Configure a payload size cap (Express body-parser `limit`, Next.js `api.bodyParser.sizeLimit`, Nest `bodyLimit`) scoped to the real expected size, instead of relying on framework defaults or copy-pasting a large limit everywhere.
Bad example
| 1 | // Express: default-ish or oversized limit applied globally |
| 2 | app.use(express.json()); // default 100kb but applied to EVERY route, incl. tiny ones |
| 3 |
|
| 4 | // Next.js API route that only receives a small JSON form, |
| 5 | // but copy-pasted the upload route's limit: |
| 6 | export const config = { |
| 7 | api: { bodyParser: { sizeLimit: '10mb' } }, |
| 8 | }; |
Explanation (EN)
Applying one large or implicit limit everywhere means a tiny JSON endpoint will happily buffer a 10MB payload. An attacker can fan out many large-but-valid requests to consume memory and parsing CPU. The limit should reflect what each endpoint actually needs.
Objašnjenje (HR)
Primjena jedne velike ili implicitne granice svugdje znači da će mali JSON endpoint rado bufferirati 10MB payload. Napadač može poslati mnogo velikih ali valjanih zahtjeva da potroši memoriju i CPU za parsiranje. Granica treba odražavati ono što svaki endpoint stvarno treba.
Good example
| 1 | // Express: tight per-route limits sized to the payload |
| 2 | app.post('/comments', express.json({ limit: '16kb' }), createComment); |
| 3 | app.post('/avatar', express.raw({ type: 'image/*', limit: '2mb' }), uploadAvatar); |
| 4 |
|
| 5 | // Next.js: keep the large limit ONLY on the route that needs it |
| 6 | export const config = { |
| 7 | api: { bodyParser: { sizeLimit: '32kb' } }, // small form route |
| 8 | }; |
| 9 | // uploads: bodyParser:false + stream to storage with a size guard |
Explanation (EN)
Each endpoint declares a limit matching its real payload, so text routes reject anything larger than a few KB while only upload routes allow MBs — and even those should disable the buffering body parser and stream with a size guard. This bounds memory/CPU per request to what the feature legitimately needs.
Objašnjenje (HR)
Svaki endpoint deklarira granicu koja odgovara njegovom stvarnom payloadu, pa tekstualne rute odbijaju sve veće od par KB dok samo upload rute dopuštaju MB-e — a i te bi trebale isključiti bufferirajući body parser i streamati uz provjeru veličine. Time se memorija/CPU po zahtjevu ograničavaju na ono što feature legitimno treba.
Exceptions / Tradeoffs (EN)
File-upload and import endpoints legitimately need larger limits, but pair them with streaming (disable the buffering parser), an early Content-Length check, and storage-side scanning rather than buffering the whole body in app memory.
Iznimke / Tradeoffi (HR)
Endpointi za upload datoteka i import legitimno trebaju veće granice, ali ih uparite sa streamingom (isključite bufferirajući parser), ranom provjerom Content-Length i skeniranjem na strani pohrane umjesto bufferiranja cijelog tijela u memoriji aplikacije.