[This lab](https://portswigger.net/web-security/access-control/lab-unprotected-admin-functionality) demonstrates a simple but high-impact vulnerability: **unprotected admin interfaces**. These occur when sensitive functionality (like user deletion or settings access) is exposed on a hidden URL without any authentication or authorization checks. In the real world, these endpoints are often **hidden but not protected** — relying on obscurity (e.g., `/admin`, `/panel`, `/dashboard`) instead of proper access control. --- ##### Step-by-Step Exploitation ###### 1. Discover Admin Panel via `robots.txt` Append the following to the lab URL: ``` /robots.txt ``` Example: ``` https://YOUR-LAB-ID.web-security-academy.net/robots.txt ``` Expected output: ``` User-agent: * Disallow: /administrator-panel ``` This reveals the path to the admin interface. ![[CleanShot 2025-05-05 at 22.50.18.png]] --- ###### 2. Access the Admin Panel Navigate to: ``` /administrator-panel ``` Full URL: ``` https://YOUR-LAB-ID.web-security-academy.net/administrator-panel ``` You should land on an **admin interface** that is completely unprotected — no login, no session check. --- ###### 3. Delete Carlos Use the UI to delete the user `carlos`. This action will mark the lab as **Solved**. --- ##### Why It Works The application incorrectly assumes that hiding sensitive routes (e.g., behind `robots.txt`) is sufficient for protection. But: - **robots.txt is public** — it's designed to be read by bots (and pentesters) - There's **no authentication check** on the admin panel route --- ##### Real-World Examples - Hidden admin panels found via fuzzing (`/admin`, `/cpanel`, `/dashboard`) - Sensitive functionality exposed via JS (`admin.js`, `debug=true`) - APIs that lack authentication on privileged methods (`DELETE /users/:id`)