Web Application Security Assessment of OWASP Juice Shop: Methodology, Testing Workflow, and Lessons Learned

Introduction

Learning individual web vulnerabilities is only one part of becoming effective at penetration testing.

A real security assessment requires a broader process: understanding the application, defining the attack surface, analyzing requests and responses, testing security controls systematically, collecting evidence, validating observations, and documenting results clearly.

To practice this process, I performed a structured web application security assessment against OWASP Juice Shop in a controlled local lab environment.

OWASP Juice Shop is an intentionally vulnerable web application designed for security education. Rather than treating the application as a collection of challenges to solve, I approached it as a penetration-testing target and followed a repeatable assessment workflow.

The objective was to strengthen practical skills in:

• Application reconnaissance
• Attack-surface mapping
• HTTP request and response analysis
• Authentication and session testing
• Authorization testing
• Input validation testing
• API analysis
• Vulnerability validation
• Evidence collection
• Security reporting

All testing described in this article was performed against an intentionally vulnerable application in an authorized laboratory environment.

---

Assessment Overview

Target: OWASP Juice Shop

Environment: Local security laboratory

Assessment Type: Authorized web application security assessment

Primary Testing Tool: Burp Suite Professional

Testing Approach: Manual-first testing supported by structured reconnaissance and targeted tooling

Objective: Practice an end-to-end web application penetration-testing methodology rather than simply completing individual vulnerability challenges.

The assessment followed this general workflow:

Scope Definition
      ↓
Application Familiarization
      ↓
Attack-Surface Mapping
      ↓
HTTP Traffic Analysis
      ↓
Endpoint and API Discovery
      ↓
Authentication and Session Review
      ↓
Authorization Testing
      ↓
Input Validation Testing
      ↓
Manual Vulnerability Validation
      ↓
Evidence Collection
      ↓
Impact Assessment
      ↓
Reporting and Remediation

This structure helped keep testing organized and prevented the assessment from becoming a sequence of unrelated payload attempts.

---

1. Scope and Testing Boundaries

Before testing any application, the first requirement is understanding what is authorized.

For this assessment, the target was a locally hosted instance of OWASP Juice Shop specifically intended for security practice.

The scope was limited to the lab application and its associated functionality.

No external or unrelated systems were targeted.

Even when working with intentionally vulnerable applications, practicing scope discipline is useful because the same habit applies directly to professional penetration tests and bug bounty programs.

Before beginning an assessment, I want to be able to answer four questions:

1. What systems am I authorized to test?
2. What testing techniques are permitted?
3. What systems or actions are excluded?
4. What evidence must be collected for reporting?

Defining those boundaries first makes the rest of the assessment safer and more structured.

---

2. Application Familiarization

Before attempting vulnerability testing, I manually explored the application.

This stage is easy to underestimate.

Immediately launching scanners or injecting payloads can cause important application logic to be missed. Understanding how legitimate users interact with the application provides context for later security testing.

I reviewed functionality such as:

• User registration
• Authentication
• Product browsing
• Search
• Shopping cart operations
• User profile functionality
• Account-related workflows
• Client-side interactions
• API-driven functionality

While browsing the application, I observed how actions performed in the browser translated into HTTP requests.

This created an initial map:

User Action
      ↓
Browser Request
      ↓
Application Endpoint
      ↓
Parameters / JSON Data
      ↓
Authentication Context
      ↓
Server Response

This mapping became the foundation for subsequent testing.

Key lesson

Understand normal application behavior before attempting abnormal behavior.

If I do not understand what a request is supposed to do, it becomes much harder to determine whether modified behavior represents a genuine security issue.

---

3. Configuring Burp Suite for Traffic Analysis

Burp Suite Professional was used as the primary interception and manual testing platform.

Browser traffic was routed through Burp Proxy so that requests and responses could be inspected during normal application usage.

The core workflow was:

Browser
   ↓
Burp Proxy
   ↓
OWASP Juice Shop
   ↓
Burp HTTP History
   ↓
Interesting Request
   ↓
Repeater
   ↓
Controlled Modification
   ↓
Response Comparison

