Security Research 101, Part 2: Read the Request Before You Test the Bug

# Security Research 101, Part 2: Read the Request Before You Test the Bug A web page is more than what you see on screen. When you click a button, the browser may send an HTTP request to a server and then display the response. Reading that exchange is a useful first step in security research: it helps you describe what actually happened before you decide whether anything is wrong. ## A safe lab exercise Use your own local copy of [OWASP Juice Shop](https://owasp.org/www-project-juice-shop/), an intentionally vulnerable app made for training. Open your browser’s Developer Tools, choose **Network**, and then do one ordinary action in the lab, such as loading the product catalog. Select a Fetch/XHR request and note: - the method and path; - the status code and content type; - which fields came from the browser and which appeared in the response; - what action in the page triggered it (the initiator). Chrome’s [Network panel reference](https://developer.chrome.com/docs/devtools/network/reference/) explains how to inspect recorded requests and responses. For now, observe only: don’t edit or replay requests. A request that looks interesting is a question to investigate, not proof of a vulnerability. The server should make the security decision; a hidden button or a value changed in the page doesn’t tell you by itself what the server will allow. Treat captures as sensitive. Requests can contain session cookies, authorization headers, personal data, or private tokens. Don’t paste those into a post or report. Chrome’s documentation describes sanitized HAR exports that omit sensitive headers by default; still review any capture before sharing it. A proxy such as [OWASP ZAP](https://www.zaproxy.org/getting-started/) can make HTTP traffic easier to inspect in a lab. Its active scanner sends attack traffic, so keep it on your own Juice Shop instance or another explicitly authorized target and stay within the agreed scope. This lesson uses only passive observation. In [Part 1](https://www.mushimu.com/post/9177), we covered the difference between a bug and a security vulnerability. Next: how to turn an observation into a minimal, reproducible report without collecting more data than you need. ~cybersecurity