Neither framework is strictly stricter. Express limits JSON bodies to 100kb and Fastify to 1 MiB, but Fastify caps route parameters, rejects poisoned JSON keys and offers a stricter validator out of the box. Both default trust proxy off. Set every limit explicitly so the answer does not depend on defaults.
The comparison
All values below come from the official documentation fetched for this post. Check the docs for your installed versions.
| Control | Express (body-parser and core) | Fastify |
|---|---|---|
| Body size limit | 100kb | 1048576 bytes (1 MiB) |
| Form parameter count | parameterLimit 1000 | Not applicable, parsed by plugin |
| Route parameter length | Not covered in the docs reviewed | maxParamLength 100 |
| Trust proxy | false | false |
| Request time limit | Inherited from Node, 300000 ms | requestTimeout 0, no limit |
| Connection timeout | Inherited from Node | connectionTimeout 0 |
JSON __proto__ and constructor keys | Not covered in the docs reviewed, so test it | error by default |
| Built in schema validation | None | Ajv, with documented defaults |
What stands out
Timeouts. Node's own server default for requestTimeout is 5 minutes. Fastify's documented default is 0, meaning no limit, and it recommends a non zero value without a proxy. So an Express app on plain Node gets a limit that a Fastify app does not unless you set one. Details in Node.js HTTP server timeouts.
Body size. A ten fold gap. If you migrate between them, check this first. See the single framework posts on Express and Fastify.
Prototype poisoning. Fastify's JSON parsing rejects those keys by default. For Express, the docs reviewed do not describe an equivalent option, so test how your JSON parser and merge code behave. See Fastify and the proto key.
Validation. Fastify ships with schema validation that can coerce, default and strip data. Express has no built in validator, so teams add one. Either way, validation needs to be written route by route.
Settings that are the same on both
Trust proxy is off by default in both, so behind a balancer you have to configure it. Neither framework rate limits for you. Add a limiter, and share its store across instances.
A checklist to apply to either
- Body limit set explicitly, smaller than the default if your payloads are small.
- Header and request timeouts set on the server and the proxy.
- Trust proxy set to your real proxy chain.
- Schema validation on every route, with unknown fields rejected.
- Rate limits on login and other sensitive routes.
- Error handler that returns generic messages in production.
- Dependencies scanned and the runtime on a supported release.
Broader framework comparisons are in comparing Node.js frameworks for security. The right choice usually depends more on how consistently your team applies controls than on defaults.
Safeguard's SBOM and dependency scanning works the same for either framework, and reachability analysis helps prioritize advisories. Free scan: gold.safeguard.sh/scan.
Quick check
Should I pick a framework based on these defaults?
Not on its own. You will override most of them anyway, so choose on fit and team habits.
Why is Fastify's requestTimeout 0?
Its docs set the default to no limit and recommend a non zero value such as 120 seconds when running without a reverse proxy.
Sources
- body-parser README
- Fastify Server reference
- Node.js http documentation
- Express behind proxies
- Fastify Validation and Serialization reference
Last reviewed: 19 October 2026.
