Web Application Security Audit

Overview

A structured penetration testing methodology based on The Web Application Hacker's Handbook. Guides you through 10 sequential phases to systematically identify vulnerabilities in any web application you're building or reviewing.

When to Use

• Before deploying a web application to production
• When adding authentication, payment processing, or user-facing features
• During periodic security reviews
• After integrating third-party services or APIs
• When you suspect a specific vulnerability class but want comprehensive coverage

When NOT to Use

• Against applications you don't own or have authorization to test
• As a replacement for professional penetration testing on critical systems
• For network-level security (this is application-layer focused)

Process

Work through each phase sequentially. At each phase:

1. Ask targeted questions about the specific application
2. Read the relevant chapter summary from

   cybersecurity/web-application-hackers-handbook/

   for detailed guidance
3. Suggest and execute concrete tests (grep patterns in source code, curl commands, Burp Suite steps, automated scripts)
4. Flag findings with severity:

   CRITICAL

   /

   HIGH

   /

   MEDIUM

   /

   LOW

   /

   INFO

5. Summarize findings before moving to the next phase

If the application doesn't have a relevant surface for a phase (e.g., no file uploads), acknowledge and skip with rationale.

digraph audit_phases {
  rankdir=TB;
  node [shape=box, style=rounded];

  p1 [label="Phase 1\nMap the Application"];
  p2 [label="Phase 2\nAnalyze the Application"];
  p3 [label="Phase 3\nClient-Side Controls"];
  p4 [label="Phase 4\nAuthentication"];
  p5 [label="Phase 5\nSession Management"];
  p6 [label="Phase 6\nAccess Controls"];
  p7 [label="Phase 7\nInjection Vulnerabilities"];
  p8 [label="Phase 8\nApplication Logic"];
  p9 [label="Phase 9\nApplication Server"];
  p10 [label="Phase 10\nReview & Report"];
  report [label="Security Audit\nReport", shape=note];

  p1 -> p2 -> p3 -> p4 -> p5 -> p6 -> p7 -> p8 -> p9 -> p10 -> report;
}

---

Phase 1: Map the Application

Reference:

cybersecurity/web-application-hackers-handbook/ch04-mapping-the-application.md

Goal: Discover the full attack surface before testing anything.

Questions to ask:

• What is the application's tech stack? (framework, language, database, hosting)
• What are all the routes/endpoints? (read route files, API definitions, OpenAPI specs)
• Are there admin panels, API docs, or debug endpoints?
• What third-party services are integrated?

Tests to run:

• Enumerate all routes from source code:

  # Express.js
  grep -rn "app\.\(get\|post\|put\|delete\|patch\)" --include="*.ts" --include="*.js"
  # Django
  grep -rn "path\|url(" --include="*.py" urls.py
  # Rails
  grep -rn "get\|post\|put\|delete\|patch\|resources\|resource" config/routes.rb
  # Next.js — check app/ and pages/ directory structure
  

• Check for exposed files:

  robots.txt

  ,

  sitemap.xml

  ,

  .env

  ,

  .git/

  ,

  package.json

• Search for hardcoded secrets in source:

  grep -rni "password\|secret\|api_key\|token\|private_key" --include="*.ts" --include="*.js" --include="*.py" --include="*.env*"
  

• Review HTML/JS comments for sensitive information
• Identify all input vectors: URL params, POST bodies, cookies, headers, file uploads, WebSockets

Deliverable: Complete attack surface map — routes, parameters, technologies, entry points.

---

Phase 2: Analyze the Application

Reference:

cybersecurity/web-application-hackers-handbook/ch03-web-application-technologies.md

Goal: Understand what the application does and identify high-risk areas.

Questions to ask:

• What are the core business functions? (user management, payments, data CRUD, search, file handling)
• Which functions handle sensitive data? (PII, financial, credentials)
• Are there multi-step processes? (checkout, registration, approval workflows)
• What user roles exist? What can each role do?

Prioritize testing areas (highest risk first):

