← blog

// OWASP Top 10 in Practice: A Pentester's Field Guide

────────────────────────────────────────────────────

OWASP Top 10 in Practice: A Pentester’s Field Guide

The OWASP Top 10 is referenced everywhere in cybersecurity, but most guides treat it as a compliance checkbox rather than a practical hunting guide. This post breaks down how I actually test for each category during real engagements at Cyber Silo and on bug bounty programs.


A01 — Broken Access Control

This is consistently the #1 finding in my assessments. The core question: can a user access resources they shouldn’t?

Testing approach

# Start with role enumeration
# Log in as a low-privilege user, note all endpoint IDs
# Then replay requests with admin session — or no session at all

# Horizontal privilege escalation example:
GET /api/users/1337/profile  # as user 1338
# Should 403 — often doesn't

Key tests I always run:

  • IDOR — change numeric/UUID identifiers in API calls
  • Forced browsing — access /admin, /dashboard, /api/v1/internal/* without authentication
  • HTTP method switching — if DELETE /resource is blocked, try GET /resource/delete
  • Missing function-level access control — admin features exposed to regular users

Real-world finding

On a grey-box engagement, I found that changing the user_id parameter in the JWT payload (which was signed with HS256 using the literal string "secret") gave me full admin access. The app trusted the token content without verifying the signature properly.


A02 — Cryptographic Failures

Previously “Sensitive Data Exposure.” I look for data that’s transmitted or stored insecurely.

What I test

# Check for weak cipher suites
nmap --script ssl-enum-ciphers -p 443 target.com

# Look for HTTP (not HTTPS) endpoints
# Check cookies: Secure flag, SameSite attribute
# Test for JWT algorithm confusion (RS256 → HS256)

Common finds:

  • Passwords hashed with MD5 or SHA1 (no salt)
  • API keys visible in JavaScript source
  • Sensitive data in URL query strings (logged by servers/proxies)
  • Weak TLS configurations (TLS 1.0/1.1 still enabled)

A03 — Injection

SQL injection is less common now but far from dead. I’ve found SQLi in production apps as recently as 2024.

My SQLi testing checklist

# Automated scan first
sqlmap -u "https://target.com/api/search?q=test" \
  --cookie="session=abc123" \
  --level=5 --risk=3 \
  --batch --dbs

# Manual tests for blind SQLi
' OR '1'='1
' OR SLEEP(5)--
' UNION SELECT NULL,NULL,NULL--

Don’t forget NoSQL injection for MongoDB-backed APIs:

{"username": {"$gt": ""}, "password": {"$gt": ""}}

And SSTI (Server-Side Template Injection):

{{7*7}}
${7*7}
<%= 7*7 %>

A05 — Security Misconfiguration

This is where most of my bug bounty findings come from. Misconfigurations are everywhere.

Quick wins I look for

# Default credentials
admin:admin, admin:password, root:root

# Exposed admin panels
/admin, /administrator, /wp-admin, /phpmyadmin, /console

# Directory listing
curl -I https://target.com/uploads/

# Debug endpoints
/actuator (Spring Boot)
/.env
/config.php.bak
/web.config

CORS misconfiguration

curl -H "Origin: https://evil.com" \
     -H "Access-Control-Request-Method: GET" \
     -I https://api.target.com/user/me
# Look for: Access-Control-Allow-Origin: https://evil.com
# with: Access-Control-Allow-Credentials: true

This combination allows an attacker to read sensitive API responses from a victim’s browser.


A07 — Identification and Authentication Failures

Session management tests

  • Session token entropy (should be cryptographically random, ≥128 bits)
  • Session fixation: can you set your own session ID before login?
  • Logout: does the server invalidate the session server-side?
  • Password reset: is the token single-use? Does it expire?
# Brute force protection test
hydra -l admin@target.com -P /usr/share/wordlists/rockyou.txt \
  https-post-form target.com:/login:email=^USER^&password=^PASS^:Invalid

# After ~10 attempts — are you locked out? Rate limited?

Tools Summary

VulnerabilityPrimary ToolSecondary
SQLiSQLmap, BurpManual, Caido
XSSBurp ScannerManual polyglots
AuthHydra, BurpManual
SSRFBurp Collaboratorinteractsh
ReconAmass, NmapCaido

Closing Thoughts

The OWASP Top 10 is a starting point, not a complete methodology. In real engagements, I combine automated scanning (Burp Suite Pro, Nessus) with deep manual testing — because automated tools miss business logic flaws, chained vulnerabilities, and anything that requires understanding the application’s intent.

If you want to discuss a specific engagement or collaborate on a bug bounty target, reach out via email or HackerOne.

────────────────────────────────────────────────────