Express and the Node.js runtime

`X-Powered-By: Express` — weight 90.

`X-Powered-By` naming Koa, Hapi, Nest or Sails — weight 85.

A `Server` header naming Node.js or Express — weight 80.

A `connect.sid` session cookie — weight 70.

All of these are server-side signals. React, Next.js or any other script in the page are never used, because they say nothing about what runs the server.

A server that removed `X-Powered-By` and renamed its session cookie leaves no public trace of its runtime.

In that case the runtime check returns not verifiable, rather than guessing from the front end.

That is the common case on well-configured sites, and it is not a failure of the site.

The same rule applies to containers and orchestration, which are never inferred from any public signal.

The security best-practices guide notes that Express sends the `X-Powered-By` header by default and shows `app.disable('x-powered-by')` to turn it off.

It adds that disabling the header does not stop a sophisticated attacker from identifying the server — the point is to reduce fingerprinting, not to hide.

It recommends not using the default session cookie name, for the same fingerprinting reason, and the express-session documentation gives that default as `connect.sid`.

It also recommends setting the cookie security options explicitly rather than relying on defaults.

`X-Powered-By: Express` does not carry a version, and none is shown.

When a header does carry a version string, the version list reports exactly that string and nothing inferred from it.

A detected runtime is an inventory fact; it is not presented as a vulnerability.

`technology.nodejs` reports Node.js only from a server signature, and is not verifiable otherwise.

`security.server_disclosure` reports `X-Powered-By` and similar headers.

`cookies.inventory`, `cookies.secure`, `cookies.httponly` and `cookies.samesite` report the session cookie and its flags.

`technology.versions` lists versions only when a header publishes one.

Express's security guide recommends Helmet, a middleware that sets security-related response headers.

By default Helmet sets headers including Content-Security-Policy, Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy, Referrer-Policy, Strict-Transport-Security, X-Content-Type-Options and X-Frame-Options, and it removes `X-Powered-By`.

An Express site sending that recognisable set of headers is very likely using Helmet — and one sending none of them is likely not.

For cookies, the guide lists the options to set explicitly: `secure`, `httpOnly`, `domain`, `path` and `expires`.

It also states that Express 2.x and 3.x are no longer maintained, which matters for an old application still running them.

The guide asks for login endpoints to be protected against brute force, blocking by consecutive failures for a user name and IP address and by failures from one address over a long period.

It recommends a rate-limiting package for this and points to an example of login protection.

It stresses that an application is only as secure as its weakest dependency, and asks for dependencies to be checked for known vulnerabilities.

From outside, an audit sees rate-limit headers and responses where they exist; the dependency tree is not observable.