fastify 5.4.0 → 5.5.0

package/.vscode/settings.json

@@ -0,0 +1,22 @@
+{
+  "workbench.colorCustomizations": {
+    "[GitHub Dark]": {
+      "tab.activeBackground": "#0d0d0d",
+      "tab.activeBorder": "#ffff00"
+    },
+    "activityBar.background": "#FBE7B2",
+    "activityBar.foreground": "#52358C",
+    "activityBar.inactiveForeground": "#616161",
+    "activityBar.activeBorder": "#04184d",
+    "activityBar.activeBackground": "#C3B48B",
+    "activityBar.border": "#C3B48B",
+    "titleBar.activeBackground": "#D2BE88",
+    "titleBar.activeForeground": "#52358C",
+    "titleBar.inactiveBackground": "#bdb59c",
+    "titleBar.inactiveForeground": "#616161",
+    "titleBar.border": "#C3B48B",
+    "statusBar.background": "#E9DBB7",
+    "statusBar.foreground": "#52358C",
+    "statusBar.border": "#C3B48B"
+  }
+}

package/LICENSE

@@ -1,6 +1,6 @@
 MIT License
 
-Copyright (c) 2016-2025 The Fastify Team
+Copyright (c) 2016-present The Fastify Team
 
 The Fastify team members are listed at https://github.com/fastify/fastify#team
 and in the README file.

package/SECURITY.md

@@ -1,4 +1,160 @@
 # Security Policy
 
