Skip to content
Penetration Testing Guide

OWASP for Penetration Testers

Forget compliance checklists. This is how you actually exploit vulnerabilities, think like an attacker, and map real-world flaws to the standards that matter.

Offensive Focus

  • •Manual exploitation flows
  • •WAF evasion techniques
  • •Logic & IDOR chaining
  • •Cloud metadata pivoting

Business Value

  • •Translate risk to executives
  • •CVSS v4.0 scoring
  • •MITRE ATT&CK mapping
  • •Actionable remediation

The OWASP Way

Why OWASP matters and how to use it as a pentester.

Compliance Checks vs. Real Pentesting

Compliance frameworks tell you what security controls must exist. PCI-DSS, ISO 27001—these are about ticking boxes and proving due diligence. OWASP is different. It teaches you how to find real vulnerabilities and exploit them. As a pentester, OWASP is your guide to thinking like an attacker and demonstrating actual impact, not just running a checklist.

The Four Pillars of OWASP

  • ASVS: Your blueprint for secure architecture. Use it to understand what a properly built app should look like.
  • WSTG: Your exploitation playbook. This is how you actually break applications step-by-step.
  • Top 10: The vulnerabilities that actually matter in the real world. Focus your testing here first.
  • Cheat Sheets: Quick reference for fixes and mitigations when you find flaws.
Prerequisites

Chapter 0:
Building Your Testing Lab

You can't learn pentesting on production systems. You need a safe sandbox where you can break things, learn from failures, and experiment without legal consequences. Here's how to build it.

0.1 Why You Need a Local Lab

Hacking production systems without permission is a felony. So you build your own broken apps locally—intentionally vulnerable systems you control. This is where you practice, make mistakes, and learn without legal or business consequences.

Why Use Docker for Your Lab?

Docker lets you spin up broken apps in seconds, reset them instantly, and run multiple targets side-by-side. This beats virtual machines for learning:

  • Isolation: The app breaks in its own sandbox, not your system.
  • Reset in seconds: Blow up the app, restart it fresh, and try again. No cleanup needed.
  • Run multiple apps: Have Juice Shop on 3000, DVWA on 8080, and WebGoat on 8081 all at once.

0.2 Your Pentesting Setup

Lab Topology
graph LR A[Kali Linux OS] --> B(Burp Suite Proxy) B -->|HTTP/HTTPS| C(Docker Daemon) C --> D[OWASP Juice Shop] C --> E[WebGoat] C --> F[bWAPP] class A danger; class B safe; class C warning; class D,E,F card;

0.3 Your Essential Toolkit

The right tools make the difference between spinning your wheels and finding real vulnerabilities. Here's what every tester needs.

  1. 1
    Burp Suite or OWASP ZAP Intercept requests, modify parameters on the fly, and see exactly what the app does. This is your main weapon.
  2. 2
    FoxyProxy (Browser Plugin) Switch your browser's proxy on and off with one click instead of diving into settings every time.
  3. 3
    SecLists Huge collections of payloads, passwords, and wordlists for fuzzing. This saves hours of manual work.

Target Apps to Practice On

  • OWASP Juice Shop A modern app with real vulnerabilities. Built with Node.js and Angular like production apps.
  • DVWA Classic and simple. Perfect for learning the basics with PHP and MySQL.
  • WebGoat OWASP's interactive Java app for learning and practicing exploitation.

0.4 Get These Apps Running

OWASP Juice Shop Docker Deployment

Terminal
Bash 
docker run --rm -p 3000:3000 bkimminich/juice-shop

Access It

Once it's running, go to http://localhost:3000 in your browser.

DVWA (PHP/MySQL)

Terminal
Bash 
docker run --rm -it -p 8080:80 vulnerables/web-dvwa

Visit http://localhost:8080. Login: admin/password. Hit "Create/Reset Database" on the setup page.

bWAPP (Interactive Labs)

Terminal
Bash 
docker run -d -p 8081:80 hackersploit/bwapp-docker

First time: go to http://localhost:8081/install.php to setup. Then login at http://localhost:8081/login.php with bee/bug.

