Security Research 101: From Bug to Vulnerability

**Security Research 101 — Part 1: When Is a Bug a Vulnerability?** A bug is behavior a developer did not intend. A security vulnerability is a weakness that can cross a security boundary or put confidentiality, integrity, or availability at risk. A page crashing is a bug; one account being able to read another account’s private data may be a vulnerability. Context matters: the same flaw can have very different impact depending on what is exposed and what access an attacker already needs. Here is the basic research loop: 1. **Confirm permission and scope.** Test software you own, a dedicated lab, or assets explicitly listed in a vulnerability disclosure program. A public website is not automatically fair game. Read the program’s rules first; permission only covers what it actually includes. 2. **Learn what “normal” looks like.** Choose one feature and note what the app should let each role do. Security bugs often appear where the observed behavior crosses a boundary the design is supposed to enforce. 3. **Reproduce the smallest safe example.** Use test accounts and synthetic data. Repeat only enough to confirm the behavior; do not access someone else’s data, change production records, or stress a service. 4. **Explain the impact.** State which boundary failed, the conditions needed to trigger it, and what could be affected. A scanner finding is a lead, not proof of a vulnerability. 5. **Report privately and clearly.** Include the affected product/version, concise reproduction steps, expected versus observed behavior, likely impact, and redacted evidence. Follow the owner’s disclosure channel and coordinate before publishing details. You do not need a huge toolkit to begin. Browser developer tools help you understand how a page communicates with its server. ZAP (Zed Attack Proxy) sits between a browser and an app so a tester can inspect requests and responses; it also has passive and active scanners. A scan alert is only a lead, so verify it manually. ZAP’s own guide warns that active scans send real attack traffic: run them only in a local lab or on systems you have explicit permission to test. OWASP’s Web Security Testing Guide gives you a structure for thinking about areas such as authentication, access control, input handling, and APIs. **Try it safely:** OWASP Juice Shop is deliberately vulnerable and built for training. Run it as a local lab, choose one beginner challenge, and write down the intended behavior, what you observed, and why it matters. Its built-in challenge flaws are for practice; do not carry the same tests over to unrelated websites. This series will build from that foundation: reading HTTP traffic, checking access-control boundaries, understanding fuzzers and scanners, and turning a confirmed finding into a useful report. Later lessons can show how a proof of concept demonstrates impact inside a lab without turning it into instructions for attacking real systems. Start with OWASP’s [Juice Shop training app](https://owasp.org/projects/juice-shop), its [Web Security Testing Guide](https://owasp.org/projects/web-security-testing-guide), the [ZAP getting-started guide](https://www.zaproxy.org/getting-started/), and OWASP’s [guidance for reporting security issues](https://owasp.org/security). OWASP notes that Juice Shop and WebGoat contain intentional practice flaws; for real findings, use the correct private channel and stay inside scope. ~cybersecurity