A scanner requests a path that often holds credentials. The server returns 200 OK. That response is worth investigating, but the status code tells us only that the server returned a body. It says nothing about whether that body contains a secret.
Many single page applications return the same HTML shell for unknown paths. Login systems can redirect visitors to a sign-in page. A CDN can even serve a branded error page with a successful status. A finding based on the status alone confuses an accessible URL with an exposed file.
Start with a control request. Ask the same host for a random path that should not exist. Compare its final URL, content type, title and response structure with the suspected file. If both responses are effectively the same page, the 200 is probably a fallback. This comparison does not prove that every path is safe. It shows that this particular response is weak evidence of an exposure.
Then look for a signature specific to the file you expected. An environment file, repository metadata and a backup archive have different structures. A generic word such as password is too weak: documentation and ordinary HTML can contain it. A credible result needs a format that fits the suspected resource, in a response that differs from the fallback control.
Keep the evidence safe. Do not copy a live credential into a public issue, screenshot or report. Record the path, relevant headers and a redacted excerpt that explains the conclusion. If the response is ambiguous, say what remains to be checked. If it is plainly the site shell, do not call it a secret leak.
This approach also applies beyond exposed files. An automated security report is more useful when it separates what the tool observed from what it inferred. The status code is an observation. The existence of a secret is a conclusion that needs stronger evidence.
Originally published on the VICE blog.
Top comments (0)