The Comment That Handed Me a Secret Key

Welcome back to the series.

Last lab, we made a website angry and read its crash report. The error told us its name. This lab is quieter. No crashing. No bad input. The site just left a note for itself — and forgot to delete it.

That note was all I needed.

Let me show you.

A Quick Recap of Where We Are

If this is your first lab here — glad you found me. We're working through information disclosure: the art of getting an app to leak details it never meant to share.

Last time the leak was loud. We broke the input and a crash report fell out.

This time the leak is silent. It was already there, written into the page, waiting for someone to read it.

That someone is you.

What the Bug Actually Is

Developers leave notes in their code. These are called comments (comment = a note in the code that does not show on the page, but anyone can read it in the source).

Comments are invisible to a normal visitor. But the source code is not hidden. Anyone can open it.

Sometimes a developer leaves a comment pointing to a private page — a debug tool, a config dump, a test file. They assume nobody will look. Then they ship it to the live site and forget.

That assumption is the bug.

What I Noticed

I opened the lab. No login. No search box. Just a normal shop page.

So I went to my favorite first move: I read the source.

The page source is the raw code behind the website (source = the code your browser reads to draw the page — you can read it too). To open it, press CTRL+U.

Then I did the slow, boring thing that pays off — I read it. Top to bottom. Looking for anything the developer left behind.

What Fell Out

A comment is a note the developer leaves in the code (comment = a note in the source that does not show on the page, but anyone can read it). This one was a leftover. And it pointed to a file path:

/cgi-bin/phpinfo.php

/cgi-bin/phpinfo.php

(cgi-bin = an old folder where servers keep scripts. phpinfo = a built-in PHP report that dumps everything about the server.)

So I took the path and added it to the website address:

https://0a6a006604924a3a886f7af0002c0058.web-security-academy.net/cgi-bin/phpinfo.php

The page loaded.

And it was everything. The PHP version. Every loaded module. Internal file paths. And the environment settings

The page loaded. And it was massive — a wall of text. The PHP version, every loaded module, internal file paths, and all the environment settings.

Too much to scroll. So I searched it. CTRL+F (the find box — it searches the text on the page you're looking at), and I typed the word I was hunting for:

SECRET_KEY

SECRET_KEY

It jumped straight to it. The secret key, sitting in plain text.

I copied the value, submitted it, and the lab was solved.

No tools. No payload. Just CTRL+U to read the source, one click to open the debug page, and CTRL+F to grab the prize.

Why This Works — The Mistake Behind It

Two mistakes stacked on top of each other here.

First mistake: the developer left a comment pointing to a private tool. Comments feel invisible because they don't show on the page. But "doesn't show" is not "hidden." The source is public. Always.

Second mistake: that private tool was a phpinfo page left live in production. It was meant for testing on a local machine. Someone copied the code to the live server and never stripped it out.

The result is brutal. A SECRET_KEY is not just "a setting." Apps use it to sign user sessions — the digital wristband that proves you are logged in (signing = stamping data so the server trusts it came from itself). If an attacker has that key, they can forge the wristband. They can mint a session for any account they want. Including the admin.

So a forgotten comment becomes a full account takeover.

The fix is simple and cheap. Never leave debug or phpinfo pages on a live site. Strip developer comments before shipping. And the moment a secret key is exposed — rotate it. Once seen, it's burned.

Real Bug Bounty Payouts — This Pays

Leaked secrets and debug pages get reported and paid all the time. Here's how hunters turn them into money.

$5,000 — SaaS company (HackerOne). A researcher found a phpinfo page left live in production. It leaked the framework secret key used to sign sessions. They didn't stop at "info leak." They used the key to forge an admin session and proved full account takeover. The chain is what paid. The leak alone was low. The takeover was critical.

$3,000 — Fintech app (Bugcrowd). A developer comment in the page source pointed to a hidden /debug/ endpoint. That endpoint dumped database credentials in plain text. The researcher used those credentials to connect directly to the database. The comment was the map. The credentials were the door.

$1,500 — E-commerce platform (private program). An exposed phpinfo page leaked internal file paths, the exact PHP version, and loaded modules. No secret key this time. But the program paid anyway — knowing the exact version and internal layout dramatically lowers the effort for any future attacker.

$750 — Healthcare portal. A leftover debug config file exposed the API keys for a third-party email service. The researcher showed they could send emails as the company. In a regulated industry, that's both a takeover risk and a compliance problem. Both raised the payout.

The pattern is always the same. Read the source. Find the breadcrumb. Follow it to the page nobody was supposed to see.

Where to Hunt This in Real Apps

Now you know the bug. Here's where it hides.

Page source, every time. Press CTRL+U on every page and read it. Look for words like debug, test, todo, key, password, secret, admin. Developers leave breadcrumbs here.

HTML comments. They feel invisible to the dev but they're public. They leak hidden paths, old endpoints, and internal notes.

Classic debug paths. Add these to your wordlist and try them by hand: /cgi-bin/phpinfo.php, /phpinfo.php, /debug, /test, /info.php, /.env, /config.

Anything that dumps config. phpinfo, server-status pages, and framework debug screens all spill versions, paths, and environment variables. Environment variables are where the secrets live.

Third-party JavaScript files. Open the .js files a site loads. Developers hardcode API keys and internal URLs in them more often than they should.

The test is always the same. Don't just look at the page. Read everything behind the page. The source, the comments, the loaded files. The good stuff is rarely on the surface.