Enable HTTPS Interception

Why Your Certs Fail

If you try to intercept HTTPS without installing Burp's certificate, your browser blocks it with a security error. You need to tell your browser to trust Burp.
  • How to Set It Up
    1. Open Burp and enable Proxy Intercept.
    2. In your proxy-configured browser, go to http://burp.
    3. Click "CA Certificate" to download the cert file.
    4. Import it into your browser's trusted certificates.
OWASP Top 10 - A01:2025

Chapter 1:
Broken Access Control

The app verified you're logged in, but does it actually check that you own the data you're accessing? That's where access control fails. We show you how to find and exploit it.

1.1 Where It Goes Wrong

The server checks if you're logged in, but then it blindly trusts whatever ID you ask for. You say "show me user 456's data" and the app returns it without checking if you actually own user 456. That's broken access control—and it's almost always an architecture problem, not a simple bug.

Deep Dive: The 'Trust' Fallacy

In a properly secured application, the processing flow must involve: Authentication (Who are you?), Authorization (Can you do this?), and Object-Level Validation (Can you do this to this specific object?). BAC occurs when step 3 is missing. For example, an API endpoint accepts an object ID and performs an action, but the server-side code neglects to check if the authenticated user actually owns that object.

  • Over-reliance on Client-Side State: Hiding admin buttons in React, but leaving the /api/admin/deleteUser endpoint unprotected.
  • Predictable Identifiers: Using sequential IDs (id=1) makes enumeration trivial.
  • Blind Trust in Input: Treating user-supplied parameters (like "isAdmin": true in a JSON body) as benign.

1.2 Request Lifecycle & IDOR Exploitation

IDOR Attack Flow Architecture
sequenceDiagram actor Attacker (User A) participant WebApp as Web Application participant Database Attacker->>WebApp: GET /api/profile?id=A_123 (Legitimate) WebApp->>Database: SELECT * FROM users WHERE id=A_123 Database-->>WebApp: Returns Data A WebApp-->>Attacker: 200 OK (Data A) Note over Attacker,Database: The IDOR Attack Phase Attacker->>WebApp: GET /api/profile?id=B_456 (Malicious) Note over WebApp: MISSING CHECK: Does User A own B_456? WebApp->>Database: SELECT * FROM users WHERE id=B_456 Database-->>WebApp: Returns Data B WebApp-->>Attacker: 200 OK (Data B Leaked)

1.3 How to Find It

Scanners miss this stuff because it's logic-based. Your job: assume the app is lying to you. Test everything with multiple users and see what you can access.

  1. 1
    Recon & Mapping Explore the app as unauthenticated, low-privilege, and admin. Identify all IDs (numeric, UUIDs, strings in JWTs).
  2. 2
    Dual-Session Setup Establish two distinct sessions (User A and User B) in Burp Suite to easily swap contexts.
  3. 3
    Systematic Tampering Capture User A's request, swap the ID parameter to User B's ID, and observe the backend response.

Critical Vectors

  • Horizontal IDOR Accessing a peer's data.
  • Vertical Escalation Hitting admin endpoints.
  • Mass Assignment Injecting unauthorized JSON fields.

1.4 Testing & Reporting

Real-World Request Modification

/api/v1/users/profile
Original Request 
PUT /api/v1/users/profile HTTP/1.1
Host: api.target.com
Authorization: Bearer eyJhbGciOi...[User A Token]
Content-Type: application/json

{"{"}"email": "userA@test.com", "name": "User A"{"}"}

Attack Scenario (BOPLA)

Injecting privileged properties assuming the backend doesn't sanitize the JSON bind. By adding "isAdmin": true, we test if the server implicitly trusts the client object.
/api/v1/users/profile
Malicious Payload 
PUT /api/v1/users/profile HTTP/1.1
Host: api.target.com
Authorization: Bearer eyJhbGciOi...[User A Token]
Content-Type: application/json

{"{"}"email": "userA@test.com", "name": "User A", "isAdmin": true, "role": 1{"}"}