1. Authentication and credential handling
2. Payment/financial transaction processing
3. File upload functionality
4. Administrative interfaces
5. API endpoints (often have weaker controls than web UI)
6. Search functionality (frequent injection target)
7. User-to-user features (stored XSS vector)
8. Data export/import (injection, XXE)

Deliverable: Functional map with risk-prioritized areas of interest.

---

Phase 3: Test Client-Side Controls

Reference:

cybersecurity/web-application-hackers-handbook/ch05-bypassing-client-side-controls.md

Goal: Verify the server never trusts client-side validation or state.

Questions to ask:

• Are there hidden form fields the server relies on? (prices, roles, user IDs)
• Is input validation only done client-side? (JavaScript, HTML5 attributes)
• Does the client transmit data that should be server-side state? (cart totals, discount flags, permission levels)

Tests to run:

• Search for hidden fields:

  grep -rn 'type="hidden"\|type=.hidden.' --include="*.html" --include="*.tsx" --include="*.jsx"
  

• Search for client-only validation:

  grep -rn "maxlength\|pattern=\|required\b" --include="*.html" --include="*.tsx" --include="*.jsx"
  

• Check if server-side validation mirrors client-side:

  grep -rn "validate\|sanitize\|zod\|yup\|joi\|class-validator" --include="*.ts" --include="*.js" --include="*.py"
  

• For each form, submit requests with: missing required fields, values exceeding maxlength, values violating patterns, modified hidden fields
• Test price/role/permission manipulation by modifying request bodies

Finding template:

[SEVERITY] Client-Side Control Bypass: [description]
  Affected: [endpoint/parameter]
  Test: [what you did]
  Result: [what happened]
  Impact: [what an attacker could achieve]
  Fix: [server-side validation recommendation]

---

Phase 4: Test Authentication

Reference:

cybersecurity/web-application-hackers-handbook/ch06-attacking-authentication.md

Goal: Verify authentication cannot be bypassed, brute-forced, or abused.

Tests to run:

Username enumeration:

• Compare responses for valid vs invalid usernames on login, registration, and password reset
• Check response body, status codes, timing differences, and response length
• Search for inconsistent error messages:

  grep -rn "invalid.*username\|user.*not found\|no.*account\|incorrect.*password" --include="*.ts" --include="*.js" --include="*.py"
  

Brute-force resilience:

• Check for account lockout, rate limiting, CAPTCHA
• Search for rate limiting implementation:

  grep -rn "rate.limit\|throttle\|brute\|lockout\|max.*attempts" --include="*.ts" --include="*.js" --include="*.py"
  

Password policy:

• Test minimum length, complexity requirements, common password blocking
• Check password storage:

  grep -rn "bcrypt\|argon2\|scrypt\|pbkdf2\|sha256\|sha1\|md5\|plaintext" --include="*.ts" --include="*.js" --include="*.py"
  

• CRITICAL

  if passwords stored as plaintext, MD5, or SHA1 without salt

Password reset:

• Check token randomness, expiry, single-use enforcement
• Check if reset tokens are in URLs (logged in server logs, browser history)

Multi-factor authentication:

• Can MFA step be skipped by directly requesting authenticated endpoints?
• Can MFA be bypassed by replaying codes or using expired codes?

Remember me:

• Decode the remember-me token (Base64, JWT) — does it contain user info?
• Is it invalidated on password change?

---

Phase 5: Test Session Management

Reference:

cybersecurity/web-application-hackers-handbook/ch07-attacking-session-management.md

Goal: Verify sessions cannot be hijacked, fixated, or predicted.

Tests to run:

Token generation:

• Collect multiple session tokens and check for patterns (sequential, timestamp-based, low entropy)
• Decode tokens (Base64, JWT) — do they contain sensitive data?

  # For JWTs
  grep -rn "jwt\|jsonwebtoken\|jose" --include="*.ts" --include="*.js" --include="*.py"
  

Cookie flags:

