STEP I: Start the machine and go to the attacker machine and open the link also using curl I verified the connection

┌──(kali㉿kali)-[~]
└─$ curl -I http://10.49.133.132:5000
HTTP/1.1 200 OK
Server: Werkzeug/3.1.5 Python/3.12.3
Date: Fri, 20 Feb 2026 13:37:05 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 1040
Vary: Cookie
Connection: close

STEP II: Now using gobuster we get two directories

└─$ gobuster dir -u http://10.49.133.132:5000 -w /usr/share/wordlists/dirb/common.txt
===============================================================
Gobuster v3.8.2
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://10.49.133.132:5000
[+] Method:                  GET
[+] Threads:                 10
[+] Wordlist:                /usr/share/wordlists/dirb/common.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.8.2
[+] Timeout:                 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
letters              (Status: 302) [Size: 231] [--> /login?next=%2Fletters]
login                (Status: 200) [Size: 1017]
logout               (Status: 302) [Size: 229] [--> /login?next=%2Flogout]
register             (Status: 200) [Size: 1048]
Progress: 4613 / 4613 (100.00%)

STEP III: From register page we register with any username and password then login and see the page

None

STEP IV: Now we see "New Letter" option is exist so we tap and write something on it and send

None

STEP V: We can simply see our messege is appeard and tap and open it

None

We now analyse the url and try to perform IDOR, so simply http://10.49.133.132:5000/letter/3 this will became ../2 in the URL

None

STEP VI: Again move with ../1 parameter and see the response

None

Here, we can see our flag.

THM{1_c4n_r3ad_4ll_l3tters_w1th_th1s_1d0r}

Conclusion: Conclusion

Insecure Direct Object Reference (IDOR) remains one of the most prevalent and impactful authorization flaws, not because it is complex, but because it is often overlooked. When applications trust user-supplied identifiers without enforcing proper access controls, they expose sensitive data and functionality to unauthorized users. Preventing IDOR requires a consistent, defense-in-depth approach: server-side authorization checks on every request, indirect object references where appropriate, least-privilege access models, and thorough testing across roles and endpoints. By treating authorization as a core security requirement — not an afterthought — organizations can significantly reduce the risk of IDOR and strengthen the overall resilience of their applications.