How the error pages check works
A site under development shows detailed errors so the developer can fix them. A live site should not: those details tell an attacker which framework, files and code paths are inside. This check makes one request that is sure to fail and reads what comes back.
What it reads
One request to an address that cannot exist on your site, made of scanylo-check- and a random string. Redirects are not followed. Nothing is sent but an ordinary page request.
What it reports
- A stack trace or code error in the page, such as PHP "Fatal error ... on line", a Python traceback or a Java exception.
- A framework debug page, such as Laravel's error page, Django with
DEBUG = True, the Werkzeug debugger or the ASP.NET developer exception page. These can show settings and sometimes secrets. - A server name with its version on the error page, for example
Apache/2.4.41 Server at .... - Status 200 for a missing page (a "soft 404"), as information. It is not a security flaw, but it confuses search engines and other tools.
What it cannot see
- Errors that only happen on real pages, after a login or with particular input. A passive check does not try to cause errors with unusual input.
- Error details written to a log rather than the page, which is where they belong.
What to do with the result
Ask your developer to switch the site to production mode (for example APP_DEBUG=false in Laravel, DEBUG = False in Django, display_errors = Off in PHP) and to serve a plain error page. If a debug page was visible, ask them to check whether it showed any passwords or keys, and to change those that it did.
See what this looks like on your own site: a free, passive check in about two minutes.
Check my websiteEverything this check can report
- SeriousError page shows a stack trace or debug output
- SeriousFramework debug page enabled
- MinorError page discloses server version
- InfoMissing pages answer with status 200
- InfoError page could not be checked
Severity is fixed per finding in our code and never set by the AI that writes the report text. How severity becomes a score is on the methodology page.
The other checks
- How the security headers check works · The instructions your server sends to browsers with every page.
- How the cookies check works · Whether the cookies your site sets are protected on the way and in the browser.
- How the secure connection check works · Your certificate, the encryption your server accepts, and whether visitors are moved to https.
- How the email and DNS check works · The public DNS records that stop fake email in your name, and addresses pointing to services you no longer use.
- How the technology check works · What your site is built with, worked out from what it shows publicly.
- How the vulnerability wave check works · Whether what we can see matches a major vulnerability in the news.