Secure Node and Express APIs Generated by AI

Direct answer: Secure a generated Express API by defining one request contract for each route: bound parsing, authentication, resource authorization, service work, and sanitized errors. Configure trust proxy from the real ingress topology, use a production session store and secure cookies, apply route-aware rate limits, keep Express and dependencies current, and test direct cross-account requests on the deployed path.

Express 5, Node.js 26, proxy, session, and permission-model behavior in this guide was reviewed against official documentation on July 17, 2026. Match every setting to the versions and ingress used by the application.

Generated Express code often contains plausible middleware without a consistent security contract. One router validates JSON, another trusts req.body. One handler checks for a session, another loads an object by ID without checking its workspace. A broad trust proxy setting can then turn a caller-controlled forwarding header into the address used for rate limits or secure-cookie decisions.

The vibe coding security guide treats the deployed request path as the target. For Express, that includes the reverse proxy and session store, not only app.js.

Define the route contract before middleware

For each public route, write the stages in execution order:

1. reject unsupported methods and oversized bodies;
2. parse and validate path, query, headers, and body;
3. establish a verified principal;
4. load current membership or role;
5. authorize the exact resource and action;
6. perform bounded service and database work;
7. return a minimal response;
8. convert expected and unexpected failures to safe errors.

Global middleware can set headers, assign request IDs, and parse a bounded content type. Authentication and authorization may be global for a private router or explicit per route. The important property is that no sensitive handler can be reached before its required checks, and no error handler sends a stack or private provider message to the client.

The risky pattern: authenticated means authorized

Vulnerable pattern. Any signed-in user can load a project by identifier.

app.get("/projects/:id", requireSession, async (req, res) => {
  const project = await db.project.findUnique({
    where: { id: req.params.id },
  })

  if (!project) return res.sendStatus(404)
  return res.json(project)
})

The session proves only that a user signed in. It does not prove membership in the project’s workspace. A generated interface may link only to the caller’s projects, while a direct request supplies another valid ID.

AI code misses this because examples usually use one account and one database fixture. The route works, TypeScript passes, and the screen looks correct. No generated happy-path test asks what Account B receives for Account A’s project.

Scope the query to current membership

Validate identifiers, load current server-side membership, and include the tenant boundary in the data query. Return an explicit DTO rather than the entire row.

const paramsSchema = z.object({
  workspaceId: z.string().uuid(),
  projectId: z.string().uuid(),
})

app.get("/workspaces/:workspaceId/projects/:projectId", requireSession, async (req, res, next) => {
  try {
    const input = paramsSchema.parse(req.params)
    const member = await requireActiveMember({
      userId: req.user.id,
      workspaceId: input.workspaceId,
    })

    const project = await db.project.findFirst({
      where: {
        id: input.projectId,
        workspaceId: member.workspaceId,
      },
      select: { id: true, name: true, status: true },
    })

    if (!project) return res.sendStatus(404)
    return res.json(project)
  } catch (error) {
    return next(error)
  }
})

This pattern narrows one read. Updates also need a whitelist of mutable fields and a transaction-safe policy check. Deletes may need last-owner protection, audit records, or retention. Shared projects need a membership model rather than a single ownerId. Keep these decisions in a service or policy seam so routes do not invent different definitions of access.

The server-side authorization guide covers those policy choices in depth.

Bound parsing and rates by route cost

Set explicit JSON and form limits based on the largest valid request. Reject unsupported content types before allocating or parsing large bodies. Validate arrays, strings, nested objects, unknown fields, and numeric ranges, not only the top-level shape.

Rate limits should reflect the protected action. Login attempts, password resets, report exports, expensive searches, and inexpensive reads do not have the same cost or abuse key. A global request count can help availability, but it does not replace account-aware limits, concurrency controls, provider quotas, or idempotency.

Choose the client address only after the proxy model is correct. The rate-limiting guide for AI apps explains composite keys and failure behavior.

Configure proxy trust from a topology

Express documents that trust proxy changes how req.ip, req.ips, req.hostname, and req.protocol use forwarded headers. Before setting it, draw every allowed path:

Internet client -> edge proxy -> regional load balancer -> Express
Health checker  -> regional load balancer -> Express

Confirm which hop overwrites X-Forwarded-For, X-Forwarded-Host, and X-Forwarded-Proto. Configure known proxy addresses or an exact hop policy only when every path has that shape. A numeric hop count can fail if a shorter route reaches the app. true is unsafe when the first trusted proxy does not remove client-supplied values.

In a test environment, send forged forwarded headers through each ingress path. Confirm Express derives the expected client address, host, and scheme. Then verify that secure cookies, redirects, logs, and rate limits use the same interpretation. Never copy app.set("trust proxy", 1) from a framework example without proving one trusted hop exists on every path.

Handle sessions and cookies as production state

Express documentation says the default express-session MemoryStore is not designed for production. Use a maintained shared store that supports expiry, concurrency, cleanup, and the application’s failure policy. A store outage should not silently turn a private route into an anonymous route.

Use a non-default cookie name and set HttpOnly, Secure, a deliberate SameSite value, narrow Path, and the smallest useful lifetime. Choose SameSite from real login, OAuth, embedded, and cross-origin flows. If HTTPS terminates at a proxy, secure-cookie behavior depends on correct proxy trust.

Rotate the session identifier after sign-in and privilege changes, invalidate it on sign-out, and bound parallel sessions if the product requires that control. Never store provider secrets or excessive personal data in a client-readable cookie.

Use headers, safe errors, and current dependencies

Helmet sets a useful group of security-related headers, but its defaults must be tested with the application. A Content Security Policy can break scripts or be weakened by broad allowances. API responses still need correct cache and content-type headers.

Place the final not-found and error middleware after routes. Log a request ID and bounded diagnostic context through the application’s logger. Return a generic message. Do not send stack traces, SQL fragments, filesystem paths, session contents, provider bodies, or secrets to clients.

Keep Node, Express, session middleware, validators, database clients, and transitive packages on supported versions. Review lockfile changes and security advisories. A dependency audit finds known package issues; it does not test resource authorization or proxy behavior.

Node’s stable permission model can restrict process capabilities such as filesystem, network, child-process, worker, and inspector access. Node describes it as a seat belt for trusted code and states that malicious code can bypass it. Use it as defense in depth where compatible, alongside operating-system or container isolation. It is not a sandbox for untrusted packages and not application authorization.

The browser-local AI app security checklist can organize these checks. It cannot inspect middleware order, the session store, the real proxy chain, dependency reachability, or deployed negative-test results.

Verify the full request path safely

Use an authorized test environment and fake tenant records.

1. Call every sensitive route signed out and expect denial.
2. As Account B, request Account A’s IDs for reads, updates, deletes, exports, and uploads.
3. Send malformed IDs, unknown fields, duplicate keys, unsupported types, oversized bodies, and repeated expensive requests.
4. Forge forwarding headers through every documented ingress path.
5. Stop the session store and a downstream provider to confirm private routes fail safely and errors remain bounded.
6. Inspect cookies, headers, JSON errors, logs, and caches for secrets or cross-user data.
7. Repeat the tests against the release candidate, not only a direct local port that bypasses the proxy.

A passing test supports the named route, identities, deployment, and proxy configuration. It does not prove every middleware branch, dependency, business rule, or future release is safe.

Sources

• Express: Production security best practices
• Express: Behind proxies
• Express session: Documentation
• Node.js: Permissions
• OWASP: API Security Top 10
• OWASP: Authorization Cheat Sheet