🛡️ Cybersecurity Home Lab
Vulnerability Assessment • Web Security • Docker • NGINX • Security Hardening
A hands-on defensive cybersecurity project documenting the process of building an isolated lab, discovering an application’s attack surface, analyzing security weaknesses, implementing compensating controls, troubleshooting their impact, and verifying remediation.
Project workflow: Discovery → Enumeration → Vulnerability Analysis → Risk Assessment → Remediation → Verification → Documentation
🎯 Project Objective
The goal of this project is to develop practical cybersecurity skills through repeatable, evidence-based security testing against systems I own and control.
The lab uses OWASP Juice Shop as an intentionally vulnerable target and Docker to provide an isolated environment. Later phases introduce an NGINX reverse proxy as a defensive security layer.
All testing documented here is performed locally for educational and authorized security training.
🏗️ Lab Architecture
Windows Host
|
+-----------+-----------+
| |
PowerShell / Browser Docker Desktop
|
Isolated Lab Network
|
+--------------+--------------+
| |
Security Tooling OWASP Juice Shop
Nmap / cURL Target :3000
|
NGINX Reverse Proxy
Hardened :8080
The original application is tested on port 3000. During the remediation phase, traffic is routed through NGINX on port 8080, where additional defensive HTTP controls are applied.
🔬 Project Phases
Phase Focus Key Work Status 1 Lab Deployment Docker environment, Juice Shop target, isolated networking ✅ Complete 2 Network Reconnaissance Nmap scanning, service detection, HTTP validation ✅ Complete 3 Web Enumeration WhatWeb, Nikto, Gobuster, endpoint discovery ✅ Complete 4 Vulnerability Analysis Finding validation, risk analysis, OWASP mapping ✅ Complete 5 Remediation & Hardening NGINX reverse proxy, CSP and security headers, validation ✅ Complete 6 Security Verification Before/after validation and remediation verification 🚧 In Progress
🔎 Phase 2 — Network Reconnaissance
Network reconnaissance was performed against the Juice Shop container using Nmap and cURL.
nmap -sV -p 3000 172.19.0.2
The assessment confirmed that the target was reachable and that TCP port 3000 exposed the web application.
HTTP inspection was then used to validate the service rather than relying only on automated scanner identification.
Skills demonstrated: Nmap • TCP/IP • Service Enumeration • HTTP Analysis • Evidence Collection
🌐 Phase 3 — Web Application Enumeration
The application was enumerated using multiple tools to identify technologies, exposed paths, HTTP behavior, and potential attack-surface information.
Tools Used
- WhatWeb
- Nikto
- Gobuster
- DIRB wordlists
- cURL
Interesting paths discovered during the authorized assessment included:
- /ftp
- /promotion
- /robots.txt
- /video
- /assets
- /media
This phase demonstrated why reconnaissance results from different tools should be correlated and manually interpreted.
Enumeration results were moved into a structured vulnerability-management workflow.
A validated finding documented application configuration information exposure through an administrative configuration endpoint.
The issue was assessed for security impact and mapped to:
OWASP A05:2021 — Security Misconfiguration
The analysis included:
- Finding description
- Technical evidence
- Security impact
- Severity assessment
- OWASP mapping
- Remediation recommendations
- Validation scope
📄 Read the Phase 4 Vulnerability Analysis
🔐 Phase 5 — Remediation & Security Hardening
Phase 5 moved from identifying weaknesses to implementing defensive controls.
Rather than modifying the Juice Shop source code, I deployed an NGINX reverse proxy in front of the application.
Browser → NGINX :8080 → OWASP Juice Shop :3000
Security Controls Implemented
- Content-Security-Policy
- Referrer-Policy
- Permissions-Policy
- X-Content-Type-Options: nosniff
- X-Frame-Options: SAMEORIGIN
The initial Content Security Policy was restrictive enough to affect the application’s interface.
I reviewed the policy, adjusted it to support required application resources, reloaded NGINX, and retested the application.
This demonstrated an important security-engineering principle:
A security control must reduce risk while preserving required business and application functionality.
📄 Read the Complete Phase 5 Remediation & Hardening Lab
📸 Phase 5 Evidence
Hardened Application
OWASP Juice Shop functioning through the NGINX reverse proxy on port 8080 after CSP troubleshooting.
Security Header Verification
PowerShell and cURL verification showing the hardened endpoint returning HTTP 200 and the additional security headers.
📊 Before vs. After
Security Control Baseline :3000 Hardened :8080 X-Content-Type-Options ✅ Present ✅ Present X-Frame-Options ✅ Present ✅ Present Content-Security-Policy ❌ Not identified ✅ Added Referrer-Policy ❌ Not identified ✅ Added Permissions-Policy ❌ Not identified ✅ Added Application Functional ✅ ✅ After CSP adjustment
The result demonstrates a complete defensive workflow rather than simply running vulnerability scanners:
Identify → Analyze → Remediate → Troubleshoot → Verify
🛠️ Tools & Technologies
Area Technologies Containerization Docker Desktop, Docker Networking Target Application OWASP Juice Shop Reconnaissance Nmap, WhatWeb, Nikto, Gobuster HTTP Analysis cURL, PowerShell Defensive Control NGINX Reverse Proxy Systems Windows, Ubuntu/Linux Documentation Git, GitHub, Markdown
🧠 Skills Demonstrated
- Vulnerability assessment and management
- Network reconnaissance and service enumeration
- Web application security assessment
- HTTP security-header analysis
- OWASP Top 10 mapping
- Risk assessment and remediation planning
- NGINX reverse-proxy configuration
- Content Security Policy implementation
- Security-control troubleshooting
- Remediation verification
- Docker container management
- Linux and PowerShell command-line work
- Technical documentation and evidence management
📁 Repository Structure
home-lab/ ├── docs/ # Vulnerability analysis and remediation reports ├── evidence/ # Raw command and scanner output ├── screenshots/ # Visual evidence from lab phases ├── nginx/ # Reverse-proxy hardening configuration └── README.md # Project case study
This structure separates raw evidence from analysis and final documentation, making the project easier to review as a cybersecurity portfolio case study.
🚧 Next Phase
Phase 6 — Security Verification
The next phase will formally compare the baseline and hardened environments, verify that the implemented controls remain active, validate application functionality, and document the final remediation outcome with repeatable evidence.
⚖️ Ethical Use
All security testing in this repository is performed against an intentionally vulnerable application deployed inside a controlled local lab environment.
No external or production systems are tested.
Security-testing techniques should only be used against systems you own or have explicit authorization to assess.
👤 Author
Cosmos Akpan Cybersecurity Student • Blue Team • SOC • Network Security
This repository is part of my hands-on cybersecurity portfolio and documents my progression from security discovery through defensive remediation and verification.