← All checks
SecurityTypical severity: High

Exposed Endpoint Scanner

Probes for debug panels and endpoints (Actuator, Telescope, Ignition, phpMyAdmin) exposed in production.

What it checks

This scanner probes for debug panels and endpoints reachable in production, such as Actuator, Telescope, Ignition or phpMyAdmin. It detects when those internal tools are accessible from the internet.

Why it matters

These panels often reveal highly valuable internal information such as configuration, environment variables or database access, meant only for development. Left open in production, they hand an attacker a direct door into your systems and data.

How to fix it

Disable these debug tools in production or restrict their access to internal networks or trusted addresses only. Check that your deployment configuration does not leave debug mode on or expose these panels publicly.

How this check works

Scanaris requests a list of paths that correspond to debug panels and tools that should never answer in production, and checks that the response is the real one from that tool and not your site's generic page. The paths and their severity: /actuator/health from Spring Boot (high), /actuator/env and /actuator/heapdump (critical: environment variables and a memory dump), /telescope/requests from Laravel Telescope (high), /_ignition/health-check from Laravel Ignition in debug mode (critical, because vulnerable versions allowed code execution), /_profiler from Symfony (high), /.vscode/sftp.json with deployment credentials (critical), Apache's /server-status (medium) and /phpmyadmin/ (high).

Why it matters

These tools exist to show the application's insides to whoever develops it: configuration, environment variables with passwords, recent queries with their parameters, full error traces, the contents of the process memory. In development they are invaluable; in production, open to the internet, they are a door with the key in the lock. A reachable /actuator/env usually includes the database connection string. A public phpMyAdmin is an entry point for trying passwords against your database 24 hours a day.

Why it happens

Because the same configuration is used for development and production. Laravel's debug mode (APP_DEBUG=true), Actuator endpoints exposed by default in old Spring versions, Symfony's profiler with APP_ENV=dev, a phpMyAdmin installed "to look at the database for a moment" and never removed. AI tools that generate the project rarely distinguish environments, and the deployment inherits the development configuration.

How to fix it

  • Laravel: APP_DEBUG=false and APP_ENV=production in the production .env. Telescope only in local environments (TELESCOPE_ENABLED=false or the authorization gate). Update Ignition to a version without the vulnerability.
  • Spring Boot: management.endpoints.web.exposure.include=health at most, without env or heapdump, and with security in front of /actuator. Better still, expose the actuator on a separate management port that does not face the internet.
  • Symfony: APP_ENV=prod and APP_DEBUG=0; the profiler is only registered in dev.
  • phpMyAdmin: uninstall it from the public server. If you need it, access it through an SSH tunnel or restrict it by IP with additional authentication.
  • Apache server-status: Require ip 127.0.0.1 in the Location /server-status directive, or disable the module.
  • Editor files like .vscode/sftp.json: they must never be deployed. Add .vscode/ to .gitignore and, if it was published, change the password it contains.

Check it is fixed

for p in actuator/health actuator/env telescope/requests _ignition/health-check _profiler .vscode/sftp.json server-status phpmyadmin/; do
  printf "%-26s " "$p"; curl -s -o /dev/null -w "%{http_code}\n" "https://yourdomain.com/$p"
done

Expected: 404, 403 or 401 on all of them. A 200 is only acceptable if what it returns is your generic page and not the tool.

Frequently asked questions

My panel asks for a password. Is it still a finding?

Scanaris checks the content, so a panel protected with authentication that returns 401 is not flagged. Even so, a phpMyAdmin with a login is a brute-force target; better off the internet.

And /actuator/health? It only says "UP".

It confirms which technology you use and which Spring version, and usually indicates that the other endpoints are exposed too. If you need a public health check for your load balancer, create a minimal route of your own instead of opening the actuator.

I use Next.js or Nuxt. Does this apply to me?

These specific paths do not, but the principle does: the debug or seed API routes (/api/debug, /api/seed) the AI creates for testing have to disappear before deploying.

Check it on your site

Scan your site free and see if this and 44 other checks pass, with a fix prompt for every issue.

Scan my site free

From the blog

Related checks