Recognised debug or non-HTML output is served at a common debug path
ShipReady found bounded evidence of debug output or non-HTML content at /admin or /debug.
Why it matters
Unintended diagnostic output can reveal details that should be reviewed before production release.
How ShipReady detects it
What it inspects
ShipReady probes only /admin and /debug on an eligible origin response.
What triggers a finding
A finding requires HTTP 200 and either a recognised framework-debug or trace signature, or a declared non-HTML body that is nontrivial and not markup or an SPA catch-all.
What the evidence shows
One of the two fixed paths returned the specific reported debug or non-HTML evidence.
Limits of this check
ShipReady does not authenticate, enumerate routes, inspect configuration comprehensively, or prove that the endpoint exposes credentials or permits administrative actions.
How to fix it
Identify the observed debug or non-HTML response
Use the reported /admin or /debug path and response indicator to determine whether it is framework diagnostics, an operational payload, or an intentionally public endpoint.
Disable production diagnostics or restrict the endpoint
Turn off unintended debug output in the production deployment, or protect an operational endpoint with the access controls appropriate for its intended users. Do not rely on the path name alone as protection.
How to verify the change
Recheck the reported debug path
Request the same path after deployment and confirm it no longer returns the matching debug signature or unintended non-HTML response.
Expected: The reported path has the intended public behavior and no longer exposes the detected diagnostic output.