I used HTTP history to observe application behavior and identify requests worth investigating further.

Interesting requests could then be sent to Burp Repeater, where individual parameters, headers, cookies, identifiers, or request bodies could be modified without repeatedly navigating through the browser interface.

This approach was especially useful because it separated:

• Discovery
• Hypothesis formation
• Manual testing
• Validation

Instead of changing many variables simultaneously, requests could be modified systematically and responses compared.

---

4. Attack-Surface Mapping

After understanding the basic application workflow, I began mapping the exposed attack surface.

The objective was not simply to collect URLs.

I wanted to understand:

• What functionality exists?
• Which endpoints process user-controlled data?
• Which endpoints require authentication?
• Which requests contain object identifiers?
• Which operations modify application state?
• Which APIs expose or manipulate data?
• Which functionality appears security-sensitive?

Potential attack surfaces included:

Authentication
├── Login
├── Registration
└── Account-related workflows

User Functionality
├── Profile
├── Session state
└── User-specific resources

Application Inputs
├── Search
├── Form fields
├── URL parameters
└── JSON request bodies

Business Functionality
├── Products
├── Basket / cart
└── User actions

Backend Interfaces
└── API endpoints

This stage helped transform a collection of HTTP requests into a structured testing plan.

---

5. HTTP Request and Response Analysis

One of the most valuable parts of the assessment was manually inspecting HTTP traffic.

For interesting requests, I reviewed:

• HTTP method
• Endpoint
• Query parameters
• Request body
• JSON fields
• Cookies
• Authentication information
• Object identifiers
• Response status
• Response content
• Error behavior

A request might look ordinary in the browser while revealing much more information when inspected directly.

For example, an application action may expose:

POST /api/resource

{
    "userId": 123,
    "value": "example"
}

This immediately raises useful testing questions:

• Can userId be changed?
• Does the server verify ownership?
• Is authorization enforced server-side?
• Does changing the value alter another user's resource?
• Are hidden client-side values trusted by the backend?

The important lesson is that parameters are not vulnerabilities by themselves.

They are testing opportunities.

A security finding requires evidence that modifying a parameter produces unauthorized or unsafe behavior.

---

6. Authentication Testing

Authentication controls were reviewed to understand how the application handled identity verification and authenticated sessions.

Testing considerations included:

• Login request structure
• Credential handling
• Authentication responses
• Error behavior
• Session establishment
• Account-related workflows
• Differences between authenticated and unauthenticated access

A useful authentication-testing process is:

Observe Normal Login
      ↓
Capture Request
      ↓
Identify Authentication Inputs
      ↓
Modify One Variable
      ↓
Compare Server Behavior
      ↓
Validate Any Unexpected Result

The goal was not to send random authentication payloads.

Instead, I focused on understanding the application's assumptions about authentication and identifying where those assumptions could be tested.

Security principle

Authentication answers:

Who are you?

But successful authentication does not automatically mean authorization is implemented correctly.

That distinction became important during later testing.

---

7. Session Management Review

After authentication, I examined how session state was maintained.

Session security is critical because an application may have a secure login mechanism while still exposing authenticated users through weak session handling.

Areas reviewed included:

• Session tokens
• Cookies
• Authentication headers
• Token persistence
• Logout behavior
• Changes in session state after authentication

Relevant security questions included:

• How is the authenticated session represented?
• Is sensitive session information protected appropriately?
• Does logout invalidate the session as expected?
• Are authentication tokens exposed unnecessarily?
• Does the application correctly distinguish authenticated from unauthenticated requests?

The key lesson was to treat authentication and session management as related but separate security controls.

---

8. Authorization and Access-Control Testing

Authorization testing focuses on what an authenticated user is allowed to do.

This is different from authentication.

Authentication
"Who is the user?"

Authorization
"What is the user allowed to access or modify?"

During attack-surface analysis, I paid particular attention to requests containing:

• User IDs
• Resource IDs
• Basket identifiers
• Account references
• API object identifiers
• Privileged operations

When an identifier appeared to reference a user-specific resource, the testing process involved determining whether the backend independently verified that the current user was authorized to access that object.

