When Error Messages Become an Attacker’s Roadmap: Finding Hidden Secrets in Web Applications

Introduction

A few weeks ago, I was testing a web application that looked completely secure.

Every request returned proper status codes. Authentication was implemented correctly. There were no obvious vulnerabilities.Out of curiosity, I intentionally broke a few requests.

Instead of a simple error page, the application responded with something developers never expected anyone to see.

A complete Java stack trace.

It revealed:

Internal package names
Database queries
API endpoints
Server file paths
Framework versions
Third-party libraries

Within minutes, I understood more about the application's architecture than hours of reconnaissance could have revealed.That engagement reminded me of something many developers overlook:

Error messages are not just debugging information. They're free reconnaissance for attackers.

OWASP WSTG treats improper error handling as an important security test because detailed errors can expose internal implementation details that help attackers build targeted attacks.

Why Error Messages Matter

Applications fail.

Databases go down.

APIs timeout.

Files don't exist.

Unexpected input reaches the server.

Errors are normal.

The problem begins when the application tells users exactly what went wrong internally.

Instead of saying:

Something went wrong.

The application might respond with:

SQLSyntaxErrorException
at com.company.user.UserDAO.java:143
PostgreSQL Version 15
Spring Boot 3.1

SQLSyntaxErrorException
at com.company.user.UserDAO.java:143
PostgreSQL Version 15
Spring Boot 3.1

To a normal user this looks confusing. To an attacker, it's valuable intelligence.

What Can Attackers Learn?

A single verbose error can reveal:

Programming language
Framework
Database type
Server technology
Internal IP addresses
File paths
API structure
Software versions
Cloud services
Microservices architecture

OWASP specifically warns that these details help attackers understand internal systems, identify technologies in use, map connected services, and even chain attacks together.

A Real Example

Imagine entering text where the application expects only numbers.

Instead of showing:

Invalid input.

Invalid input.

The application returns:

java.lang.NumberFormatException
at com.shop.payment.PaymentService

java.lang.NumberFormatException
at com.shop.payment.PaymentService

Now the attacker already knows:

Java is used
Package naming convention
Payment module exists
Error handling isn't configured properly

That single mistake becomes the starting point for deeper testing.

Stack Traces: A Blueprint of the Application

Stack traces are one of the biggest information leaks.

They often include:

Controller -> Service ->Database Layer -> SQL Query -> Exception

This tells an attacker exactly how requests move through the application.

In older versions of the WSTG, stack traces had their own test. In WSTG v4.2, they are included under Improper Error Handling, because exposing stack traces is simply another form of poor error handling.

How I Usually Test This

Instead of immediately trying payloads from cheat sheets, I first try to make the application fail.

Some simple tests include:

• Sending text instead of numbers

• Removing required parameters

• Sending malformed JSON

• Uploading an unexpected file type

• Making requests for pages that don't exist

• Using invalid HTTP requests

• Breaking request headers

• Sending unusually large input

OWASP recommends identifying input points, understanding the expected data type, and then using focused fuzzing rather than blindly sending every payload. It also suggests trying malformed HTTP requests and invalid paths to trigger server-side errors.

What I Look For

Whenever an error appears, I check for:

Database names
SQL queries
Source code references
Internal IP addresses
Server paths
API names
Cloud provider details
Framework versions
Container names
Hidden endpoints

Even a small clue can completely change the direction of a penetration test.

Why This Matters in Modern Applications

Modern applications rarely run as a single server.

Today they're built using:

Microservices
APIs
Containers
Serverless functions
Cloud infrastructure

If every service returns a different error format, attackers can identify which backend service processed each request and map the application's architecture more easily. OWASP highlights this as a particular concern in microservice environments.

Common Mistakes Developers Make

Some mistakes appear again and again:

Debug mode enabled in production
Returning full exception messages
Exposing stack traces
Displaying SQL errors
Revealing framework versions
Different error formats across services
Forgetting to disable verbose logging after testing

None of these issues directly compromise the application.

But together they make an attacker's job much easier.

Final Thoughts

Most penetration testers spend hours trying to understand how an application works.Sometimes the application tells them everything they need to know after a single failed request.Good error handling isn't about hiding problems.

It's about making sure users only see what they need to see, while detailed information stays in server logs where developers can investigate it safely.

The next time you're testing a web application, don't ignore the error pages.

Sometimes they're the best documentation you'll ever receive.

Contents