How Pentesters Hunt for Secrets in Page Source (Real-World Walkthrough Using a Lab)

One forgotten HTML comment leaked an admin path, a token and a flag. Here is the exact process I follow to find leaks like this on real targets.

Practice labs often give you a hint in the title. Real targets don't. In a real engagement, nobody tells you where to look, so what matters is having a repeatable process. In this post I walk through an easy WebVerse lab, Marginalia the Developers Left Behind, and treat it the way I would treat a real web application test.

Step 1: Understand the Target Before Touching Anything

The target is the website of Vellichor Press, a fictional literary magazine. It has Issues, About, Contributors and Subscribe pages.

Before testing anything, I map the attack surface:Before testing anything, I map the attack surface:

What pages and features exist?
Is there a login, an API, or an admin area?
What technology is it built with?

For a brochure-style site like this, the only user input is the mailing list form. So the likely weakness is not an exploit, it is information leaking from the site itself. That is the first lesson: always ask what the application is exposing before asking how to break it.

Step 2: Check What the Server Already Hands You

Everything the browser receives is visible to the user. So I check, in order:

Response headers and cookies_ for secrets, tokens and version info_
Page source_ for comments, hidden fields and internal paths_
JavaScript files_ for API endpoints and keys_
robots.txt and sitemap.xml for paths the owner did not want indexed

_Headers and cookies were clean here, so I moved to the page sou_rce.

Step 3: Read the Page Source

I opened the source with right-click → View page source (or Ctrl + U)

crolling through a long source file by eye is slow and easy to get wrong. Searching for <!-- is faster, and on a real engagement I would automate it:

# list HTML comments on one page
curl -s https://TARGET/ | tr '\n' ' ' | grep -oP '<!--.*?-->'
# repeat for every page you discovered
for p in / /issues /about /contributors; do
  echo "== $p"
  curl -s "https://TARGET$p" | tr '\n' ' ' | grep -oP '<!--.*?-->'

# list HTML comments on one page
curl -s https://TARGET/ | tr '\n' ' ' | grep -oP '<!--.*?-->'
# repeat for every page you discovered
for p in / /issues /about /contributors; do
  echo "== $p"
  curl -s "https://TARGET$p" | tr '\n' ' ' | grep -oP '<!--.*?-->'

In Burp Suite, you can do the same with a regex search for <!-- across the whole proxy history. That matters because a comment might exist on a page you never opened by hand.

Step 4: The Finding

Just above the footer, I found a developer note:

In a lab, you copy the flag and stop. In a real test, this single comment tells you much more:

Flag: WEBVERSE{488995bf7e0e0d6***********} (partially hidden on purpose)

Step 5: Think Like an Attacker, Not Just a Flag Hunter

What the comment leaked, and why it matters

/staff/admin: a hidden admin area that was never meant to be public.On a real engagement, my next step would be to check whether the token actually works. Only do this if the target is in scope and your rules of engagement allow it. If it works, I would verify access with the smallest possible action, take a screenshot as proof, and stop. I would not browse payment data, download anything or change anything. In bug bounty and pentesting, proving the impact is enough.
In this lab I stopped at the flag, because that was the goal of the lab.
token=stripe-recon-2026: a hardcoded token that may give direct access to that admin area.
"Stripe export": the admin area likely touches payment-related data.
TODO(elias) and e.l: a staff name and initials, useful for social engineering and username guessing.
Date and time: they show when the note was written, so the token may be old and never rotated.

Step 6: How I Would Report It

Title:_ Sensitive information and hardcoded token exposed in HTML comment_
Weakness:_ CWE-615 (Sensitive Information in Source Code Comments), related to CWE-798 (Hardcoded Credentials)_
Severity:_ depends on the token. Informational if it is dead, High if it opens an admin panel with payment data._
Proof:_ screenshot of the comment and the URL where it appears_
Fix:
Strip HTML comments from production builds automatically
Never place secrets or internal paths in comments
Add a CI check that fails on TODO, FIXME or token inside comments
Rotate any token that has been exposed, even briefly
Protect admin routes with real authentication, not a shortcut token in the URL

What You Should Take Away

Have a process. Real targets don't give hints. Headers, source, JavaScript, robots.txt is a checklist you can run every time.
Automate the boring part. One grep beats scrolling through thousands of lines.
Look at the impact, not only the flag._ One comment gave a hidden path, a credential and an internal tool name._
Stay in scope._ Finding a token does not mean you are allowed to use it freely._
Simple bugs get paid._ Leaked secrets in source code are a regular finding in real bug bounty programs._

Thanks for reading! Follow me for more lab writeups and web security walkthroughs.