Learning Objectives
- Identify what information is exposed in a leaked stack trace
- Understand the security risk of raw exception output in production responses
- Test for stack trace leakage and document findings in a security-relevant bug report
What a Stack Trace Reveals
A stack trace is a debugging tool — it shows exactly where in the code an exception occurred and the full call chain that led there. In development, this is invaluable. In production, it is a security vulnerability.
A typical leaked stack trace might look like:
java.lang.ArithmeticException: / by zero
at com.example.bookings.PricingService.calculateDailyRate(PricingService.java:47)
at com.example.bookings.BookingResource.createBooking(BookingResource.java:112)
at com.example.bookings.BookingResource$quarkus$$intercepted.createBooking(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137)
From this single stack trace, an attacker learns:
| Information | Value to Attacker |
|---|---|
com.example.bookings |
Package structure, company naming convention |
PricingService.java:47 |
Exact file name and line number of the bug |
BookingResource.java:112 |
Entry point for the vulnerable functionality |
quarkus$$intercepted |
Framework being used (Quarkus) |
sun.reflect.NativeMethodAccessorImpl |
JDK version and reflection mechanism |
org.jboss.resteasy |
HTTP layer library and version hints |
This information enables targeted attacks: finding known CVEs for the identified library versions, crafting inputs that exploit the specific code path, and understanding the application architecture.
Dev Mode vs Production Mode
| Environment | Error Response | Stack Trace Exposed? |
|---|---|---|
| Development / staging | Full stack trace in response body | Yes — intentional |
| Production (correct) | {"error": "An error occurred", "errorId": "abc-123"} |
No |
| Production (misconfigured) | Full stack trace in response body | Yes — vulnerability |
The difference is configuration. Frameworks like Spring Boot, Quarkus, and Django have settings that control error verbosity. A common misconfiguration is deploying with development-mode settings to a public-facing environment.
How to Test for Stack Trace Leakage
- Trigger a 500 error using boundary inputs (zero-duration dates, null values, malformed dates)
- Inspect the full response body — not just the HTTP status code
- Look for class names, file paths, line numbers, or library names in the response
- Check all error formats: HTML error pages (sometimes verbose), JSON error responses, plain text
- Test in staging environments — they are more likely to have verbose error settings than true production, but still public
Reporting Leakage Bugs
When you find stack trace leakage, your bug report should include:
- The exact request that triggered it (method, URL, request body)
- The full leaked response (or the sensitive portion)
- The severity classification: typically High — information disclosure that aids attack planning
- The recommended fix: enable production error masking in the framework configuration