OWASP Juice Shop — Web Application Security

Case summary

A controlled web-application security project using OWASP Juice Shop to practice reconnaissance, request interception, vulnerability validation, and security reasoning.

Overview

The sections below are a concise case-file overview. The detailed assessment report is kept separate so the case page remains readable while the complete evidence and findings remain available to readers who want them.

Context

OWASP Juice Shop is an intentionally vulnerable web application used for security education. I used it to strengthen the fundamentals of web assessment and to connect browser behavior with the underlying HTTP requests.

Objective

The goal was to build a repeatable approach for investigating web application behavior instead of treating individual challenges as isolated puzzles.

Scope

Testing was restricted to the local training application.

Methodology

Reconnaissance

I first mapped the visible application functionality and observed the requests generated during normal interaction. Burp Suite provided a clearer view of methods, parameters, cookies, headers, and server responses.

Investigation

I then tested how application behavior changed when requests were modified. The emphasis was on understanding what the server validated and what assumptions existed in the client.

Validation

Potential issues were reproduced in the controlled environment and documented with the request/response evidence necessary to explain the security consequence.

Findings

This project reinforced a central web-security principle: the browser is an interface, not a security boundary. Any security decision that matters must ultimately be enforced by the server.

Detection Angle

Useful defensive signals include abnormal request sequences, repeated access-control failures, suspicious parameter manipulation, and authentication anomalies. Application logs become much more valuable when they retain enough context to reconstruct the sequence of events.

Remediation

Security controls should be enforced server-side, inputs should be validated according to their intended use, sensitive actions should require appropriate authorization, and security-relevant events should be logged consistently.

What I Learned

Intercepting traffic changed the way I think about web applications. What looks like a simple button in a browser is often a much richer sequence of requests and trust decisions underneath.

What I’d Do Differently

I would keep a structured evidence log from the first request rather than collecting screenshots and notes only after a vulnerability becomes obvious.