Security: Raw Error Responses and Information Disclosure

Learning Objectives

By the end of this lesson you will be able to:

Identify information disclosure via error messages as an OWASP security risk
Describe what a safe error response contains and what it must not include
Design test cases that reveal whether an API leaks internal details through errors
Write a complete security bug report for an information disclosure finding

OWASP A05: Security Misconfiguration

The OWASP Top 10 categorizes information disclosure through error messages under A05: Security Misconfiguration. This includes scenarios where an application returns raw exception details, internal file paths, database query fragments, or software library names in its HTTP error responses.

While this may seem like a minor UX issue, it is a meaningful security vulnerability: every piece of internal information an attacker receives narrows their attack surface. Knowing that a server runs Spring Boot 2.7.3 or Hibernate 5.6 tells an attacker exactly which CVEs to try.

What a Safe Error Response Contains

A well-designed error response for an end user should include:

A generic, user-friendly message: "An unexpected error occurred. Please try again or contact support."
A correlation ID (also called a request ID or error reference): a unique identifier such as "error_id": "err-a3f9b1c2" that allows developers to look up the full error in server logs without exposing it to the client
The HTTP status code: 500, 400, 422, etc.

A safe error response must not include:

Stack traces (Java/Python/Node exception chains)
Internal file paths (/app/src/main/java/...)
Library or framework names and versions
SQL query text or database schema information
Server hostnames or internal IP addresses

How to Test for Information Disclosure via Errors

As a black-box tester, your goal is to trigger the application's error handling and inspect what it reveals:

Submit an invalid date format: send "31-13-2024", "not-a-date", "null", or "" to any date field and capture the full response body.
Submit boundary-breaking values: try 99999-01-01 or a Unix timestamp from the year 55000 and observe whether the response contains internal exception text.
Inject special characters: try "2024-01-01'; DROP TABLE events; --" — if the error response contains SQL text, the application is disclosing query structure.
Send a malformed JSON body: omit required fields or send a non-JSON content body with Content-Type: application/json. Observe whether the response reveals the JSON parsing library.
Check the Content-Type header on error responses: text/html errors from a JSON API often contain HTML-rendered stack traces from frameworks like Django or Spring.

In each case, record whether the response body contains any of the forbidden elements listed above.

What to Include in a Security Bug Report

When you find an information disclosure issue, the bug report must be precise:

Title: API Leaks Stack Trace on Invalid Date Input — Information Disclosure

Severity: Medium (OWASP A05 — Security Misconfiguration)

Affected Endpoint: POST /api/events

Steps to Reproduce:
1. Send a POST request to /api/events with body:
   {"start_date": "not-a-date"}
2. Observe the response body.

Expected Result:
{"error": "Invalid date format", "error_id": "err-xxxxx"}

Actual Result:
HTTP 500 with full Java stack trace including:
  - at org.springframework.web.servlet.FrameworkServlet...
  - Caused by: java.time.format.DateTimeParseException...
  - Internal path: /home/app/src/main/java/...

Evidence: [attach raw response screenshot or curl output]

Risk: Exposes Spring Boot version and internal package structure to unauthenticated callers.

Summary

Information disclosure through raw error responses is one of the easiest security bugs to find and one of the most commonly overlooked. By systematically sending invalid inputs and inspecting every character of the response body, a QA engineer can surface misconfiguration findings that a security audit might have missed.