Unminify — picoCTF Write-up | Sometimes the Flag Is Right in Front of You

Introduction

While practicing web exploitation challenges on picoCTF / CyLab Academy, I came across a simple but interesting challenge called Unminify.

This challenge was a good reminder that cybersecurity is not always about using advanced tools or complicated payloads. Sometimes, being curious, attentive, and checking the basics carefully is enough.

The challenge presents a simple website that claims the browser has already received the flag.

That statement immediately gave me something to think about: If my browser has already received the flag, where exactly is it?

Challenge: Unminify Category: Web Exploitation Platform: picoCTF / CyLab Academy Main Concept: Source Code Inspection / Information Disclosure

Exploring the Website

After launching the challenge, I was presented with a very simple webpage.

The page displayed the following message:

The interesting part was the statement that my browser had already received the flag.

That sounded like a direct hint.

If the browser had already received the flag from the server, then the flag might already exist somewhere in the page response.

Looking Around the Application

I spent a little time checking the website normally.

There wasn't much functionality available. No login page, no forms, no search box, and nothing obvious to interact with.

I didn't spend too much time trying random things because the message on the page kept pointing me back to one idea:

The browser already has the flag.

So instead of looking for a complicated vulnerability, I decided to check what the server had actually sent to my browser.

Checking the Page Source

One of the simplest things we can do when analyzing a webpage is inspect its HTML source.

I opened the page source using:

View Page Source

The source initially looked difficult to read because most of the HTML was compressed onto a very small number of lines.

This is known as minified HTML.

But after looking through it carefully, I noticed something interesting inside one of the paragraph elements.

There it was.

The flag was already present directly inside the HTML response:

picoCTF{pr3tty_c0d3_622b2c88}

And just like that, the challenge was solved! 🚩

Understanding What Happened

The important clue on the homepage was:

Your browser has successfully received the flag.

That statement was literally true.

When I requested the webpage, the server returned HTML containing the flag.

The browser received something conceptually like:

Server → HTML Response → Browser

And somewhere inside that HTML response was:

picoCTF{...}

The browser didn't visibly display the flag on the rendered page, but that didn't mean the flag wasn't there.

By viewing the raw HTML source, I could see information that wasn't obvious in the normal page view.

Why Was the Flag Not Visible Normally?

Browsers don't simply display every piece of HTML as plain text.

HTML elements, attributes, CSS rules, hidden elements, comments, scripts, and other information may exist in the source without appearing directly on the rendered page.

That means there can be a difference between:

What the user sees

and

What the browser receives.

For security testing, both are important.

The Complete Solution

The entire challenge can be summarized as:

Open Challenge → Read the Hint → Explore the Page → Notice Browser Already Received the Flag → View Page Source → Inspect Minified HTML → Find Flag 🚩

No brute force.

No complicated payload.

No special exploitation tool.

Just careful observation and source code inspection.

Real-World Security Lesson

Although this is a beginner CTF challenge, the concept connects to an important real-world security issue: Information Disclosure.

Developers sometimes assume that information is protected simply because it isn't displayed on the screen.

For example, sensitive information might accidentally appear inside:

• HTML comments
• Hidden form fields
• JavaScript variables
• API responses
• Source maps
• Debugging information
• Client-side configuration
• Minified JavaScript
• Page source

But if the server sends sensitive information to the client's browser, the user can potentially inspect it.

A useful rule to remember is:

If you don't want the user to know something, don't send it to their browser.

How to Prevent Information Disclosure

Sensitive information should never be included in client-side responses unless the user is authorized to receive it.

Applications should avoid exposing secrets, credentials, API keys, internal configuration, or sensitive debugging information inside HTML and JavaScript.

Developers should also review production builds to make sure unnecessary comments, debugging information, and development data are removed.

Most importantly, security decisions should always be enforced on the server side.

Hiding information from the interface is not the same as protecting it.

What I Learned

This challenge reinforced a few simple but important habits:

• Read every hint carefully.
• Understand what the application is telling you.
• Explore the website before trying complicated attacks.
• Check the HTML source when something feels hidden.
• Remember that the rendered page and raw response are different.
• Minified code can still be inspected.
• Minification is optimization, not security.
• Sensitive information should never be unnecessarily sent to the client.

The biggest lesson for me was to stay curious and attentive.

I checked the website for a while and didn't find anything useful in the visible interface. Instead of overcomplicating it, I went back to the clue that the browser had already received the flag.

That small observation led directly to the solution.

Conclusion

Unminify was a simple but useful picoCTF challenge.

There was no complex exploit involved. The website itself told me that my browser had already received the flag.

After checking the visible website and finding nothing obvious, I inspected the page source. Inside the minified HTML, the flag was sitting directly in the response.

The challenge demonstrated an important mindset for web security:

Don't immediately look for the most complicated attack. Observe carefully, follow the clues, and check the basics first.

Sometimes the information you're looking for is already right in front of you.

Connect With Me

LinkedIn: https://www.linkedin.com/in/affanhaxor Instagram: https://instagram.com/affan_haxor

Follow me for more CTF write-ups, web security labs, and AppSec content.