A structured authorization test looks like:

Capture Authorized Request
      ↓
Identify Resource Identifier
      ↓
Establish Expected Access
      ↓
Modify Identifier or Context
      ↓
Replay Request
      ↓
Compare Response
      ↓
Determine Whether Server-Side Authorization Exists

This methodology is important when testing for weaknesses such as Insecure Direct Object Reference (IDOR) or Broken Object Level Authorization (BOLA).

Changing an ID alone does not prove a vulnerability.

The issue exists only if unauthorized access or modification is actually possible.

---

9. Input Validation Testing

User-controlled input was reviewed to understand how the application processed data.

Potential input locations included:

• Search fields
• Authentication forms
• URL parameters
• JSON values
• Profile fields
• API parameters
• Other application forms

Testing focused on how the application handled:

• Unexpected input
• Special characters
• Modified parameters
• Invalid values
• Encoded input
• Client-side versus server-side validation

The workflow was:

Identify Input
      ↓
Determine Expected Behavior
      ↓
Capture Baseline Request
      ↓
Modify Input Carefully
      ↓
Observe Response
      ↓
Compare With Baseline
      ↓
Investigate Anomalies

This process is more useful than blindly sending large payload lists.

An unexpected response may indicate something worth investigating, but it is not automatically a vulnerability.

Further validation is always required.

---

10. API Security Review

Modern web applications frequently rely heavily on backend APIs.

OWASP Juice Shop provided a useful environment for observing how browser actions interact with API endpoints.

API requests were reviewed for:

• HTTP methods
• Endpoint structure
• JSON request bodies
• Authentication requirements
• Object identifiers
• User-controlled fields
• Response data
• Authorization behavior

For each interesting endpoint, I considered questions such as:

Does this endpoint require authentication?

Does it verify authorization?

Can object identifiers be modified?

Does it expose more data than necessary?

Does the server trust client-controlled fields?

Can the request be replayed outside the normal UI workflow?

One particularly important lesson was that the browser interface should never be treated as the security boundary.

Client-side restrictions can often be bypassed simply by modifying HTTP requests.

Security controls must therefore be enforced by the backend.

---

11. Manual Validation With Burp Repeater

Burp Repeater was one of the most useful tools during the assessment.

When an interesting request was discovered, I could send it to Repeater and create a controlled baseline.

Then I modified one variable at a time.

For example:

Original Request
      ↓
Record Baseline Response
      ↓
Modify Parameter A
      ↓
Compare Response
      ↓
Restore Baseline
      ↓
Modify Parameter B
      ↓
Compare Again

This made it easier to determine which input actually influenced application behavior.

Repeater was useful for investigating:

• Parameters
• Object identifiers
• Authentication context
• Headers
• JSON fields
• Request methods
• Application responses

Key lesson

Controlled request modification produces better evidence than random payload testing.

When only one variable changes, it becomes much easier to explain why a particular behavior occurred.

---

12. Distinguishing Observations From Confirmed Findings

An important part of penetration testing is knowing when something is actually a vulnerability.

During testing, I separated observations into stages:

Observation
      ↓
Security Hypothesis
      ↓
Manual Test
      ↓
Reproduction
      ↓
Impact Validation
      ↓
Confirmed Finding

For example:

Observation:
A request contains a numeric object identifier.

Hypothesis:
The identifier may reference another user's resource.

Test:
Change the identifier under controlled conditions.

Validation:
Determine whether unauthorized data or functionality becomes accessible.

Conclusion:
Only classify the behavior as an access-control vulnerability if unauthorized access is reproducible.

This prevents speculative observations from being reported as confirmed vulnerabilities.

It also reduces false positives.

---

13. Evidence Collection

Evidence collection was treated as part of testing rather than something to do afterward.

For meaningful observations, useful evidence can include:

• Relevant HTTP requests
• Relevant HTTP responses
• Screenshots
• Affected endpoints
• Modified parameters
• Authentication context
• Reproduction steps
• Expected versus actual behavior

A useful evidence structure is:

