Angular

`ng-version=` or an `<app-root` element in the markup — weight 70, a single rule that clears the reporting threshold with high confidence.

`ng-version` is added by the framework itself: Angular's component code sets it on the root element with a placeholder that the release build replaces with the version number.

`<app-root>` is the default name of the root component in new projects, and many applications keep it.

The attribute appears in the rendered DOM; when the served HTML is only a shell, the root element is present but the attribute may only exist after the application boots.

Because `ng-version` carries the release number, any visitor can read the exact Angular version from the page.

That is a disclosure in the same class as a server version header: useful to an inventory, useful to anyone matching known issues to versions.

The engine records the attribute as detection evidence; it does not parse it into the version list, which only reports versions from headers and generator tags.

A published version is never treated as a vulnerability on its own.

Angular's documentation states that it ships all applications as client-side rendered by default.

The served HTML then contains the root element and script references, and the content appears only after JavaScript runs.

Server-side rendering and prerendering are available and can be added to an existing project, including per route in a hybrid setup.

Which mode a given route uses is visible by comparing its served HTML with the rendered page.

Checks that read the served HTML — titles, descriptions, canonicals, headings — may find an application shell rather than the page.

Where the engine can render pages, it reads the rendered result too; where rendering is unavailable, it says so rather than reporting the shell as the page.

Performance findings on a client-rendered application concentrate on the JavaScript that must run before anything is visible.

Accessibility checks need the rendered DOM, for the same reason.

`technology.inventory` lists Angular with the matched marker.

`seo.title`, `seo.h1` and `seo.canonical` show whether the metadata exists in what is served.

`performance.javascript` and `performance.heavy_javascript` measure the script a client-rendered page depends on.

The `javascript_rendering_unavailable` issue is raised when pages could not be rendered, so a shell is never mistaken for content.

Angular's documentation shows server rendering being added to a new project with the `--ssr` flag of `ng new`, or to an existing one with `ng add`.

Hybrid rendering lets each route be server-rendered, prerendered or client-rendered, so a single Angular site can mix the three.

Hydration is the step that restores a server-rendered page in the browser by reusing the existing DOM instead of re-creating it; the documentation ties it to better Largest Contentful Paint and layout stability.

For a custom setup that did not use the CLI to enable server rendering, hydration is enabled manually with `provideClientHydration`.

From outside, the difference shows directly: a server-rendered route delivers its content and metadata in the HTML, a client-rendered one delivers the shell.