• Check every cookie for:

  Secure

  ,

  HttpOnly

  ,

  SameSite

  ,

  Domain

  ,

  Path

  grep -rn "Set-Cookie\|cookie\|setCookie\|httpOnly\|secure\|sameSite" --include="*.ts" --include="*.js" --include="*.py"
  

• HIGH

  if session cookie missing

  HttpOnly

  (XSS can steal it)

• HIGH

  if session cookie missing

  Secure

  (transmitted over HTTP)

• MEDIUM

  if session cookie missing

  SameSite

  (CSRF vector)

Session lifecycle:

• Does the token change after login? (session fixation if not)
• Is the session invalidated server-side on logout? (not just cookie deletion)
• Is there idle timeout and absolute timeout?

CSRF protection:

• Identify all state-changing operations (POST/PUT/DELETE)
• Check for anti-CSRF tokens:

  grep -rn "csrf\|xsrf\|_token\|csrfmiddleware" --include="*.ts" --include="*.js" --include="*.py" --include="*.html"
  

• Can state-changing requests succeed without the CSRF token?

---

Phase 6: Test Access Controls

Reference:

cybersecurity/web-application-hackers-handbook/ch08-attacking-access-controls.md

Goal: Verify users cannot access unauthorized data or functionality.

Questions to ask:

• What user roles exist? (admin, user, moderator, API consumer)
• How is authorization enforced? (middleware, decorators, inline checks)
• Are there resource IDs in URLs or request bodies that could be manipulated?

Tests to run:

IDOR (Insecure Direct Object Reference):

• Find all endpoints with resource IDs:

  grep -rn "/users/\|/orders/\|/documents/\|/api/.*/:id\|/api/.*/<.*>" --include="*.ts" --include="*.js" --include="*.py"
  

• As User A, request User B's resources by changing IDs

• CRITICAL

  if successful

Vertical privilege escalation:

• As a regular user, request admin endpoints directly
• Check if authorization is enforced per-endpoint:

  grep -rn "isAdmin\|requireAdmin\|role.*admin\|authorize\|permission\|@Roles\|@RequiresRole" --include="*.ts" --include="*.js" --include="*.py"
  

• Check if any endpoints lack authorization middleware

Horizontal privilege escalation:

• Modify user-identifying parameters (

  user_id

  ,

  account_id

  ,

  email

  ) in requests
• Check if the server validates that the requested resource belongs to the authenticated user

Multi-step process controls:

• For multi-step flows (checkout, approval), test skipping to later steps directly
• Test performing steps out of order

---

Phase 7: Test for Injection Vulnerabilities

Reference:

cybersecurity/web-application-hackers-handbook/ch09-attacking-data-stores.md

,

ch10-attacking-back-end-components.md

,

ch12-attacking-users-xss.md

Goal: Verify all input is safely handled across every context.

SQL Injection:

# Find raw query construction (CRITICAL pattern)
grep -rn "query.*+\|execute.*+\|raw.*+\|\\.format.*SELECT\|f\".*SELECT\|f'.*SELECT" --include="*.ts" --include="*.js" --include="*.py"
# Verify parameterized queries are used
grep -rn "prepare\|parameterized\|\$[0-9]\|placeholder\|\?" --include="*.ts" --include="*.js" --include="*.py"

• CRITICAL

  if string concatenation/interpolation used in SQL queries

XSS (Cross-Site Scripting):

# Find dangerous DOM operations
grep -rn "innerHTML\|outerHTML\|document\.write\|\.html(\|dangerouslySetInnerHTML\|v-html\|\{!! " --include="*.ts" --include="*.js" --include="*.tsx" --include="*.jsx" --include="*.vue" --include="*.blade.php"
# Find eval usage
grep -rn "eval(\|Function(\|setTimeout.*string\|setInterval.*string" --include="*.ts" --include="*.js"

• HIGH

  for stored XSS,

  MEDIUM

  for reflected XSS,

  MEDIUM

  for DOM-based XSS

OS Command Injection:

