Security - Add server middleware h3 syntax presence checks on startup or build

[oom-]

Describe the feature

Describe the feature

Nuxt server middleware will:

[...] run on every request before any other server route to add or check headers, log requests, or extend the event's request object.
source: https://nuxt.com/docs/guide/directory-structure/server#server-middleware

CASE 1: This means that if you want to execute middleware only for specific routes, you need to include a condition that checks the path:

export default defineEventHandler(async (event) => {
    //I'm not sure about the props names, it's just to show an example here
    if (event.path == "/api/user/hello") && event.context.user.role != 'USER' && event.method != "GET") return;
    console.log("User role allowed");
});

However, this approach is not ideal as it conflicts with the auto-generation process and naming conventions of Nuxt's server/api folder. If a file is moved to a different folder and the middleware condition isn't updated accordingly, it can lead to application-breaking issues.

Luckily there is a more elegant way to do it, you can use the h3 onRequest prop on your handler (see nuxt/nuxt#23308 (reply in thread)).

CASE 2: Based on the h3 syntax we can have:

export default defineEventHandler({
    onRequest: [apiRouteAdminCheck],
   ///[...]

export default defineEventHandler({
    onRequest: [(event) => apiRouteRoleCheck(event, ["USER", "TECH"])],
   ///[...]

export default defineEventHandler({
  onRequest: [
    // Allow only specific environnement
    (event) => blockWrongEnv(event, ["DEV", "TEST"]),
    // Retrieve redis session
    useSession,
    // Check if the role of the user is correct
    (event) => apiRouteRoleCheck(event, ["RECEPTION"]),
    // Check 2FA code
    2faCheck,
  ],
   ///[...]

But this syntax brings other issues when your project starts to grow:

• Your server/api folder can become cluttered with numerous routes, making it challenging to review the onRequest middleware list in each file.
• Adding a new route often involves copying and pasting from an existing route, which increases the likelihood of forgetting to update the onRequest middleware property.
• There are no safeguards to verify that all routes are properly secured with the apiRouteAdminCheck middleware or any other required middleware.

Feature request:

• The h3 onRequest syntax would be beneficial to define a list of paths, sub-paths, methods, or files that must be validated during build or startup to ensure they include a specified set of middleware.

Current workaround:

• I'm using a pre-commit Git hook to run a script that applies regex tests to ensure the presence of the required middleware.

Inspiration?:

Here's an example of how I reimplemented an inspired Nuxt server/api route auto-generation mechanism and h3 onRequest logic in another project based on Fastify. The startup script for loading the routes also incorporates some of the checks mentioned earlier:

      const baseRoute = match?.[1]?.replaceAll("\\", "/") ?? "";
        const isAdminRoute = baseRoute.startsWith("/admin");
        const isWebhookRoute = baseRoute.startsWith("/webhooks");
        const method = match[4] as "post" | "get" | "delete" | "head" | "patch" | "put" | "options";
        const subRoute = match[5];
        const fullRoute = baseRoute + (subRoute == "index" ? "" : `/${subRoute}`);
        const middlewares = (routeObj?.opt?.preHandler as any[]) ?? [];
        const hasMiddlewares = middlewares.length > 0;
        //Admin routes are decorated with middlewareIsAdmin
        if (isAdminRoute && (!hasMiddlewares || (hasMiddlewares && !middlewares.includes(middlewareIsAdminConnected)))) {
            logger.error(`Admin route not decorated with middlewareIsAdminConnected: ${routeFile}`);
            process.exit(1);
        }

        //PATCH/PUT/POST/DELETE routes are decorated with middlewareCSRF (and in first position)
        if (!isWebhookRoute && ["post", "patch", "put", "delete"].indexOf(method) != -1 && (!hasMiddlewares || (hasMiddlewares && middlewares.indexOf(middlewareCSRF) != 0))) {
            logger.error(`POST/PATCH/PUT/DELETE route not decorated with middlewareCSRF (or not placed on first position): ${routeFile}`);
            process.exit(1);
        }

In this case, the server would fail to start if the routes were not properly decorated, preventing the exposure of admin routes or no CSRF protection.

Representing the feature:
Let's say, you want to assure on startup or on build that :

• all routes "POST" has the CSRF middleware
• all routes under /server/api/user and /server/api/admin has a isConnected middleware
• all routes under /server/api/user has a roleCheck middleware
• all routes under /server/api/admin has a adminOnly middleware
• all routes "POST" under /server/api/2FA has a twoFa middleware

There is currently no way to do it.

Raised in nitrojs/nitro after @danielroe comment

Additional information

• Would you be willing to help implement this feature?