TryHackMe Fools Mate Walkthrough Easy Client-Side Validation Bypass

🎯 Room Info

📖 What This Room Is About

Fools Mate is a small, focused room built around one lesson that trips up a lot of junior developers: anything enforced only in the browser is not actually enforced.

The app has a form (or feature) that looks locked down — greyed-out buttons, JavaScript checks, "you're not allowed to do that" messages — but none of it is backed up on the server side. This room walks through:

1. 🌐 Finding the restricted feature
2. 🔍 Understanding why it's blocked (client-side JS, not server logic)
3. 🛠️ Bypassing the restriction by editing the request directly
4. 🚩 Reaching the flag the "locked" feature was hiding

🧠 Skills You'll Practice

• Reading and editing JavaScript in browser dev tools
• Intercepting and modifying HTTP requests (Burp Suite)
• Recognizing client-side-only validation
• Understanding why server-side validation is non-negotiable

🛠️ Step-by-Step Walkthrough

1️⃣ Scan and browse the target

nmap -sC -sV -oN nmap-initial.txt <TARGET_IP>

HTTP is open. Load the site and look for the restricted feature — often a button, form field, or action that's disabled, hidden, or gated behind a message like "not available" or "access denied."

2️⃣ Inspect the page source

Open dev tools (F12 or Ctrl+Shift+I) and look at the Elements and Sources tabs.

Common patterns you'll find in a room like this:

• A button with disabled in its HTML attribute
• A JavaScript function that checks a condition client-side before allowing a submit
• A hidden form field controlling access (e.g. <input type="hidden" name="isAdmin" value="false">)

💡 Why this matters: anything visible in your browser's dev tools is fully under your control, not the server's. If the only thing stopping an action is JavaScript running on your machine, it's not a real security control.

3️⃣ Try the easy bypass first

Sometimes simply removing the disabled attribute in the Elements panel, or flipping a hidden field's value, is enough:

<!-- Before -->
<input type="hidden" name="isAdmin" value="false">

<!-- After (edited live in dev tools) -->
<input type="hidden" name="isAdmin" value="true">

Submit the form and see if the server actually re-checks that value — in this room, it usually doesn't.

4️⃣ Intercept the request with Burp Suite

If the front-end fix isn't enough (page reloads reset your edits, or JS blocks the submit entirely), intercept the raw HTTP request instead:

1. Set your browser proxy to Burp Suite (127.0.0.1:8080)
2. Turn on Intercept in the Proxy tab
3. Trigger the form submission in the browser
4. Edit the intercepted request body directly — for example, change a parameter like:

isAdmin=false

to:

isAdmin=true

1. Forward the request

💡 Why this matters: the browser only shows you a rendered view of what the server expects. The real conversation happens in raw HTTP requests — Burp lets you see and change that conversation directly, bypassing any client-side restriction entirely.

5️⃣ Confirm the bypass worked

After forwarding the modified request, the page should now show the previously restricted content or action succeeding — this is your signal the server trusted the client-supplied value instead of checking its own session/permission state.

6️⃣ Grab the flag

The restricted feature typically reveals the flag directly once bypassed, or unlocks a page/download containing it.

cat flag.txt

🚩 Click to reveal: flag

Redacted — swap in your own captured flag if you want to keep a private record.

📋 Every Command / Action, In Order

nmap -sC -sV -oN nmap-initial.txt <TARGET_IP>
# Open dev tools -> inspect disabled elements / hidden fields
# Try editing the DOM directly first
# If that fails, route traffic through Burp Suite:
#   Intercept ON -> submit form -> edit parameter (e.g. isAdmin=false -> true) -> Forward

🎓 Key Takeaways

• Never trust the client. JavaScript validation, disabled buttons, and hidden fields are all UX conveniences — they exist to make the interface feel polished, not to enforce security.
• Every restriction needs a matching server-side check. If the server doesn't independently verify permissions on every request, the client-side gate is decorative.
• Burp Suite (or any intercepting proxy) is the real test. If you can't reproduce a restriction bypass by editing the raw request, you haven't actually tested the security control — you've only tested the UI.
• This exact bug class shows up constantly in real apps — broken access control consistently ranks in the OWASP Top 10 for a reason.