grep -rn "exec(\|execSync\|spawn(\|system(\|popen\|subprocess\|child_process\|shell_exec\|passthru\|backtick" --include="*.ts" --include="*.js" --include="*.py" --include="*.php"

• CRITICAL

  if user input flows into command execution

Path Traversal:

grep -rn "readFile\|writeFile\|createReadStream\|open(\|path\.join.*req\|path\.resolve.*req\|fs\." --include="*.ts" --include="*.js" --include="*.py"

• Check if user input is used in file paths without sanitization

XXE (XML External Entity):

grep -rn "parseXML\|DOMParser\|SAXParser\|XMLReader\|etree\.parse\|xml2js\|libxml" --include="*.ts" --include="*.js" --include="*.py"

• Check if external entity processing is disabled

SSRF (Server-Side Request Forgery):

grep -rn "fetch(\|axios\|request(\|urllib\|http\.get\|https\.get\|curl\|wget" --include="*.ts" --include="*.js" --include="*.py"

• Check if user-supplied URLs are validated against an allowlist

• CRITICAL

  if user input flows directly into server-side HTTP requests without validation

Server-Side Template Injection (SSTI):

grep -rn "render_template_string\|Template(\|Jinja2\|nunjucks.*render\|handlebars.*compile\|ejs.*render" --include="*.ts" --include="*.js" --include="*.py"

• Check if user input is embedded in templates before rendering

---

Phase 8: Test Application Logic

Reference:

cybersecurity/web-application-hackers-handbook/ch11-attacking-application-logic.md

Goal: Identify flaws in business logic that automated scanners cannot find.

Questions to ask:

• What assumptions does each function make about user behavior?
• Are there multi-step processes? Can steps be skipped or reordered?
• Are there financial transactions? Can amounts be manipulated (negative values, zero, overflow)?
• Are there referral/reward/coupon systems? Can they be abused?

Tests to run:

Race conditions:

grep -rn "balance\|credits\|quantity\|stock\|inventory\|coupon\|redeem\|transfer\|withdraw" --include="*.ts" --include="*.js" --include="*.py"

• For any check-then-act pattern (check balance → deduct), test concurrent requests

• HIGH

  if double-spending or double-redemption is possible

Multi-step process abuse:

• Map every multi-step flow (checkout, registration, approval)
• Test: skip steps, repeat steps, go backward, change data between steps, switch user context between steps

Transaction logic:

• Test negative amounts, zero amounts, extremely large amounts
• Test fractional values where integers expected
• Test self-referral, circular referral chains

Input normalization conflicts:

• Test unicode normalization issues (different representations of same character)
• Test case sensitivity conflicts (register as "Admin" when "admin" exists)

---

Phase 9: Test Application Server

Reference:

cybersecurity/web-application-hackers-handbook/ch18-attacking-the-application-server.md

Goal: Verify the server platform itself is hardened.

Tests to run:

Default credentials:

• Check if admin panels exist at common paths:

  /admin

  ,

  /wp-admin

  ,

  /phpmyadmin

  ,

  /console

  ,

  /manager

• Test default credentials for any discovered admin interfaces

Dangerous HTTP methods:

curl -X OPTIONS <target-url> -i

• MEDIUM

  if PUT, DELETE, or TRACE are enabled unnecessarily

Security headers:

curl -s -I <target-url>

Check for:

• Content-Security-Policy

  —

  HIGH

  if missing (XSS mitigation)

• Strict-Transport-Security

  —

  HIGH

  if missing (HTTPS enforcement)

• X-Frame-Options

  or CSP

  frame-ancestors

  —

  MEDIUM

  if missing (clickjacking)

• X-Content-Type-Options: nosniff

  —

  LOW

  if missing (MIME sniffing)

• Referrer-Policy

  —

  LOW

  if missing (information leakage)

• Permissions-Policy

  —

  INFO

  if missing

• Server

  /

  X-Powered-By

  —

  INFO

  if present (version disclosure)

Debug mode:

