Post cover image

July 14, 2026

PortSwigger Lab Solution: Information Disclosure in Error Messages Walkthrough (Apprentice)

Learn how to identify and exploit information disclosure through verbose error messages using Burp Suite in the PortSwigger Web Security…

By Rahul M S

3 min read

Learn how to identify and exploit information disclosure through verbose error messages using Burp Suite in the PortSwigger Web Security Academy.

Error messages are useful for developers during testing, but when exposed in production, they can reveal sensitive information about an application's internal implementation. Attackers often leverage these details during reconnaissance to identify technologies, framework versions, and potential attack vectors.

In this walkthrough, we'll solve the Information Disclosure in Error Messages lab from the PortSwigger Web Security Academy and understand why this vulnerability exists, how it can be exploited, and how developers can prevent it.

📌 Lab Information

Difficulty: Apprentice

Category: Information Disclosure

Objective: Trigger an error message that reveals a framework version number and submit it to solve the lab.

Lab URL: https://portswigger.net/web-security/information-disclosure/exploiting/lab-infoleak-in-error-messages

🎯 What You'll Learn

By completing this lab, you'll learn how to:

✅ Identify parameters suitable for information disclosure testing.

✅ Trigger verbose server-side error messages.

✅ Extract sensitive information from application responses.

✅ Understand the security risks of verbose error handling.

✅ Apply secure error-handling best practices.

🔍 Understanding the Vulnerability

Information disclosure occurs when an application unintentionally exposes internal information that should never be accessible to users.

Verbose error messages can reveal:

• Technology stack (Apache Struts, Spring Boot, ASP.NET, etc.)

• Framework versions

• Database queries and SQL errors

• File paths and directory structures

• Stack traces

• Internal server information

Although this information may not immediately compromise the application, it provides valuable intelligence that attackers can use during reconnaissance.

🎯 Identifying the Attack Surface

While browsing the application, clicking on any product generates the following request:

GET /product?productId=1

The productId parameter is an ideal candidate for testing because:

✔ It accepts user-controlled input.

✔ It references a database record.

✔ Numeric parameters commonly interact with SQL queries.

✔ Invalid input may trigger backend exceptions.

A simple way to test this parameter is by replacing the expected numeric value with unexpected characters and observing how the application responds.

⚙️ How the Vulnerability Occurs

When the application receives malformed input, it attempts to process it without proper validation.

User Input (productId=')
        │
        ▼
Application Processes Input
        │
        ▼
Input Breaks SQL Query
        │
        ▼
Database Throws Exception
        │
        ▼
Application Returns Detailed Error
        │
        ▼
Sensitive Information is Disclosed

This happens because:

• User input is not properly validated.

• Backend exceptions are exposed directly to users.

• Detailed error messages are enabled instead of generic error pages.

🚀 Exploitation Steps

Step 1: Browse the Application

Open the lab and browse the target application.

Click on any product and observe the following request:

GET /product?productId=1

Step 2: Send the Request to Burp Repeater

Locate the request in Proxy → HTTP History.

Right-click the request.

Select Send to Repeater.

Step 3: Modify the Parameter

Replace:

productId=1

with:

productId='

The modified request becomes:

GET /product?productId=' HTTP/1.1
Host: <lab-id>.web-security-academy.net

Click Send.

Step 4: Analyze the Response

The application returns a 500 Internal Server Error containing a verbose exception similar to:

HTTP/1.1 500 Internal Server Error
java.sql.SQLException
...
Apache Struts 2 2.3.31

The response exposes the framework version running on the server.

✅ Lab Answer

Apache Struts 2 2.3.31

⚠️ Security Impact

An attacker can use the disclosed information to:

• Fingerprint the application's technology stack.

• Identify publicly known vulnerabilities (CVEs).

• Understand the backend implementation.

• Build more targeted attacks.

Even though this lab only reveals a framework version, similar vulnerabilities often expose database queries, configuration files, file paths, and other sensitive information.

🛡️ Remediation

Developers should implement the following security best practices:

✅ Display generic error pages to users.

✅ Log detailed exceptions only on the server.

✅ Disable debug mode in production.

✅ Validate and sanitize all user input.

✅ Implement centralized exception handling.

📖 Key Takeaways

Verbose error messages should never be exposed in production environments.

✔ A single malformed input can reveal valuable backend information.

✔ Framework version disclosure helps attackers identify known vulnerabilities.

✔ Proper exception handling is a critical part of secure application development.

📚 References

PortSwigger Web Security Academy

https://portswigger.net/web-security/information-disclosure

OWASP Top 10

https://owasp.org/www-project-top-ten/

🤝 Connect with Me

If you enjoy practical cybersecurity content and hands-on PortSwigger Web Security Academy walkthroughs, feel free to connect with me.

🌐 Portfolio https://rahulms.qzz.io/

💻 GitHub https://github.com/1amrahul

💼 LinkedIn https://linkedin.com/in/rahul-m-s-372b631a2

If this walkthrough helped you, consider following this publication for more PortSwigger Web Security Academy lab solutions, Burp Suite tutorials, and practical web application security content.