Information disclosure vulnerability | Bug bounty

In this write-up, we're exploring practical methods to find information disclosure bugs that qualify as P1 in bug bounty programs.

Always get proper authorization before testing any website. This is purely for educational purposes.

Let's find.

1) The web archive method (Wayback Machine)

The Wayback Machine is your first stop for recovering files that were once hosted on a target but now return 404.

Steps:

1. open web.archive.org.
2. Change the domain in the search bar to your target domain and press Enter.

3. You'll get a list of archived results for the target domain, including subdomains.

4. Manually look for file types that often contain sensitive data: PDF, CSV, DB, ZIP, archive files, and so on.

That manual approach works, but it's slow. I prefer to collect passive URLs and scan them from the terminal.

2) Pull passive URLs and scan from the terminal

Open your terminal and run the curl one-liner I use (replace the target domain in the command). The forward slash followed by an asterisk matches any path under the domain and subdomains, including pages and resources. This will download all passive URLs and save them to an output directory.

Use du to check file sizes in a human readable format. Once the URLs are downloaded, run another oneliner to search those files for interesting extensions and sensitive filenames (PDF, CSV, DB, ZIP, etc.). That will grep occurrences of those extensions across your saved URLs.

You can also search interactively from the terminal by typing an extension name and checking the URLs one by one.

Note: I'm not pasting the exact curl oneliner here because it's specific to your tooling and target. Replace the domain and paths as needed.

3) If a URL returns 404, don't stop — check Wayback

A common pattern: you find a URL that looks promising, but the server returns a 404. Most people stop there. Don't.

1. Copy the URL that returned a 404.
2. Paste it into the search bar on web.archive.org.
3. Press Enter to see the archive timeline for that exact URL.
4. Select a snapshot date and open the snapshot.

Even if the file was deleted from the live server, the Wayback snapshot often still serves the archived copy. I've pulled ZIPs this way that contained insurance claim templates, customer invoice details, and other sensitive documents — all of which are valid high-impact disclosures when you have authorization to test and report.

4) Examples and what to look for

• ZIP files containing PDFs like insurance claims or invoices.
• Database exports, backup files, or configuration files.
• CSV exports with customer data.
• Old forms or internal documents that were crawled and archived.

If you can access a file via Wayback that contains sensitive information, that's a strong P1 submission in most programs. The key is proving it was publicly accessible at some point and contains sensitive content that should not have been exposed.

5) Other sources: VirusTotal and AlienVault

Wayback isn't the only place to find passive URLs:

• Use VirusTotal: replace the domain with your target and look through the associated URLs it lists. If they return 404 on the live site, check Wayback for archived snapshots.
• Use AlienVault in the same way to find historical URLs and files.

The workflow is the same: gather URLs from these sources, filter for interesting extensions, and check Wayback for archived snapshots.

6) Fast reference and tooling

7) Final notes and safety

• Always have written permission before testing a domain.
• Archive-recovered files can contain real sensitive data; handle responsibly when reporting.
• This method is also useful for legitimate recovery tasks, such as finding deleted content the owner wants restored.