# Does your site show error details or stack traces to the public?

By Mark Kashef, founder of Lockpick. Published 2026-10-08, updated 2026-10-08.

The error output check flags responses that show stack traces or debug output from your server. Here is what they reveal and how to turn them off.

The error output check flags a response that shows a stack trace or structured debug output from your server. These details help someone map how your app works inside.

## What does this check look at?

It looks at whether a response shows a stack trace or structured debug output from the server. OWASP notes that unhandled errors can assist an attacker in the reconnaissance phase of an attack.

Pulse and Deep scans both run it.

## What does a result mean?

| What the report shows | What it means | What to do |
| --- | --- | --- |
| Medium finding | A response matched a stack trace or debug output. | Turn off debug output in production and log errors privately. |

Details about the server help someone understand it but do not prove they can control it. A clean result means nothing was found in what the scan read. It does not prove the problem is absent from parts the scan never sees.

## How serious is a finding?

Treat this as a hardening gap. It makes an attacker’s job easier but gives them no path of its own, so fix it after anything more direct. Confidence starts high, because a response from your site shows the thing itself. The report lists what to fix by how directly someone could use it, not by the severity label.

### What does a confirmed finding have to show?

| Part | For this check |
| --- | --- |
| Where it starts | Anyone on the internet, with no account, cookie or credential |
| The protection that should stop it | Error details and diagnostics should be off in production |
| What is reached | A stack trace, environment or route listing |
| What follows | Internal details that help plan an attack; no access on their own |

## Which standards does it relate to?

| Standard | Reference |
| --- | --- |
| OWASP Top Ten | `A10:2025` Mishandling of Exceptional Conditions |
| CWE | `CWE-209` |

Each one is a related control, not a verification. A scan sees what anyone online can see, so it never proves a whole requirement is met.

## Fix it with your AI

Most frameworks have one production setting for this, plus a custom error page.

:::fix-prompt any
My live site shows error details to visitors: [paste the evidence from the report]. Turn off debug mode and detailed error pages in production for my framework and host, return a plain error page or JSON error without stack traces, and send full error details only to my server logs or error tracker. Show me the settings you changed.
:::

## How to check

Say Atlas, our example app at `atlas.example`, left debug mode on after a late night fix. Its error page shows a stack trace with file paths, and the check flags it.

Run a Pulse scan from your Lockpick account to see it for your site. [Pulse or Deep](/docs/get-started/pulse-or-deep) explains what each scan reads, and the [full list of checks](/checks) shows the rest.

## Questions people ask

### Is a stack trace a vulnerability?

Not on its own. It reveals internal details that make other attacks easier to plan, so it is rated medium at most.

### Did Lockpick cause the error?

Deep scans make a small number of careful requests, and one may land on an error page. Pulse only reads what your homepage and scripts already show.

## Sources

- [Error Handling Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Error_Handling_Cheat_Sheet.html), OWASP Cheat Sheet Series, read on 2026-10-07
- [How we rate findings](https://www.lockpick.app/docs/security/how-we-rate-findings), Lockpick docs, read on 2026-10-07