Next.js

`/_next/static/` in the served markup, the path Next.js serves its build output from — weight 85.

`__NEXT_DATA__` in the markup, the script element carrying the page's serialised data in the Pages Router — weight 85.

An `x-powered-by` header naming Next.js — weight 90, the strongest single signal.

The score is the strongest signal plus a quarter of each additional one, capped at 99; below 40 nothing is reported. Any one of these three is enough on its own.

Next.js, Nuxt and plain React are separate rules, so a React application that is not built with Next.js is not reported as one.

It proves the pages were produced by a Next.js build. That is an inventory fact, not a finding.

It does not prove the server runs Node.js: a statically exported Next.js site can be served by any web server or CDN, and the runtime check reports Node.js only from a server signature.

It does not identify the host. A Next.js site on its original vendor's platform and one on a self-managed server look the same in the markup; the hosting rows come from headers and addresses instead.

It does not reveal the framework version. Nothing in the three signals carries one, and a version is never guessed.

By default Next.js adds an `x-powered-by` header to its responses, and the documented `poweredByHeader: false` option in `next.config.js` removes it.

The header advertises the framework to anyone who requests a page. That is a small disclosure rather than a vulnerability, and it is also the most reliable of the three recognition signals.

Removing it does not hide the framework — the bundle paths remain — so its value is tidiness, not concealment.

An audit reports it with the other version and product disclosures in the response headers.

Browser source maps are disabled for production builds by default, the documentation says, to avoid leaking source to the client. The `productionBrowserSourceMaps` option turns them on, and Next.js then serves them next to the JavaScript files.

A production Next.js site serving `.map` files therefore made a deliberate choice, and anyone can reconstruct the original source from them.

Environment variables prefixed `NEXT_PUBLIC_` are inlined into the JavaScript sent to the browser at build time. Anything given that prefix is public, whatever it is called.

The right question for each such variable is whether it was meant to be public. A publishable key is fine; a secret with the prefix is exposed.

In the Pages Router, the props a page's data function returns must be serialisable, and they are delivered to the browser with the page.

Everything returned as props is therefore readable by the visitor, even fields the page never displays.

In the App Router, the documentation's data-security guidance applies the same rule to values passed to Client Components and to Server Action return values: they are serialised and sent to the client.

An external audit can read the payload that was delivered; whether a field in it was meant to stay server-side is a question for the team that wrote it.

`technology.inventory` lists the detection with its evidence and confidence.

`security.server_disclosure` reports product and version strings in headers such as `x-powered-by`.

`exposure.sourcemap.public` and `exposure.sourcemap.sources_content` report served source maps and whether they embed the original code.

`exposure.secrets.public_keys` and `exposure.secrets.private` report keys found in the JavaScript that was actually served.

`technology.nodejs` stays not verifiable unless the server itself names its runtime.