nginx

A `Server` header beginning with `nginx` — weight 85, enough for a high-confidence report.

When the header includes a version, such as `nginx/1.24.0`, the version is extracted and listed exactly as published.

nginx is often a reverse proxy in front of an application or a CDN edge, so the header identifies the component that answered, not necessarily where the application runs.

It is reported as a web server, and nothing about the application behind it is inferred.

The core module documentation gives `server_tokens` a default of `on`, and describes it as enabling the emission of the nginx version on error pages and in the `Server` header.

`server_tokens off;` keeps `Server: nginx` and removes the version from the header and from error pages.

The `build` value adds the build name alongside the version.

The version is a disclosure, not a vulnerability; what matters is whether the version it reveals is maintained.

The autoindex module's `autoindex` directive defaults to `off`.

A directory listing served by nginx therefore always comes from an explicit `autoindex on;` for that location.

That makes the fix precise: remove the directive, or restrict the location, rather than hunting for a global setting.

A listing exposes the name of every file in the directory, including files nobody linked to.

The module can emit listings as HTML, XML, JSON or JSONP through `autoindex_format`, so a listing may be machine-readable rather than a visible page.

Security headers such as HSTS, Content-Security-Policy or X-Content-Type-Options are sent only when `add_header` directives say so.

`add_header` directives are inherited from the enclosing level only when the current level defines none — so adding one header in a location can silently drop the ones set at the server level.

That inheritance rule is the usual reason headers present on one path are missing on another.

Checking headers on more than one path is the way to see it.

`technology.inventory` and `technology.versions` list nginx and any version published.

`security.server_disclosure` reports the version in the `Server` header.

`wordpress.directory_listing` reports directory listings on WordPress sites; the listing problem page covers them in general.

`infrastructure.reverse_proxy` reports proxy and cache signatures in the response headers.

The headers module documentation states that `add_header` adds a field only when the response code is one of a listed set of success and redirect codes — 200, 201, 204, 206, 301, 302, 303, 304, 307 and 308.

Error pages therefore do not carry headers added this way unless the directive uses the `always` parameter.

An HSTS or Content-Security-Policy header present on normal pages and missing from 404 or 500 responses usually has this cause.

Recent nginx versions also document a directive to redefine the inheritance rules of `add_header`, so the behaviour above is the default rather than the only possibility.