Pentester Detection Methodology

  • Burp Suite Autorize: The most critical tool. Supply a low-privileged token, and Autorize automatically replays all captured high-privileged requests to test for authorization failures.
  • Burp Repeater: Manual, iterative modification of IDs. Crucial for analyzing complex error messages.
  • Param Miner: Discovers hidden or unlinked parameters that might control authorization state.

WAF & Filter Bypass Techniques

WAFs cannot generally stop IDOR because they lack application context (they don't know who owns ID 456). However, parameter pollution can bypass simple checks.

HTTP Parameter Pollution (HPP)

If the WAF checks the first parameter (MY_ID) but the backend Node/Express server processes the last parameter (VICTIM_ID), the attack succeeds.
/api/get_receipt
HPP Payload 
GET /api/get_receipt?user_id=MY_ID&user_id=VICTIM_ID

Developer Remediation

Common Developer Mistake

Assuming that using a UUID instead of a sequential integer ID prevents Broken Access Control. A UUID only prevents enumeration. If an attacker discovers a UUID (e.g., via a leaked link or another API), the authorization check is still missing.
  • Centralized Server-Side Enforcement All access decisions must occur on the server. Implement robust ABAC/RBAC mechanisms in a unified middleware layer.
  • Ownership Verification: For every request using an object ID, query the database ensuring the owner_id matches the session.
  • Avoid Implicit Binding: Do not automatically map JSON request body properties to internal database models to prevent Mass Assignment. Explicitly whitelist allowed properties.
OWASP Top 10 - A03:2025

Chapter 2:
Injection & Code Execution

The app treats your input as data, but the database treats it as a command. Slip some SQL into a form field and suddenly you're running code on the server. That's injection.

2.1 Why It Happens

The developer builds a database query by mashing your input straight into SQL code. Instead of treating your input as safe data, the query becomes something like: SELECT * FROM users WHERE username = 'yourInput'. If you inject SQL into yourInput, the database runs your code. It's the most fundamental security mistake.

Deep Dive: Interpreter Processing

The interpreter cannot distinguish between the legitimate command logic written by the developer and the malicious input injected by the attacker. Because it's all processed as a single string, the entire statement is executed.

  • Database (SQL/NoSQL): Leads to data exfiltration or modification.
  • Operating System Shell: Leads to Remote Code Execution (RCE) via command injection.
  • Template Engine (SSTI): Leads to server-side code execution if the template evaluates untrusted syntax.

2.2 The SQLi Data Exfiltration Chain

SQL Injection Execution Path
flowchart LR A[Attacker]:::danger -->|Injects Payload| B(Web Form / API) B -->|String Concatenation| C[(Database Server)]:::safe C -->|Syntax Error| D[Application Error] C -->|Union Select| E[Exfiltrate Data]:::safe C -->|Sleep Command| F[Time Delay]:::warning E --> A F -.->|Observes Delay| A

2.3 Finding Injection Flaws

Your scanner will find obvious SQLi in 5 minutes. The hard part is finding blind injection, time-based attacks, and bypassing filters. Here's the manual approach.

  1. 1
    Input Mapping Identify every single input vector (URL params, JSON fields, custom headers like X-Forwarded-For).
  2. 2
    Syntax Breaking Send single quotes ', double quotes ", or template syntax {{7*7}} to induce backend errors.
  3. 3
    Blind Identification If errors are hidden, use boolean logic (AND 1=1) or time delays (pg_sleep(10)).

Critical Injection Types

  • Time-Based Blind Measuring response time to extract data bit by bit.
  • Out-Of-Band (OOB) Forcing a DNS request to an attacker server.
  • SSTI Injecting Jinja2/Twig syntax to execute code.

2.4 Exploiting & Fixing

Real-World Payloads

Time-Based Blind SQLi (PostgreSQL)
Payload 
1' AND (SELECT 1 FROM (SELECT(sleep(10)))a)--

Server-Side Template Injection

SSTI in Jinja2 allows attackers to escape the template sandbox. We use Python's built-in __globals__ to access the `os` module and execute arbitrary system commands, bypassing the web application entirely.
SSTI (Jinja2) resulting in Remote Code Execution
Payload 
{"{"}{"{"} self._TemplateReference__context.joiner.__init__.__globals__.os.popen('id').read() {"}"}{"}"}
Command Injection (Bypassing Space Filters)
Payload 
127.0.0.1;cat$IFS/etc/passwd

Pentester Detection Methodology

  • Burp Intruder: Fuzzing parameters with specialized wordlists (e.g., SecLists) designed to trigger specific database errors or time delays.
  • sqlmap: Highly automated database takeover tool. Pentesters use it after manually confirming an injection point to speed up exfiltration.
  • Burp Collaborator: Essential for Out-of-Band (OOB) injections. Generates unique domain names to detect if a backend system executes a DNS lookup payload.

WAF Bypass & Filter Evasion

WAFs rely on signature matching. Pentesters evade them by altering the payload signature while maintaining its executable logic.

Evasion Strategy

Never rely on a single payload. If a WAF blocks `SELECT`, try `S%45LECT` or `SEL/**/ECT`. The database parser will often reconstruct the obfuscated string before execution.
  • Encoding: Using URL encoding, Hex encoding, or Unicode variations to hide keywords.
  • Obfuscation: Inserting SQL comments inside keywords (e.g., SEL/**/ECT) to break WAF regex.
  • sqlmap --tamper: Utilizing built-in tamper scripts (e.g., space2comment.py) to automatically encode payloads on the fly.

Developer Remediation

  • Parameterized Queries (Prepared Statements) The absolute best defense against SQLi. It forces the database to treat input strictly as data, never as executable code, regardless of the characters it contains.
  • Strict Allow-listing: Validate all input against a strict whitelist of allowed characters or formats.
  • Avoid Shell Execution: Never use exec() or system() functions with user-supplied data. Use built-in language APIs instead.
OWASP API Top 10 & Cloud Pivot

Chapter 3:
APIs & Cloud

Modern apps are APIs, and they run in the cloud. No fancy UI to hide broken logic. Everything's exposed, and cloud metadata servers become your pivot point.

3.1 Why APIs Are Dangerous

APIs expose business logic directly. No UI to hide broken access controls or validate inputs. And cloud servers have metadata APIs that leak credentials—if you can make the web app request them, you own everything.

SSRF to Cloud Takeover

SSRF is when you trick the app into making requests to URLs you control. In AWS/GCP/Azure, there's a magic IP (169.254.169.254) that serves instance credentials. If the app has an "image fetch" feature and you inject that IP as the URL, the app will return the server's IAM credentials. Game over—you own the infrastructure.

3.2 The SSRF to Cloud Pivot Chain

AWS IAM Extraction via SSRF
sequenceDiagram actor Attacker participant App as Web Application (AWS EC2) participant Metadata as AWS IMDS (169.254.169.254) Attacker->>App: POST /fetch_image (url=http://169.254.169.254/.../s3-admin-role) Note over App: App fails to validate internal IP App->>Metadata: GET /latest/meta-data/iam/security-credentials/s3-admin-role Metadata-->>App: Returns JSON with AccessKeyId, SecretAccessKey, Token App-->>Attacker: Displays JSON as "Image Data" Note over Attacker: Attacker configures local AWS CLI with stolen creds

3.3 How to Break APIs

API testing is methodical. Find all endpoints, fuzz every parameter, and chain operations to break business logic.

  1. 1
    Schema Extraction Attempt to find Swagger docs, OpenAPI specs, or use GraphQL Introspection (__schema) to map all endpoints.
  2. 2
    Parameter Fuzzing Look for parameters like url=, path=, or webhook= that might trigger outbound requests (SSRF).
  3. 3
    Logic Manipulation Attempt to call multi-step processes out of order, or batch hundreds of GraphQL queries in a single request to test rate limits.

Critical API Vectors

  • BOLA (API1:2023) The API equivalent of IDOR. Manipulating object IDs in REST paths.
  • Unrestricted Resource Sending deeply nested GraphQL queries to exhaust server memory (DoS).
  • SSRF (API7:2023) Forcing the server to make requests to internal networks.

3.4 Practical Application

Real-World Payloads

/graphql
Recon Payload 
{"{"} __schema {"{"} types {"{"} name fields {"{"} name {"}"} {"}"} {"}"} {"}"}

AWS IMDS Extraction

Using SSRF to hit AWS IMDSv1 to extract highly privileged IAM roles from the EC2 instance. This immediately escalates a web vulnerability into full Cloud Account Compromise.
?url=
Malicious Payload 
http://169.254.169.254/latest/meta-data/iam/security-credentials/
?url=
Malicious Payload 
dict://127.0.0.1:6379/info

Pentester Detection Methodology

  • Postman & Burp API Client: Directly interacting with REST endpoints based on discovered documentation.
  • InQL (Burp Extension): Essential for GraphQL security testing. Automatically issues introspection queries and generates all possible queries/mutations for testing.
  • Burp Collaborator: Used to confirm blind SSRF. Inject a Collaborator URL into an input; if a DNS/HTTP request is received by the Collaborator server, the SSRF is confirmed.

SSRF Filter Evasion

Developers often implement blacklists to block 169.254.169.254 or 127.0.0.1. Pentesters use alternative representations.

DNS Rebinding

Setting up a custom domain that initially resolves to a safe IP (passing the WAF check), but its TTL is 0. By the time the backend logic actually makes the HTTP request, the DNS lookup resolves to an internal IP like `127.0.0.1`.
  • Decimal Encoding: http://2852039166 (resolves to 169.254.169.254).
  • Octal Encoding: http://0251.0376.0251.0376.

Developer Remediation

  • SSRF Fix & IMDSv2 Implement a strict URL whitelist. Do not use blacklists. If fetching external resources is required, resolve the DNS name and verify the target IP is not within an internal subnet before establishing the connection. For AWS, enforce IMDSv2 (requires session tokens) and disable IMDSv1.
  • GraphQL Fix Disable Introspection in production. Implement strict query depth and complexity limits to prevent Denial of Service via recursive queries.
Methodology & Workflow

Chapter 4:
Running a Real Pentest

From reconnaissance to reporting. How professionals structure a penetration test and translate technical findings into business language.

4.1 The Engagement Cycle

PTES Standard Execution Flow
flowchart LR A[Reconnaissance & Enumeration]:::card -->|Map Attack Surface| B(Threat Modeling & Vuln Analysis):::card B -->|Identify Weaknesses| C([Active Exploitation]):::danger C -->|Gain Foothold| D[Post-Exploitation & Pivoting]:::danger D -->|Assess Impact| E[Reporting & Translation]:::safe

Phase 1: Mapping the Target

Before you attack, you need to understand what exists. Every endpoint, parameter, and API.

  • Passive Intelligence

    Google for subdomains, use theHarvester and Shodan. Check HTTP headers to see what tech stack they're running.

  • Brute-Force Endpoints

    Use wordlists to find hidden admin panels, `.git` directories, or exposed config files.

    Terminal
    Bash 
    ffuf -w wordlist.txt -u https://target.com/FUZZ -mc 200,401,403
  • Map Everything

    Use Burp to proxy all traffic. Write down every input, every API endpoint, every form field. Know the app before you attack it.

Phase 2: Exploitation & Impact

Find the flaws, exploit them, and explain to management why it matters.

The Real Skill

Finding SQLi is easy. Explaining to the CEO why it costs the company $2M in data loss—that's what they're paying for. Good pentesters speak business language.
  • Attack Manually

    Burp Repeater is your best friend. Tweak parameters, test logic flaws, find blind injections. Automation finds obvious stuff; you find the gold.

  • Pivot & Expand

    RCE? Go deeper. SSRF? Grab AWS credentials. Find databases, internal services, and bigger targets.

  • Report It Right

    A great find goes nowhere if your report is technical gibberish. Executives need to understand impact and cost.

    • What: OWASP classification.
    • Severity: CVSS score.
    • Impact: What's the business cost? Data loss? Downtime? Breach liability?
Sponsored Links

Subscribe to my newsletter

Receive my case study and the latest articles on my WhatsApp Channel.

Warning