ahmedhamadto/software-forge/web-app-security-audit

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