grep -rn "DEBUG.*=.*True\|debug.*:.*true\|NODE_ENV.*development\|FLASK_DEBUG\|DJANGO_DEBUG" --include="*.py" --include="*.js" --include="*.ts" --include="*.env*" --include="*.yaml" --include="*.yml"

• HIGH

  if debug mode enabled in production config

Dependency vulnerabilities:

# Node.js
npm audit
# Python
pip-audit  # or safety check
# Ruby
bundle audit

Known CVEs:

• Check framework/library versions against known vulnerabilities

• CRITICAL

  for RCE CVEs,

  HIGH

  for auth bypass CVEs

---

Phase 10: Review & Report

Reference:

cybersecurity/web-application-hackers-handbook/ch15-exploiting-information-disclosure.md

,

ch21-web-application-hackers-methodology.md

Final checks:

Information disclosure:

grep -rn "console\.log\|print(\|logger\.\(debug\|info\)\|TODO\|FIXME\|HACK\|XXX" --include="*.ts" --include="*.js" --include="*.py"

• Check for verbose error messages exposing internals
• Check for exposed

  .git/

  ,

  .env

  , source maps, backup files

SSL/TLS:

# If accessible externally
nmap --script ssl-enum-ciphers -p 443 <target>
# Or use testssl.sh

Generate the audit report:

# Security Audit Report: [Application Name]
**Date:** [date]
**Auditor:** [name]
**Scope:** [what was tested]

## Executive Summary
[1-2 paragraph summary of overall security posture and critical findings]

## Findings Summary
| # | Severity | Finding | Phase |
|---|----------|---------|-------|
| 1 | CRITICAL | [title] | [phase] |
| 2 | HIGH     | [title] | [phase] |
| ... | ... | ... | ... |

## Detailed Findings

### Finding 1: [Title]
**Severity:** CRITICAL / HIGH / MEDIUM / LOW / INFO
**Phase:** [which phase found it]
**Affected Component:** [endpoint, file, function]

**Description:**
[What the vulnerability is and why it exists]

**Reproduction Steps:**
1. [Step-by-step to reproduce]

**Impact:**
[What an attacker could achieve — data access, account takeover, RCE, etc.]

**Remediation:**
[Specific, actionable fix with code example if possible]

**Reference:**
[OWASP, CWE, or WAHH chapter reference]

---
[Repeat for each finding]

## Recommendations Priority
1. [Fix critical/high findings immediately]
2. [Fix medium findings before next release]
3. [Fix low/info findings as part of regular maintenance]

## Out of Scope / Not Tested
[What was explicitly excluded and why]

Severity Rating Guide

Severity	Criteria	Examples
CRITICAL	Immediate exploitation, RCE, full data breach, auth bypass	SQL injection with data access, RCE via command injection, hardcoded admin credentials, unauthenticated admin access
HIGH	Significant data exposure, account takeover, privilege escalation	Stored XSS, IDOR on sensitive data, broken access controls, session fixation, missing HTTPS enforcement
MEDIUM	Limited exploitation, requires user interaction, partial data exposure	Reflected XSS, CSRF on non-critical functions, missing SameSite cookies, verbose error messages with internal paths
LOW	Minor information disclosure, best practice violation	Version disclosure in headers, missing X-Content-Type-Options, autocomplete on sensitive fields
INFO	Observation, no direct security impact	Missing Permissions-Policy, minor configuration notes, suggestions for defense-in-depth

Common Mistakes

Mistake	Fix
Testing only the happy path	Test every parameter with malicious input — injection lives in the edge cases
Skipping access control testing	IDOR is consistently a top vulnerability — test every resource endpoint with different user contexts
Only testing through the UI	The UI hides parameters, endpoints, and capabilities — test the API directly
Assuming the framework handles security	Frameworks provide tools, not guarantees — verify each mechanism is correctly configured and used
Testing in isolation	Chain findings — info disclosure + IDOR + XSS can escalate from LOW to CRITICAL
Stopping at first finding per category	One SQL injection doesn't mean all queries are vulnerable — test each endpoint independently