How do you build a secure API gateway in Node.js?

A secure Node.js API gateway terminates TLS, authenticates every request, validates input, limits request rates, sets safe headers and passes only authorized calls to backend services. Treat it as the first enforcement point, not the only one. Check object-level authorization again in each service.

What is the gateway's job?

A gateway sits in front of your services and applies shared rules once instead of in every service. Typical rules are authentication, rate limiting, request validation, routing and logging. That makes it a high-value target, so it must be small, boring and well tested.

Use the OWASP API Security Top 10 (2023) as the checklist. Its list is: broken object level authorization, broken authentication, broken object property level authorization, unrestricted resource consumption, broken function level authorization, unrestricted access to sensitive business flows, server side request forgery, security misconfiguration, improper inventory management and unsafe consumption of APIs.

Which items can a gateway handle well?

Some of those risks are natural fits:

• Broken authentication: verify tokens at the edge and reject missing or expired ones before routing.
• Unrestricted resource consumption: enforce rate limits, request size limits and timeouts.
• Security misconfiguration: set security headers, disable debug output and keep error messages generic.
• Improper inventory management: route only declared paths, so forgotten endpoints are not reachable.

Others need the services' help. Broken object level authorization means a user changes an ID in a request and reads someone else's record. OWASP says object-level checks should be considered in every function that uses an ID from the user. A gateway cannot know who owns record 4821, so the service must check.

What does the Node.js and Express guidance add?

Express's production security page lists steps that apply to a gateway built on it. Do not run Express 2.x or 3.x, which are no longer maintained. Use TLS for sensitive data, with a reverse proxy such as Nginx handling it. Do not trust user input, and validate redirect targets so the app is not an open redirect. Use Helmet, a middleware that sets security headers such as Content-Security-Policy, Strict-Transport-Security and X-Content-Type-Options. Use cookies securely, and protect login endpoints against brute-force attempts by limiting failed attempts by user and IP address.

The Express page also recommends keeping dependencies safe, and notes that an app is only as secure as its weakest dependency, with npm audit as a starting tool. For a gateway that sits in front of everything, dependency hygiene matters more than usual.

The Node.js project's own security best practices lists threats to account for, including denial of service of the HTTP server, HTTP request smuggling, prototype pollution and malicious third-party modules.

What does a minimal secure setup look like?

A short constructed sketch of the order of middleware:

const express = require('express');
const helmet = require('helmet');

const app = express();
app.disable('x-powered-by');
app.use(helmet());
app.use(express.json({ limit: '100kb' }));
// 1. rate limit by IP and by token
// 2. verify the token; reject on failure
// 3. validate the request against a schema for the route
// 4. forward to the service with an identity header the gateway set

The comments mark the order that matters: limit first so abusive traffic is cheap to reject, authenticate second, validate third, forward last. Strip any identity header a client sends, so a caller cannot pretend to be the gateway.

How to check or apply this

1. List every route the gateway exposes and delete any not in your API inventory.
2. Terminate TLS in front of Node, or configure it carefully, and redirect plain HTTP.
3. Verify tokens on every call, and keep tokens out of logs and URLs.
4. Add request size limits, timeouts and rate limits per client and per route.
5. Validate bodies and parameters against a schema, and reject unknown fields.
6. Make each backend service check object-level and function-level authorization itself.
7. Pin dependencies, run npm audit, and scan the full dependency tree in CI.
8. Log who called what, with request IDs, and alert on spikes of 401, 403 and 429 responses.

Safeguard can scan a Node.js project's dependencies and use reachability analysis to show which vulnerable packages your gateway code actually calls, through the CLI or an IDE extension.

Quick check

Sources

• OWASP API Security Top 10 2023
• Express, Production best practices: security
• Node.js, Security best practices

Last reviewed: 18 October 2026.