Framework-Aware Scanning: TCSR Now Detects Laravel, Django and Beyond

TCSR has always known how to recognise an off-the-shelf CMS — WordPress, Joomla, Drupal — and check it the way an attacker would: which core version, which plugins, which of them carry a known vulnerability. From today the scan engine does the same for application frameworks. If your site runs Laravel, Django, Symfony, Rails, ASP.NET, Spring Boot, Express or Next.js, TCSR now identifies it and runs framework-specific checks — the ones that map to how these stacks actually get breached.

Why a framework needs different checks than a CMS

A CMS is assembled from parts: the risk lives in outdated plugins and themes with public CVEs, so you match versions against a vulnerability feed. A framework is different. There is no plugin marketplace to scan. The danger is almost always the same story: a development convenience left switched on in production.

Debug mode that prints stack traces and config to the browser. A profiler or admin dashboard reachable without a password. A management endpoint that will happily hand over every environment variable — including your database password and API keys. None of these are "bugs" in the framework. They're defaults that are perfectly fine on a laptop and quietly catastrophic on a public server.

What TCSR looks for

Once a framework is fingerprinted from passive signals (response headers, cookies, page markup), the assessment probes the well-known paths that expose those development conveniences:

• Laravel — Telescope and Horizon dashboards open to the public, Debugbar enabled, the Ignition error handler exposed (the vector behind CVE-2021-3129, an unauthenticated RCE that was mass-exploited in the wild), and a publicly readable storage/logs/laravel.log.
• Symfony — the /_profiler web profiler reachable in production, a leftover app_dev.php front controller, and the X-Debug-Token header that betrays debug mode.
• Django — DEBUG = True left on, which turns any 404 into a verbose page disclosing your settings, installed apps and URL map.
• Ruby on Rails — the /rails/info development routes that should never answer in production.
• ASP.NET — the ELMAH error log (elmah.axd) and the trace.axd viewer leaking request and server internals.
• Spring Boot — exposed Actuator endpoints, above all /actuator/env and /actuator/configprops, which dump the full configuration and are a notorious source of leaked secrets.

These join the version-disclosure and misconfiguration signals we already read straight from the homepage, so even a passive, ownership-free scan will tell you which framework you're advertising to the world.

The honest part — what we do and don't do

Two boundaries, the same ones that govern the rest of the engine:

• Detection and reporting only. Every framework check is a plain GET to a well-known path — the same non-destructive class as our exposed-files module. We confirm that a dashboard or endpoint responds; we never send an exploit payload, and a page that redirects you to a login is treated as protected, not as a finding.
• Active checks need proven ownership. Framework detection is passive and runs on any scan. The active exposure probes run only against a domain whose ownership you have verified, on the appropriate plan — so you stay firmly on the right side of the line.

Why it matters to you

The headlines write themselves here: a Spring Actuator endpoint that leaked production credentials, a Laravel app whose debug page handed attackers remote code execution, a Django site whose error page mapped out its own internals. Every one of those started as a setting nobody remembered to flip before launch.

Knowing which framework you run is step one. Knowing which doors it left open is the step that actually changes your exposure. Run a verified scan, and your next report will name the framework — and tell you, in plain language, exactly which of those doors to close.