Symfony

`x-symfony-cache` header — weight 90, from Symfony's HTTP cache.

`x-debug-token` or `x-debug-token-link` header — weight 85, from the web profiler.

A generator meta tag naming Symfony — weight 90.

A `sf_redirect` or `symfony` cookie — weight 70; `/_profiler/` or `/bundles/framework/` paths — weight 65; any `/bundles/<name>/` path — weight 30, which only adds to the score.

PHP alone is never treated as Symfony, and the dedicated check says so when nothing specific is found.

Symfony's profiler guide places the profile's token in the `X-Debug-Token` response header and a link to it in `X-Debug-Token-Link`.

The same guide carries a danger notice: never enable the profiler in production environments, as it will lead to major security vulnerabilities.

The configuration reference repeats the rule: the web profiler must never be enabled in production.

A live site sending these headers is therefore exposing a development tool, and the finding is the profiler, not the framework.

Profiler and cache headers prove Symfony code produced the response.

Bundle paths suggest Symfony and are shared by other projects built on its components, which is why the generic path carries a low weight.

No signal carries the Symfony version, and a version is shown only when one is observed.

The PHP runtime is reported separately, from its own headers.

Switch the environment to production and confirm the profiler bundle is not enabled there.

Treat anything the profiler could have displayed as seen — request data, configuration, logs — and rotate credentials that appeared in it.

Check that the `/_profiler/` route no longer answers, not only that the headers disappeared.

Rescan to confirm the headers are gone from every response.

`technology.symfony` reports Symfony only from specific public evidence, with its confidence.

`technology.inventory` lists it with the evidence that produced it.

`security.server_disclosure` reports product and version strings in response headers.

`exposure.internal.paths` reports internal paths referenced in served content.

Symfony selects its environment through the `APP_ENV` variable, and the configuration guide shows `APP_ENV=prod` for production.

Bundles such as the web profiler are normally enabled only for the development and test environments, which is why the profiler headers are a sign the production environment is not in use — or that the bundle was enabled for it.

The profiler guide notes that the debug toolbar is injected only into HTML responses, so an API can run with the profiler on and show no toolbar at all.

It also notes that when the profiler is enabled without the toolbar, the `X-Debug-Token` header is still available, which is exactly what an external audit reads.

Symfony's bundles configuration shows the web profiler bundle enabled for `dev` and `test` only in the standard setup, so seeing it in production means that line was changed or the wrong environment is running.