How Hackers Find Secrets Hidden in Public Websites 🔍

Hey everyone 👋I’m Vipul, the curious mind behind TheHackersLog — a blog where we explore the science (and art) of cybersecurity, ethical hacking, and digital discovery.

Oct 14, 2025

Hey everyone 👋
I’m Vipul, the curious mind behind TheHackersLog — a blog where we explore the science (and art) of cybersecurity, ethical hacking, and digital discovery. Today I’ll take you behind the scenes 🕵️‍♂️ into one of the most fascinating areas of hacking: finding secrets that sit in plain sight on public websites. This is a practical, hands-on guide aimed at defenders, bug bounty hunters, and curious learners — written in a human, practical style with commands, tools, and image suggestions so you can reproduce (responsibly) or protect against these findings.

🔧 Download The Best AI Tools Pack (80+ tools) — perfect for automating, writing, and research.
🧭 Get The Hacker’s Recon Guide — a step-by-step playbook for discovering hidden subdomains, directories, and more.

What do we mean by “secrets”? 🤔

Not sci-fi vaults — usually small but dangerous leaks such as:

API keys
Database connection strings / passwords
Cloud storage tokens (S3 / GCS)
Internal or admin URLs (staging, dev panels)
Credentials accidentally committed to public code

Even one small secret can cascade into big compromises. The point of this post is to show how these secrets are commonly discovered — so you can better protect your projects.

How hackers (and security researchers) find them — step by step 👨‍💻

1) Open-source recon (OSINT): map the public footprint

Start wide. OSINT reveals subdomains, historical sites, and hosts that shouldn’t be public.

Common tools:

OWASP Amass — subdomain enumeration. (https://github.com/OWASP/Amass)
Recon-ng — modular recon framework. (https://github.com/lanmaster53/recon-ng)
TheHarvester — harvest emails/hosts. (https://github.com/laramies/theHarvester)
crt.sh & Certificate Transparency — find hostnames in certs.
Wayback Machine — old pages often reference removed endpoints. (

https://web.archive.org

)

Example command (Amass passive)

amass enum -d example.com -passive -o amass_output.txt

2) Hunt in source code — GitHub, JS, and public repos

People accidentally commit secrets to source control, or expose internal URLs in JavaScript.

Search patterns security researchers use:

site:github.com “AWS_ACCESS_KEY_ID”
site:github.com “DB_PASSWORD”
Inspect .js bundles in the browser for fetch(...) endpoints or hard-coded keys.

Automated watchers (see next section) also monitor new commits in real time.

3) Secret scanning & live monitoring (automation)

Manual hunting is slow. Use scanners to speed things up:

TruffleHog — finds high-entropy strings in git history. (https://github.com/trufflesecurity/trufflehog)
Gitleaks — CI-friendly scanner for secrets. (https://github.com/zricethezav/gitleaks)
Shhgit — live GitHub leak discovery. (https://github.com/eth0izzle/shhgit)

Run these against your repos or integrate in CI to catch leaks before they go public.

Quick example (gitleaks as pre-commit/CI)

gitleaks detect --source=./ --report=gitleaks-report.json

4) Wayback Machine & historical artifacts

Old pages often contain references to endpoints that were later removed from navigation but remain live. Tools like waybackurls or gau collect archived URLs.

Example flow

Pull historical URLs for a domain.
Filter for .zip, .env, .sql, /admin/, /api/.
Test any paths that appear plausible.

Command snippet

echo “example.com” | waybackurls | grep -E “\.zip|\.env|/admin|/api” | sort -u

5) Directory / file brute forcing

Directory scans often reveal /backup/, /old/, /uploads/, or other forgotten directories.

Tools & tips:

Gobuster or dirsearch with curated wordlists (SecLists).
Try common extensions: .bak, .old, .zip, .sql, .env.

Gobuster example

gobuster dir -u https://dev.example.com -w /usr/share/seclists/Discovery/Web-Content/common.txt -t 50

6) Inspect JavaScript and API traffic (browser + proxy)

Modern web apps leak a lot in JS and API responses. Open DevTools → Network (XHR/fetch) → Sources to find endpoints, tokens, and debug fields.

Pro-tip: proxy the app through Burp Suite and use the site map + response search to find token, apiKey, key, authorization.

Command-ish sniff

curl -s https://example.com/static/js/app.js | grep -E “api|token|KEY|secret|env”

7) Search engines & specialized indexers

Google dorking: site:example.com “index of”, site:example.com filetype:env
Shodan: find exposed services (Elasticsearch, Redis, etc.) that may leak data. (

https://www.shodan.io

)
Public cloud search: grayhat/archived bucket indexes

A misconfigured Elasticsearch or S3 bucket is an easy win for an attacker.

8) Chaining small leaks into bigger compromises

Attackers rarely rely on a single reveal. Typical chain:

Find forgotten endpoint (via Wayback/Gobuster).
Endpoint returns JSON with a path to a backup.
Backup contains config.json with an API key.
API key allows enumerating storage or invoking privileged APIs → data exposure.

This is why least privilege, key rotation, and audit logging matter so much.

Defensive checklist — what you can do now ✅

Secret scanning in CI — enforce gitleaks / TruffleHog on every PR.
Environment variables — never hard-code credentials in code.
Short-lived credentials — prefer temporary tokens & IAM roles.
Remove public staging/dev hosts — or firewall them.
S3 / cloud storage ACLs — default to private, require MFA/ACL reviews.
Monitor CT logs & Shodan — detect unexpected certificates or open services.
Rotate keys immediately if a leak is found.
Bug bounty / disclosure policy — make it easy for researchers to report.

What to include in a good bug/incident report

If you find a leak (ethically), include:

Exact URL(s) and HTTP request/response (redact PII).
Clear PoC: screenshots + steps to reproduce.
Impact assessment: what an attacker could do.
Suggested remediation (rotate keys, revoke tokens, restrict access).
Contact information & offer to help verify a fix.

A clear report speeds up remediation and builds rapport with the vendor. ✍️

Mini (anonymized) case study — a real lesson

I once found a dev subdomain via Amass that referenced a backup.zip on an old page captured by Wayback. A quick test found /downloads/backup.zip publicly available. Inside was config.json containing a third-party API key. That key let me list a storage bucket — which contained user exports. I reported it through the vendor’s security contact; they made the bucket private, rotated keys, and thanked us for the report.

Lesson: tiny oversights cascade. Small hardening reduces big risk.

🧠 80+ AI Tools Vault 2025 — The Ultimate Collection

Unlock the future of productivity with 80+ handpicked AI tools that hackers, developers, and creators use daily.

From recon automation to AI-assisted learning — this vault is your secret weapon ⚡

🧰 Grab it here → AI Tools Vault 2025

📘 Bonus: Hacker’s Recon Guide

Want to master reconnaissance and OSINT like a pro?
This Recon Guide is a field-tested resource that teaches you every stage — from subdomain hunting to endpoint discovery.

🕵️‍♂️ Get it here → The Hacker’s Recon Guide