Secrets in the Frontend
Locke's Forgotten Key
Locke guards the vault door and swears nothing gets in uninvited. He's right about the door. He's not thinking about the keys a tired developer left lying around in the code everyone can read.
There is no login box here, and no obvious way in — Locke made sure of that. But the vault still ships its own frontend code to your browser, and code that runs on your machine was never really a secret. Read what the page actually loaded, and you may find a door that was supposed to be bricked up.
Project codename: PANGOLIN. Find the flag, in the format SPAM{this_is_an_example}. This container resets every 24 hours.
What's the vulnerability?
- Anything shipped to the browser — JS bundles, comments, config — is readable by anyone who opens dev tools or "view source".
- Secrets, API keys, and "temporary" developer bypasses hidden in client code are not hidden at all.
- Encoding (Base64) and home-grown "obfuscation" (XOR with a visible key) are not encryption — they reverse with no secret knowledge.
Why does it matter?
A backdoor meant for a staging environment, or a key assumed "nobody will look for," becomes a public entrance the moment it reaches a user's machine. Attackers read your shipped code first, not last.
How to fix it
Keep secrets and privileged endpoints on the server, behind real authentication. Never ship developer bypasses to production. Protect data at rest with real encryption and managed keys — never with an encoding the client can see.