Skip to main content

Insp3ct0r picoCTF 2019 Solution

Find a flag split across multiple parts of a web page's source code, stylesheet, and script files.

Published: April 2, 2026Updated: August 13, 2026

Description

Kishor Balan tipped us off about a website with something hidden inside. The flag is split across the HTML, CSS, and JavaScript.

Web

Open the provided challenge URL in your browser.

Solution

Want to try it yourself first?

The guided walkthrough reveals hints one step at a time.

Walk me through it
  1. Step 1Check the HTML source for part 1
    Observation
    The description says the flag is hidden inside the website, and the name Insp3ct0r points at the browser inspector. The raw HTML source, and any comments in it, is the first place to look.
    Right-click the page and select View Page Source (or press Ctrl+U). Scroll through the HTML and look for a comment containing part 1 of the flag.
    What didn't work first

    Tried: Opening DevTools (F12) and using the Elements panel to search for the flag.

    The Elements panel shows the live DOM after JavaScript has run, and it strips HTML comments entirely - they do not appear there. You need View Page Source (Ctrl+U) or the Sources panel to read the raw HTML including comments.

    Tried: Reading only the visible text on the rendered page, looking for something that looks like a flag.

    HTML comments are deliberately hidden from the rendered view - that is their purpose. The flag fragment is invisible unless you look at the underlying source. Use Ctrl+U or right-click and select View Page Source.

    Learn more

    HTML comments are denoted by <!-- comment text --> and are invisible in the rendered browser view but fully readable in the page source. Developers use them to leave notes, temporarily disable code, or mark sections for future work. In CTF challenges they are a classic hiding spot for flags or hints.

    Pressing Ctrl+U (or Cmd+U on Mac) opens the raw HTML source in a new browser tab. Alternatively, right-clicking and selecting "View Page Source" does the same. This is distinct from the browser's Developer Tools inspector, which shows the live DOM (which may differ from the original source if JavaScript has modified it). For finding comments, the raw source view is often more reliable.

    In real-world web security, HTML source inspection is the first step in web application reconnaissance. Developers sometimes accidentally leave database names, internal hostnames, API endpoints, version numbers, or even credentials in HTML comments. Always inspect source before proceeding to more advanced techniques.

  2. Step 2Check the linked CSS file for part 2
    Observation
    The HTML links an external stylesheet, and the description says the flag is split across HTML, CSS, and JavaScript. So that CSS file is the natural next place to check for a comment.
    In the page source, find the <link> tag pointing to the stylesheet. Open that CSS file URL directly. Look for a comment containing part 2 of the flag.
    What didn't work first

    Tried: Looking for part 2 only in the main HTML source after already finding part 1 there.

    The challenge explicitly splits the flag across three separate files. Once you have part 1 from the HTML, you need to follow the link tag in the source to the external CSS file and open that URL separately.

    Tried: Checking the Styles panel in DevTools instead of opening the raw CSS file URL.

    The DevTools Styles panel reformats CSS, shows only the rules matching the selected element, and strips comments. Navigate straight to the CSS file URL, which is in the link tag's href, to see the raw file with its comments intact.

    Learn more

    CSS comments use the /* comment */ syntax and are equally invisible in the rendered page but readable in the stylesheet source. External stylesheets are referenced via <link rel="stylesheet" href="/path/to/style.css"> in the HTML head. You can navigate to the CSS file URL directly in your browser to read its full contents including any comments.

    External CSS files are fetched by the browser as separate HTTP requests. In browser DevTools (F12), the Network tab shows all resources the page loads - stylesheets, scripts, images, fonts, API calls - making it easy to enumerate everything included in a page. The Sources tab lets you browse and read all loaded files directly within DevTools.

    From a security perspective, CSS files can reveal internal path structures, framework versions (from file paths or comments), and occasionally sensitive data. CSS preprocessor source maps (.css.map files) can expose original SCSS/LESS source, which sometimes contains more context about the application's structure.

  3. Step 3Check the JavaScript file for part 3
    Observation
    The HTML also includes a script tag pointing at an external JS file. Two of the three parts came out of HTML and CSS comments, so the JS file is the only place left for the third.
    Find the <script> tag pointing to an external JS file. Open that URL. Look for a comment containing part 3 of the flag. Concatenate all three parts to form the complete flag.
    What didn't work first

    Tried: Looking at the Console tab in DevTools for the flag instead of reading the JS file source.

    The Console tab only shows runtime output: logged messages and errors. The comment holding part 3 is in the JavaScript source file itself. Open the script URL directly, or use the Sources panel, to read the full text including comments.

    Tried: Trying to combine only part 1 and part 2 and submitting early, assuming part 3 is optional.

    The flag is split into three pieces that must be concatenated in order to form a valid picoCTF{...} flag, and a partial string will not be accepted. Confirm you have found comments in all three files, HTML, CSS, and JS, before assembling.

    Learn more

    JavaScript comments come in two forms: single-line (// comment) and multi-line (/* comment */). External JS files referenced via <script src="/path/to/script.js"></script> can be read by navigating to their URL directly in the browser or viewing them in DevTools Sources panel.

    JavaScript files are often a goldmine in web security assessments. Beyond comments, JS files may contain hardcoded API keys, internal endpoint URLs, client-side authentication logic, hidden form parameters, and debug functionality left in production. Source maps (.js.map files) can expose the original unminified TypeScript or framework source, which is even more readable.

    The pattern of splitting a flag (or secret) across multiple files is a teaching device, but it mirrors real-world reconnaissance: sensitive data is rarely all in one obvious place. Thorough enumeration of all page resources - HTML, CSS, JS, images, API responses - is standard practice in web application penetration testing. Browser DevTools, Burp Suite, and tools like wget --mirror or httrack help automate this enumeration.

Interactive tools
  • Strings ExtractorPull printable text from any binary, library, or image. ASCII and UTF-16 detection, configurable minimum length, flag-like highlight, no command line needed.

Flag

Reveal flag

picoCTF{tru3_d3t3ct1ve_0r_ju5t_lucky?d3db9182}

Web developers frequently leave comments in HTML/CSS/JS that expose internal notes - in CTFs those comments often contain flags split across multiple files.

Key takeaway

Every resource the browser loads for a page, HTML, CSS, JavaScript, source maps, is sent in full to the client and readable with standard developer tools. The browser never strips comments, so anything left in one is visible to anyone who looks, which is why comments so often leak credentials, internal endpoints, API keys, and version numbers. In web penetration testing, enumerating every loaded resource in the Network tab and reading its raw source comes before any active testing.

Related reading

Useful tools for Web Exploitation

Where to go next