Information Disclosure vulnerabilities: Source Code Disclosure via Backup Files Walkthrough…

Learn how to discover exposed backup files, retrieve source code, and identify hard-coded credentials using Burp Suite in the PortSwigger Web Security Academy.

Backup files are commonly created by developers before modifying source code or configuration files. If these files are accidentally left inside publicly accessible directories, attackers can download them to obtain sensitive information such as application source code, database credentials, API keys, and internal business logic.

In this walkthrough, we'll solve the Source Code Disclosure via Backup Files lab from the PortSwigger Web Security Academy using Burp Suite. You'll learn how to identify exposed backup files, extract sensitive information from source code, understand the associated risks, and implement effective security controls.

📌 Lab Information

Difficulty: Apprentice

Category: Information Disclosure

Objective: Locate an exposed backup file that contains the database password and submit it to solve the lab.

Lab URL: https://portswigger.net/web-security/information-disclosure/exploiting/lab-infoleak-via-backup-files

🎯 What You'll Learn

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

✅ Identify hidden directories using robots.txt.

✅ Discover publicly accessible backup files.

✅ Analyze exposed source code for sensitive information.

✅ Extract hard-coded credentials from application files.

✅ Apply best practices to prevent source code disclosure.

🔍 Understanding the Vulnerability

Backup files are copies of source code or configuration files created during development. If these files remain accessible after deployment, they can expose sensitive application data.

Common backup file extensions include:

• .bak

• .old

• .orig

• .save

• .swp

• ~ (tilde backups)

These files often contain:

• Application source code

• Database credentials

• API keys

• Configuration settings

• Internal business logic

Although intended only for development, publicly accessible backup files can significantly assist attackers during reconnaissance and exploitation.

🎯 Identifying the Attack Surface

A common place to begin reconnaissance is the application's robots.txt file.

Request:

GET /robots.txt HTTP/1.1
Host: <lab-id>.web-security-academy.net

GET /robots.txt HTTP/1.1
Host: <lab-id>.web-security-academy.net

The response reveals:

User-agent: *
Disallow: /backup

User-agent: *
Disallow: /backup

Although robots.txt is intended for search engine crawlers, it is publicly accessible and often reveals hidden directories that developers don't want indexed.

The discovered /backup directory becomes our next target.

⚙️ How the Vulnerability Occurs

The vulnerability exists because backup files were left inside a publicly accessible directory.

robots.txt
        │
        ▼
Hidden Directory Discovered
        │
        ▼
Directory Listing Enabled
        │
        ▼
Backup File Found
        │
        ▼
Source Code Downloaded
        │
        ▼
Sensitive Credentials Exposed

robots.txt
        │
        ▼
Hidden Directory Discovered
        │
        ▼
Directory Listing Enabled
        │
        ▼
Backup File Found
        │
        ▼
Source Code Downloaded
        │
        ▼
Sensitive Credentials Exposed

This happens because:

• robots.txt exposes the backup directory.

• Directory listing is enabled.

• Backup files are stored inside the web root.

• Database credentials are hard-coded within the source code.

🚀 Exploitation Steps

Step 1: Check the robots.txt File

Send the following request using Burp Repeater:

GET /robots.txt HTTP/1.1
Host: <lab-id>.web-security-academy.net

GET /robots.txt HTTP/1.1
Host: <lab-id>.web-security-academy.net

The response reveals:

User-agent: *
Disallow: /backup

User-agent: *
Disallow: /backup

This indicates the presence of a hidden backup directory.

Step 2: Browse the Backup Directory

Request:

GET /backup/ HTTP/1.1
Host: <lab-id>.web-security-academy.net

GET /backup/ HTTP/1.1
Host: <lab-id>.web-security-academy.net

The response displays a directory listing similar to:

<h1>Index of /backup</h1>
ProductTemplate.java.bak

<h1>Index of /backup</h1>
ProductTemplate.java.bak

This confirms that a backup file is publicly accessible.

Step 3: Download the Backup File

Request:

GET /backup/ProductTemplate.java.bak HTTP/1.1
Host: <lab-id>.web-security-academy.net

GET /backup/ProductTemplate.java.bak HTTP/1.1
Host: <lab-id>.web-security-academy.net

Click Send.

Step 4: Review the Source Code

The downloaded Java source code contains a hard-coded database connection.

ConnectionBuilder connectionBuilder = ConnectionBuilder.from(
        "org.postgresql.Driver",
        "postgresql",
        "localhost",
        5432,
        "postgres",
        "postgres",
        "DATABASE_PASSWORD"
).withAutoCommit();

ConnectionBuilder connectionBuilder = ConnectionBuilder.from(
        "org.postgresql.Driver",
        "postgresql",
        "localhost",
        5432,
        "postgres",
        "postgres",
        "DATABASE_PASSWORD"
).withAutoCommit();

Locate the password value inside the connection string.

Note:_ The database password is generated uniquely for every PortSwigger lab instance, so your value will differ._

⚠️ Security Impact

If exposed in a production environment, backup files can allow attackers to:

• Download proprietary application source code.

• Retrieve database credentials.

• Understand application logic.

• Discover hidden endpoints.

• Identify additional vulnerabilities for further exploitation.

🛡️ Remediation

Developers should implement the following security best practices:

✅ Store backup files outside publicly accessible directories.

✅ Disable directory listing on the web server.

✅ Block access to backup file extensions such as .bak, .old, .orig, and .swp.

✅ Never hard-code database credentials inside source code.

✅ Store secrets securely using environment variables or a dedicated secrets management solution.

✅ Review deployment packages to ensure development artifacts are removed before production releases.

📖 Key Takeaways

Backup files should never be publicly accessible.

✔ Always inspect robots.txt during reconnaissance.

✔ Directory listings can expose sensitive files.

✔ Source code often contains valuable information for attackers.

✔ Hard-coded credentials represent a critical security risk.

✔ Secure deployment practices help prevent accidental information disclosure.

📚 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, Web Application Penetration Testing (VAPT) guides, and practical web application security content.

Contents

📌 Lab Information

🎯 What You'll Learn

🔍 Understanding the Vulnerability

🎯 Identifying the Attack Surface

⚙️ How the Vulnerability Occurs

🚀 Exploitation Steps

Step 1: Check the robots.txt File

Step 2: Browse the Backup Directory

Step 3: Download the Backup File

Step 4: Review the Source Code

⚠️ Security Impact

🛡️ Remediation

📖 Key Takeaways

📚 References

🤝 Connect with Me