Finding
├── Affected Component
├── Preconditions
├── Baseline Request
├── Modified Request
├── Observed Response
├── Reproduction Steps
├── Security Impact
└── Recommended Remediation

Evidence should demonstrate the issue clearly enough that another tester or developer can understand and reproduce it.

Screenshots can support a finding, but they should not replace technical evidence.

---

14. Reporting Methodology

A penetration test is incomplete if the results cannot be communicated clearly.

For a confirmed vulnerability, I use a structure similar to:

Title

Severity

Affected Component

Description

Technical Details

Steps to Reproduce

Evidence

Security Impact

Remediation

References

The report should answer three major questions:

1. What is wrong?
2. Why does it matter?
3. How should it be fixed?

A technically correct finding that cannot be understood by the intended audience loses much of its value.

This assessment reinforced that reporting is not separate from penetration testing.

It is part of the penetration-testing process itself.

---

15. Lessons Learned

1. Application Understanding Comes Before Exploitation

Exploring normal functionality first made later testing more efficient.

Understanding workflows helped identify where trust boundaries, user-controlled data, and security-sensitive operations existed.

2. HTTP Traffic Reveals the Real Application

The browser interface shows what the user is intended to see.

HTTP requests reveal how the application actually communicates with the backend.

Analyzing that traffic exposed endpoints, parameters, identifiers, session information, and API behavior that were important for security testing.

3. Manual Testing Is Essential

Automated tools are useful for coverage and speed, but they cannot replace reasoning.

Manual testing was especially important for:

• Authorization
• Session behavior
• API logic
• Workflow analysis
• Context-dependent vulnerabilities

4. Change One Variable at a Time

Controlled testing made response differences easier to understand.

Changing multiple parameters simultaneously makes it difficult to determine what caused an observed behavior.

5. An Observation Is Not Automatically a Vulnerability

Interesting behavior requires validation.

A parameter, error message, exposed endpoint, or scanner alert should be treated as a lead until its security impact is demonstrated.

6. Documentation Should Happen During Testing

Capturing evidence immediately made the reporting process much easier.

Trying to reconstruct requests, responses, and reproduction steps after testing is inefficient and risks losing important context.

7. Methodology Matters More Than the Number of Tools

The most important improvement from this assessment was not learning another command.

It was developing a repeatable process:

Understand
→ Map
→ Observe
→ Hypothesize
→ Test
→ Validate
→ Document
→ Report

Tools support that process; they do not replace it.

---

Security Principles Reinforced

The assessment reinforced several broader web security principles:

• Validate user-controlled input on the server.
• Enforce authentication consistently.
• Perform authorization checks for every protected resource and action.
• Never rely solely on client-side security controls.
• Protect session tokens and authentication state.
• Treat object identifiers as untrusted input.
• Minimize unnecessary API data exposure.
• Validate automated findings manually.
• Apply least privilege wherever possible.
• Maintain clear security logging and monitoring.
• Perform regular security testing throughout the development lifecycle.

---

Conclusion

Assessing OWASP Juice Shop as a structured penetration-testing engagement was more valuable than approaching it only as a collection of vulnerability challenges.

The exercise helped reinforce an end-to-end workflow:

Define Scope
      ↓
Understand the Application
      ↓
Map the Attack Surface
      ↓
Analyze HTTP Traffic
      ↓
Test Security Controls
      ↓
Validate Observations
      ↓
Collect Evidence
      ↓
Assess Impact
      ↓
Document Findings
      ↓
Recommend Remediation

The most important takeaway was that effective penetration testing is not simply about finding vulnerabilities.

It requires understanding how an application works, identifying where trust is placed, forming testable security hypotheses, validating behavior carefully, and communicating results with evidence.

Tools such as Burp Suite make testing more efficient, but methodology and analytical reasoning determine the quality of the assessment.

Practicing this process in controlled environments such as OWASP Juice Shop provides a strong foundation for conducting structured, authorized web application security assessments.

---

References

• OWASP Juice Shop
• OWASP Web Security Testing Guide (WSTG)
• OWASP Top 10
• OWASP API Security Top 10
• PortSwigger Web Security Academy
• Burp Suite Documentation