-Please see Fastify's [organization-wide security policy
-](https://github.com/fastify/.github/blob/main/SECURITY.md).
+This document describes the management of vulnerabilities for the Fastify
+project and its official plugins.
+
+## Reporting vulnerabilities
+
+Individuals who find potential vulnerabilities in Fastify are invited to
+complete a vulnerability report via the dedicated pages:
+
+1. [HackerOne](https://hackerone.com/fastify)
+2. [GitHub Security Advisory](https://github.com/fastify/fastify/security/advisories/new)
+
+### Strict measures when reporting vulnerabilities
+
+It is of the utmost importance that you read carefully and follow these
+guidelines to ensure the ecosystem as a whole isn't disrupted due to improperly
+reported vulnerabilities:
+
+* Avoid creating new "informative" reports. Only create new
+  reports on a vulnerability if you are absolutely sure this should be
+  tagged as an actual vulnerability. Third-party vendors and individuals are
+  tracking any new vulnerabilities reported in HackerOne or GitHub and will flag
+  them as such for their customers (think about snyk, npm audit, ...).
+* Security reports should never be created and triaged by the same person. If
+  you are creating a report for a vulnerability that you found, or on
+  behalf of someone else, there should always be a 2nd Security Team member who
+  triages it. If in doubt, invite more Fastify Collaborators to help triage the
+  validity of the report. In any case, the report should follow the same process
+  as outlined below of inviting the maintainers to review and accept the
+  vulnerability.
+* ***Do not*** attempt to show CI/CD vulnerabilities by creating new pull
+  requests to any of the Fastify organization's repositories. Doing so will
+  result in a [content report][cr] to GitHub as an unsolicited exploit.
+  The proper way to provide such reports is by creating a new repository,
+  configured in the same manner as the repository you would like to submit
+  a report about, and with a pull request to your own repository showing
+  the proof of concept.
+
+[cr]: https://docs.github.com/en/communities/maintaining-your-safety-on-github/reporting-abuse-or-spam#reporting-an-issue-or-pull-request
+
+### Vulnerabilities found outside this process
+
+⚠ The Fastify project does not support any reporting outside the process mentioned
+in this document.
+
+## Handling vulnerability reports
+
+When a potential vulnerability is reported, the following actions are taken:
+
+### Triage
+
+**Delay:** 4 business days
+
+Within 4 business days, a member of the security team provides a first answer to
+the individual who submitted the potential vulnerability. The possible responses
+can be:
+
+* **Acceptance**: what was reported is considered as a new vulnerability
+* **Rejection**: what was reported is not considered as a new vulnerability
+* **Need more information**: the security team needs more information in order to
+  evaluate what was reported.
+
+Triaging should include updating issue fields:
+* Asset - set/create the module affected by the report
+* Severity - TBD, currently left empty
+
+Reference: [HackerOne: Submitting
+Reports](https://docs.hackerone.com/hackers/submitting-reports.html)
+
+### Correction follow-up
+
+**Delay:** 90 days
+
+When a vulnerability is confirmed, a member of the security team volunteers to
+follow up on this report.
+
+With the help of the individual who reported the vulnerability, they contact the
+maintainers of the vulnerable package to make them aware of the vulnerability.
+The maintainers can be invited as participants to the reported issue.
+
+With the package maintainer, they define a release date for the publication of
+the vulnerability. Ideally, this release date should not happen before the
+package has been patched.
+
+The report's vulnerable versions upper limit should be set to:
+* `*` if there is no fixed version available by the time of publishing the
+  report.
+* the last vulnerable version. For example: `<=1.2.3` if a fix exists in `1.2.4`
+
+### Publication
+
+**Delay:** 90 days
+
+Within 90 days after the triage date, the vulnerability must be made public.
+
+**Severity**: Vulnerability severity is assessed using [CVSS
+v.3](https://www.first.org/cvss/user-guide). More information can be found on
+[HackerOne documentation](https://docs.hackerone.com/hackers/severity.html)
+
+If the package maintainer is actively developing a patch, an additional delay
+can be added with the approval of the security team and the individual who
+reported the vulnerability.
+
+At this point, a CVE should be requested through the selected platform through
+the UI, which should include the Report ID and a summary.
+
+Within HackerOne, this is handled through a "public disclosure request".
+
+Reference: [HackerOne:
+Disclosure](https://docs.hackerone.com/hackers/disclosure.html)
+
+## The Fastify Security team
+
+The core team is responsible for the management of the security program and
+this policy and process.
+
+Members of this team are expected to keep all information that they have
+privileged access to by being on the team completely private to the team. This
+includes agreeing to not notify anyone outside the team of issues that have not
+yet been disclosed publicly, including the existence of issues, expectations of
+upcoming releases, and patching of any issues other than in the process of their
+work as a member of the Fastify Core team.
+
+### Members
+
+* [__Matteo Collina__](https://github.com/mcollina),
+  <https://twitter.com/matteocollina>, <https://www.npmjs.com/~matteo.collina>
+* [__Tomas Della Vedova__](https://github.com/delvedor),
+  <https://twitter.com/delvedor>, <https://www.npmjs.com/~delvedor>
+* [__Vincent Le Goff__](https://github.com/zekth)
+* [__KaKa Ng__](https://github.com/climba03003)
+* [__James Sumners__](https://github.com/jsumners),
+  <https://twitter.com/jsumners79>, <https://www.npmjs.com/~jsumners>
+
+## OpenSSF CII Best Practices
+
+[![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/7585/badge)](https://bestpractices.coreinfrastructure.org/projects/7585)
+
+There are three “tiers”: passing, silver, and gold.
+
+### Passing
+We meet 100% of the “passing” criteria.
+
+### Silver
+We meet 87% of the “silver” criteria. The gaps are as follows:
+  - we do not have a DCO or a CLA process for contributions.
+  - we do not currently document
+    “what the user can and cannot expect in terms of security” for our project.
+  - we do not currently document ”the architecture (aka high-level design)”
+    for our project.
+
+### Gold
+We meet 70% of the “gold” criteria. The gaps are as follows:
+  - we do not yet have the “silver” badge; see all the gaps above.
+  - We do not include a copyright or license statement in each source file.
+    Efforts are underway to change this archaic practice into a
+    suggestion instead of a hard requirement.
+  - There are a few unanswered questions around cryptography that are
+    waiting for clarification.

package/build/build-validation.js

@@ -43,7 +43,14 @@ const defaultInitOptions = {
   http2SessionTimeout: 72000, // 72 seconds
   exposeHeadRoutes: true,
   useSemicolonDelimiter: false,
-  allowErrorHandlerOverride: true // TODO: set to false in v6
+  allowErrorHandlerOverride: true, // TODO: set to false in v6
+  routerOptions: {
+    ignoreTrailingSlash: false,
+    ignoreDuplicateSlashes: false,
+    maxParamLength: 100,
+    allowUnsafeRegex: false,
+    useSemicolonDelimiter: false
+  }
 }
 
 const schema = {
@@ -103,6 +110,17 @@ const schema = {
     http2SessionTimeout: { type: 'integer', default: defaultInitOptions.http2SessionTimeout },
     exposeHeadRoutes: { type: 'boolean', default: defaultInitOptions.exposeHeadRoutes },
     useSemicolonDelimiter: { type: 'boolean', default: defaultInitOptions.useSemicolonDelimiter },
+    routerOptions: {
+      type: 'object',
+      additionalProperties: false,
+      properties: {
+        ignoreTrailingSlash: { type: 'boolean', default: defaultInitOptions.routerOptions.ignoreTrailingSlash },
+        ignoreDuplicateSlashes: { type: 'boolean', default: defaultInitOptions.routerOptions.ignoreDuplicateSlashes },
+        maxParamLength: { type: 'integer', default: defaultInitOptions.routerOptions.maxParamLength },
+        allowUnsafeRegex: { type: 'boolean', default: defaultInitOptions.routerOptions.allowUnsafeRegex },
+        useSemicolonDelimiter: { type: 'boolean', default: defaultInitOptions.routerOptions.useSemicolonDelimiter }
+      }
+    },
     constraints: {
       type: 'object',
       additionalProperties: {

package/docs/Guides/Delay-Accepting-Requests.md

@@ -527,11 +527,14 @@ Retry-After: 5000
 Then we attempted a new request (`req-2`), which was a `GET /ping`. As expected,
 since that was not one of the requests we asked our plugin to filter, it
 succeeded. That could also be used as a means of informing an interested party
-whether or not we were ready to serve requests (although `/ping` is more
-commonly associated with *liveness* checks and that would be the responsibility
-of a *readiness* check -- the curious reader can get more info on these
-[terms](https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-setting-up-health-checks-with-readiness-and-liveness-probes))
-here with the `ready` field. Below is the response to that request:
+whether or not we were ready to serve requests with the `ready` field. Although
+`/ping` is more commonly associated with *liveness* checks and that would be
+the responsibility of a *readiness* check. The curious reader can get more info
+on these terms in the article
+["Kubernetes best practices: Setting up health checks with readiness and liveness probes"](
+https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-setting-up-health-checks-with-readiness-and-liveness-probes).
+
+Below is the response to that request:
 
 ```sh
 HTTP/1.1 200 OK

package/docs/Guides/Ecosystem.md

@@ -199,6 +199,8 @@ section.
   Run REST APIs and other web applications using your existing Node.js
   application framework (Express, Koa, Hapi and Fastify), on top of AWS Lambda,
   Huawei and many other clouds.
+- [`@hey-api/openapi-ts`](https://heyapi.dev/openapi-ts/plugins/fastify)
+  The OpenAPI to TypeScript codegen. Generate clients, SDKs, validators, and more.
 - [`@immobiliarelabs/fastify-metrics`](https://github.com/immobiliare/fastify-metrics)
   Minimalistic and opinionated plugin that collects usage/process metrics and
   dispatches to [statsd](https://github.com/statsd/statsd).
@@ -507,6 +509,8 @@ middlewares into Fastify plugins
   [MS Graph Change Notifications webhooks](https://learn.microsoft.com/it-it/graph/change-notifications-delivery-webhooks?tabs=http).
 - [`fastify-multer`](https://github.com/fox1t/fastify-multer) Multer is a plugin
   for handling multipart/form-data, which is primarily used for uploading files.
+- [`fastify-multilingual`](https://github.com/gbrugger/fastify-multilingual) Unobtrusively
+  decorates fastify request with Polyglot.js for i18n.
 - [`fastify-nats`](https://github.com/mahmed8003/fastify-nats) Plugin to share
   [NATS](https://nats.io) client across Fastify.
 - [`fastify-next-auth`](https://github.com/wobsoriano/fastify-next-auth)
@@ -557,6 +561,9 @@ middlewares into Fastify plugins
   A set of Fastify plugins to integrate Apple Wallet Web Service specification
 - [`fastify-peekaboo`](https://github.com/simone-sanfratello/fastify-peekaboo)
   Fastify plugin for memoize responses by expressive settings.
+- [`fastify-permissions`](https://github.com/pckrishnadas88/fastify-permissions)
+  Route-level permission middleware for Fastify supports
+  custom permission checks.
 - [`fastify-piscina`](https://github.com/piscinajs/fastify-piscina) A worker
   thread pool plugin using [Piscina](https://github.com/piscinajs/piscina).
 - [`fastify-polyglot`](https://github.com/beliven-it/fastify-polyglot) A plugin to
@@ -616,6 +623,9 @@ middlewares into Fastify plugins
   Fastify Rob-Config integration.
 - [`fastify-route-group`](https://github.com/TakNePoidet/fastify-route-group)
   Convenient grouping and inheritance of routes.
+- [`fastify-route-preset`](https://github.com/inyourtime/fastify-route-preset)
+  A Fastify plugin that enables you to create route configurations that can be 
+  applied to multiple routes.
 - [`fastify-s3-buckets`](https://github.com/kibertoad/fastify-s3-buckets)
   Ensure the existence of defined S3 buckets on the application startup.
 - [`fastify-schema-constraint`](https://github.com/Eomm/fastify-schema-constraint)
@@ -734,6 +744,7 @@ middlewares into Fastify plugins
 - [`typeorm-fastify-plugin`](https://github.com/jclemens24/fastify-typeorm) A simple
   and updated Typeorm plugin for use with Fastify.
 
+
 #### [Community Tools](#community-tools)
 
 - [`@fastify-userland/workflows`](https://github.com/fastify-userland/workflows)

package/docs/Guides/Migration-Guide-V5.md

@@ -557,7 +557,6 @@ and provides a way to trace the lifecycle of a request.
 'use strict'
 
 const diagnostics = require('node:diagnostics_channel')
-const sget = require('simple-get').concat
 const Fastify = require('fastify')
 
 diagnostics.subscribe('tracing:fastify.request.handler:start', (msg) => {
@@ -583,15 +582,12 @@ fastify.route({
   }
 })
 
-fastify.listen({ port: 0 }, function () {
-  sget({
-    method: 'GET',
-    url: fastify.listeningOrigin + '/7'
-  }, (err, response, body) => {
-    t.error(err)
-    t.equal(response.statusCode, 200)
-    t.same(JSON.parse(body), { hello: 'world' })
-  })
+fastify.listen({ port: 0 }, async function () {
+  const result = await fetch(fastify.listeningOrigin + '/7')
+
+  t.assert.ok(result.ok)
+  t.assert.strictEqual(response.status, 200)
+  t.assert.deepStrictEqual(await result.json(), { hello: 'world' })
 })
 ```
 

package/docs/Guides/Recommendations.md

@@ -285,7 +285,7 @@ server {
 ## Kubernetes
 <a id="kubernetes"></a>
 
-The `readinessProbe` uses [(by
+The `readinessProbe` uses ([by
 default](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes))
 the pod IP as the hostname. Fastify listens on `127.0.0.1` by default. The probe
 will not be able to reach the application in this case. To make it work,

package/docs/Reference/Errors.md

@@ -29,6 +29,7 @@
     - [FST_ERR_CTP_INVALID_MEDIA_TYPE](#fst_err_ctp_invalid_media_type)
     - [FST_ERR_CTP_INVALID_CONTENT_LENGTH](#fst_err_ctp_invalid_content_length)
     - [FST_ERR_CTP_EMPTY_JSON_BODY](#fst_err_ctp_empty_json_body)
+    - [FST_ERR_CTP_INVALID_JSON_BODY](#fst_err_ctp_invalid_json_body)
     - [FST_ERR_CTP_INSTANCE_ALREADY_STARTED](#fst_err_ctp_instance_already_started)
     - [FST_ERR_INSTANCE_ALREADY_LISTENING](#fst_err_instance_already_listening)
     - [FST_ERR_DEC_ALREADY_PRESENT](#fst_err_dec_already_present)
@@ -299,7 +300,8 @@ Below is a table with all the error codes used by Fastify.
 | <a id="fst_err_ctp_body_too_large">FST_ERR_CTP_BODY_TOO_LARGE</a> | The request body is larger than the provided limit. | Increase the limit in the Fastify server instance setting: [bodyLimit](./Server.md#bodylimit) | [#1168](https://github.com/fastify/fastify/pull/1168) |
 | <a id="fst_err_ctp_invalid_media_type">FST_ERR_CTP_INVALID_MEDIA_TYPE</a> | The received media type is not supported (i.e. there is no suitable `Content-Type` parser for it). | Use a different content type. | [#1168](https://github.com/fastify/fastify/pull/1168) |
 | <a id="fst_err_ctp_invalid_content_length">FST_ERR_CTP_INVALID_CONTENT_LENGTH</a> | Request body size did not match <code>Content-Length</code>. | Check the request body size and the <code>Content-Length</code> header. | [#1168](https://github.com/fastify/fastify/pull/1168) |
-| <a id="fst_err_ctp_empty_json_body">FST_ERR_CTP_EMPTY_JSON_BODY</a> | Body cannot be empty when content-type is set to <code>application/json</code>. | Check the request body. | [#1253](https://github.com/fastify/fastify/pull/1253) |
+| <a id="fst_err_ctp_empty_json_body">FST_ERR_CTP_EMPTY_JSON_BODY</a> | Body is not valid JSON but content-type is set to <code>application/json</code>. | Check if the request body is valid JSON. | [#5925](https://github.com/fastify/fastify/pull/5925) |
+| <a id="fst_err_ctp_invalid_json_body">FST_ERR_CTP_INVALID_JSON_BODY</a> | Body cannot be empty when content-type is set to <code>application/json</code>. | Check the request body. | [#1253](https://github.com/fastify/fastify/pull/1253) |
 | <a id="fst_err_ctp_instance_already_started">FST_ERR_CTP_INSTANCE_ALREADY_STARTED</a> | Fastify is already started. | - | [#4554](https://github.com/fastify/fastify/pull/4554) |
 | <a id="fst_err_instance_already_listening">FST_ERR_INSTANCE_ALREADY_LISTENING</a> | Fastify instance is already listening. | - | [#4554](https://github.com/fastify/fastify/pull/4554) |
 | <a id="fst_err_dec_already_present">FST_ERR_DEC_ALREADY_PRESENT</a> | A decorator with the same name is already registered. | Use a different decorator name. | [#1168](https://github.com/fastify/fastify/pull/1168) |

package/docs/Reference/Hooks.md

@@ -189,12 +189,8 @@ specific header in case of error.
 It is not intended for changing the error, and calling `reply.send` will throw
 an exception.
 
-This hook will be executed only after
-the [Custom Error Handler set by `setErrorHandler`](./Server.md#seterrorhandler)
-has been executed, and only if the custom error handler sends an error back to the
-user
-*(Note that the default error handler always sends the error back to the
-user)*.
+This hook will be executed before
+the [Custom Error Handler set by `setErrorHandler`](./Server.md#seterrorhandler).
 
 > ℹ️ Note: Unlike the other hooks, passing an error to the `done` function is not
 > supported.

package/docs/Reference/Lifecycle.md

@@ -70,9 +70,9 @@ submitted, the data flow is as follows:
                      ★ send or return                 │                 │
                             │                         │                 │
                             │                         ▼                 │
-       reply sent ◀── JSON ─┴─ Error instance ──▶ setErrorHandler ◀─────┘
+       reply sent ◀── JSON ─┴─ Error instance ──▶ onError Hook ◀───────┘
                                                       │
-                                 reply sent ◀── JSON ─┴─ Error instance ──▶ onError Hook
+                                 reply sent ◀── JSON ─┴─ Error instance ──▶ setErrorHandler
                                                                                 │
                                                                                 └─▶ reply sent
 ```

package/docs/Reference/Request.md

@@ -237,7 +237,7 @@ const newValidate = request.compileValidationSchema(newSchema)
 console.log(newValidate === validate) // false
 ```
 
-### .validateInput(data, [schema | httpStatus], [httpStatus])
+### .validateInput(data, [schema | httpPart], [httpPart])
 <a id="validate"></a>
 
 This function validates the input based on the provided schema or HTTP part. If

package/docs/Reference/Routes.md

@@ -59,8 +59,9 @@ fastify.route(options)
   one.
 * `onRequest(request, reply, done)`: a [function](./Hooks.md#onrequest) called
   as soon as a request is received, it could also be an array of functions.
-* `preParsing(request, reply, done)`: a [function](./Hooks.md#preparsing) called
-  before parsing the request, it could also be an array of functions.
+* `preParsing(request, reply, payload, done)`: a
+  [function](./Hooks.md#preparsing) called before parsing the request, it could
+  also be an array of functions.
 * `preValidation(request, reply, done)`: a [function](./Hooks.md#prevalidation)
   called after the shared `preValidation` hooks, useful if you need to perform
   authentication at route level for example, it could also be an array of
@@ -781,7 +782,7 @@ const secret = {
 > const Fastify = require('fastify')
 >
 > const fastify = Fastify({
->   frameworkErrors: function (err, res, res) {
+>   frameworkErrors: function (err, req, res) {
 >     if (err instanceof Fastify.errorCodes.FST_ERR_ASYNC_CONSTRAINT) {
 >       res.code(400)
 >       return res.send("Invalid header provided")