Web Application Attack Surface Mapping

When to Use

Use this skill at the start of any authorized web application security engagement — before any vulnerability probing, scanning, or exploitation. The mapping phase determines which areas of the application are worth investing time in and which vulnerability classes are most likely.

Invoke it when:

• You have explicit authorization to test a web application (bug bounty scope, penetration test contract, internal security review, or own application)
• You are beginning a code review with a security focus and need to understand the application's attack surface before diving into individual functions
• You want to identify all the ways user-controlled data enters the application — not just the obvious form fields
• You have proxy traffic, source code, or application artifacts to analyze and need a structured methodology

Do not invoke it for unauthorized access to systems you do not own or have permission to test.

Context and Input Gathering

Required Context (must have — ask if missing)

• Authorization confirmation: Has explicit authorization for testing been granted?
• Check prompt for: keywords like "authorized," "bug bounty," "pentest," "internal review," "own application"
• If missing, ask: "Do you have explicit authorization to perform security testing on this application? If yes, what is the scope?"

• Target definition: What is the application being mapped?
• Check prompt for: a URL, domain name, application name, or codebase path
• Check environment for: source code directory, HTTP capture files (.har, Burp export), or API spec files
• If still missing, ask: "What is the target application? (URL, codebase path, or description)"

Observable Context (gather from environment)

• Source code available: Look for web framework files (routes.py, urls.py, web.xml, routes.rb, *.controller.ts), config files (application.properties, .env), and template directories.
• HTTP traffic available: Look for .har files, Burp Suite exports, or traffic captures in the working directory.
• Existing security artifacts: Look for prior pentest reports, OpenAPI/Swagger specs, or architecture diagrams.
• Technology indicators: Look for package.json, pom.xml, Gemfile, requirements.txt, composer.json to infer the stack without HTTP traffic.

Default Assumptions

• If no proxy tool is specified, Burp Suite Community/Professional is assumed as the primary interception proxy.
• If authorization is unclear from a codebase-only review context, assume the user owns or has authorization to review the application.
• If no scope boundary is stated, treat the entire domain (and its subdomains if mentioned) as in-scope.

Process

Step 1: Establish the Spidering Baseline

ACTION: Walk through the application manually using a browser proxied through an interception tool (Burp Suite, OWASP ZAP, or equivalent), visiting every linked page and submitting every form. Simultaneously, run an automated spider against the already-visited content.

WHY: Automated spiders miss content hidden behind JavaScript navigation, Flash/Java applets, forms with validation, and authentication-protected areas. User-directed spidering with a proxy captures everything the human can see — including JavaScript-triggered navigation — while the proxy parses all server responses for additional content automatically. The combination is more thorough than either technique alone.

Procedure:

1. Configure the browser to route all traffic through the proxy
2. Browse the entire application normally: click every link, submit every form with valid-looking data, complete all multi-step workflows (registration, checkout, password reset)
3. Try browsing with JavaScript enabled, then disabled — some applications serve different content in each mode
4. Try browsing with cookies enabled, then disabled — some content paths are reachable only in the cookieless state
5. After completing the manual walk-through, review the proxy's site map for any content identified by parsing server responses that you did not visit directly
6. For any such content, access it manually through the browser so that the proxy can parse the server's response for further links
7. Repeat Step 6 recursively until no new content appears
8. Check robots.txt — it frequently lists directories the application owner does not want indexed, which are often the most sensitive areas worth testing

AGENT: EXECUTES (when source code is available) — grep for all route definitions, template links, and form action attributes to produce a complete URL list without live access.

HANDOFF TO HUMAN (when live access is required) — the human browses while the proxy captures traffic; the agent analyzes the captured site map.

WARNING: Never run an automated spider against an application without first identifying and excluding dangerous endpoints (admin delete functions, data-erasure operations, logout URLs). An automated spider that follows all links can cause real damage — defacing content, deleting users, or breaking sessions.

Step 2: Discover Hidden Content

ACTION: Enumerate content not linked from the visible application using three complementary techniques: brute-force enumeration, inference from naming patterns, and mining public sources.

WHY: Applications routinely contain unlinked content — debug pages left from development, old versions not removed from the server, functionality visible only to higher-privilege users, configuration files with credentials, and backup copies of live pages. None of these appear in a spider's site map. Finding them can reveal critical vulnerabilities that the main application surface does not expose.

2a. Brute-Force Enumeration

Use a tool with a wordlist (Burp Intruder, DirBuster, ffuf, gobuster, or a custom script) to request common directory names and file names within every known directory:

1. Make test requests for known-valid and known-invalid resources first to establish how the server signals a missing resource. Many applications return 200 OK with a custom "not found" page rather than 404. Record the response fingerprint for genuinely missing resources so you can filter it from results.
2. Start at the web root and enumerate common directory names
3. For each discovered directory, enumerate common file names within it
4. Capture the full response (not just status code) and review manually — a 302 redirect to the login page indicates an authenticated-only resource that exists; a 401/403 indicates an existing but access-restricted resource; a 500 often indicates a resource that exists and expects specific parameters
5. Perform each exercise recursively as new directories are found

Response code interpretation guide:

• 200 OK — Resource exists and is accessible (verify it is not a custom "not found" page)
• 302 to login page — Resource exists, authentication required
• 302 to error page — May indicate a different condition; investigate further
• 401 Unauthorized / 403 Forbidden — Resource exists but access is restricted regardless of privilege level
• 400 Bad Request — May indicate nonstandard naming conventions or invalid wordlist entries
• 500 Internal Server Error — Resource likely exists and expects specific parameters

2b. Inference from Naming Patterns

1. Review all enumerated resources to identify naming conventions (capitalization style, abbreviation patterns, verb prefixes like Add, Edit, View, Delete)
2. Infer sibling resources: if ForgotPassword exists in /auth, look for ResetPassword, ChangePassword, UpdatePassword
3. For numeric identifiers in URLs (e.g., /pub/media/117), probe adjacent values in the observed range
4. Add common backup and temporary extensions to known file stems: .bak, .src, .inc, .old, .tmp, .php-1, .DS_Store
5. For source files compiled into live pages (.java, .cs), request the source extension — misconfigured servers may serve raw source code

2c. Mine Public Sources

1. Query search engines using advanced operators against the target domain:
• site:target.com — all indexed pages
• site:target.com admin — pages containing specific keywords (administrative areas, login functions)
• link:target.com — pages on other sites that link to the target (may reveal partner-only URLs)
2. Check web archives (Wayback Machine at archive.org) for historical content that may no longer be linked but is still live on the server
3. Search developer forums and issue trackers for the names of known developers — technical questions they posted may reveal functionality, technology choices, or known bugs
4. View cached versions of pages to find content that requires authentication or payment on the live site

AGENT: EXECUTES — analyzes source code for hardcoded paths, commented-out links, disabled form fields, and server-side include references. Produces a candidate URL list.

HANDOFF TO HUMAN — wordlist-based brute-force and live HTTP probing require tool execution against a live target.

Step 3: Identify All User-Input Entry Points

ACTION: Catalog every location where user-controlled data enters the application — including non-obvious channels that are frequently overlooked.

WHY: Vulnerability testing is only as comprehensive as the entry point catalog. Missed entry points mean missed vulnerabilities. Many critical flaws (SQL injection, cross-site scripting, path traversal) are discovered at entry points that automated scanners miss because they do not appear in HTML forms — they appear in HTTP headers, URL path segments, or out-of-band channels.

Entry point categories to enumerate:

Special attention — HTTP headers: Many applications trust the X-Forwarded-For header for the client's IP address when running behind a proxy. If this header is processed without validation, injecting SQL or scripting content into it can trigger injection vulnerabilities. Similarly, spoofing User-Agent to a mobile device string often reveals a separate mobile-optimized code path that has received less security review.

Special attention — non-standard parameter formats: If the application does not use the standard name=value&name2=value2 format, understand the actual encoding before testing. Treating a URL like /dir/file?data=%3cfoo%3e%3c%2ffoo%3e%3cbar%3e%3c%2ffoo2%3e%3e as a single parameter called data will miss injection points inside the embedded XML.

Step 4: Fingerprint Server-Side Technologies

ACTION: Determine the technology stack — web server software and version, application framework, programming language, database, and third-party components — from the available indicators.

WHY: Technology identification directly predicts which vulnerability classes to prioritize. A PHP application on Apache has a different vulnerability profile than a Java application on WebSphere. Known third-party components may have published Common Vulnerabilities and Exposures (CVEs) that are directly exploitable. Version information enables precise vulnerability lookup.

Fingerprinting sources:

HTTP fingerprinting: Even when the Server header is suppressed or falsified, behavior differences in how the server handles invalid requests, the ordering of response headers, and the exact formatting of error messages can identify the underlying software. Run a behavioral fingerprinting tool (httprecon, WhatWeb) against the target when banner-based identification is inconclusive.

Third-party component identification: Search for the names of unusual cookies, custom HTTP headers, or distinctive JavaScript library calls. Locate other applications using the same component to understand its full feature set and known vulnerabilities. Check CVE databases for the identified component and version.

Step 5: Infer Server-Side Functionality and Structure

ACTION: Reason about the server-side implementation by analyzing request structure, parameter names, and application behavior — treat every observable artifact as a clue about how the server processes requests.

WHY: Understanding what the server is doing enables identification of vulnerability classes that are not yet visible from the application's surface. Parameters named OrderBy suggest database queries where the value may be used directly in an SQL ORDER BY clause. Parameters named template or loc suggest file retrieval that may be vulnerable to path traversal. Boolean parameters set to false may control functionality that attackers benefit from setting to true.

Analysis approach:

1. For each request, review every parameter name and value in context of the function being performed. Ask: "What server-side mechanism is most likely handling this?" Common patterns:
• OrderBy, sort, sortField parameters → SQL ORDER BY injection candidates
• template, page, include, file, path parameters → path traversal or server-side include candidates
• redirect, url, next, returnUrl parameters → open redirect candidates
• to, from, subject parameters in mail-sending functions → email header injection candidates
• isExpired, isAdmin, edit, debug Boolean parameters → access control bypass candidates by toggling the value

1. Look for consistent patterns across functions — if input sanitization is applied in one area, it may be uniformly applied (or uniformly absent) across the application. A function that visibly echoes user input to the page reveals the sanitization logic, which you can then test against other entry points.

1. Identify areas where behavior diverges from the application's norm — different visual style, different parameter naming conventions, commented-out code referencing a different framework. These "bolted-on" areas are frequently missing from the application's standard security controls (authentication checks, CSRF tokens, input validation middleware).

Step 6: Map Behavior to Vulnerability Classes

ACTION: For each functional area identified, assign the most likely vulnerability classes based on the behavior and technology patterns observed.

WHY: Attack surface mapping is only actionable when it produces a prioritized test plan. A behavior-to-vulnerability matrix translates the reconnaissance findings into specific things to test, preventing both the unfocused "test everything" approach and the risk of missing high-probability vulnerability areas.

Apply this mapping:

Prioritize the map by combining two factors: likelihood (how often this vulnerability class appears in this technology) and impact (what an attacker gains if it is present). Authentication bypass, SQL injection, and access control flaws are typically highest priority.

Inputs

• Application access (live target via browser + proxy, OR source code directory, OR HTTP traffic captures)
• Scope definition (which domains, paths, user roles are in-scope)
• Authorization confirmation for the target

Outputs

• Content inventory: Enumerated URLs, directories, and functional paths discovered through spidering and content discovery
• Entry point catalog: Table of all user-input locations — URL segments, parameters, cookies, HTTP headers, out-of-band channels
• Technology fingerprint: Web server, application framework, programming language, database, third-party components with version information where available
• Functional path map: For parameter-driven applications, a map showing which parameters control which functions and their logical dependencies
• Behavior-to-vulnerability matrix: Prioritized list of functionality areas mapped to vulnerability classes, ordered by estimated risk

Key Principles

• Coverage before depth — The mapping phase is about breadth. Resist the urge to probe a promising entry point in depth until the full surface is enumerated. A vulnerability found in the first 10 minutes may be less significant than one hiding in content discovered in the last 10 minutes of mapping. WHY: skilled assessments are always time-boxed; investing testing time against the complete surface produces better risk coverage than deep-diving the first interesting thing found.

• User-directed spidering beats automated spidering — Automated spiders miss JavaScript navigation, form validation requirements, and authenticated content. A human browsing with a proxy captures all of these while the tool handles the mechanical parsing work. WHY: modern applications increasingly rely on client-side navigation mechanisms that do not appear in static HTML — a conventional spider that only follows links will miss large portions of the application.

• Naming patterns are reconnaissance — The naming conventions a developer uses (verbose vs. abbreviated, verb-first vs. noun-first, CamelCase vs. snake\_case) are consistent and predictable within an application. Mining these patterns dramatically improves brute-force effectiveness. WHY: developers typically write all their code in a consistent personal style; inferring that style from observed names allows you to generate a far more targeted wordlist than a generic dictionary.

• HTTP headers are entry points — The Referer, User-Agent, X-Forwarded-For, and Host headers are processed by many applications for logging, analytics, access control, and content personalization. Treating them as read-only is a testing oversight. WHY: headers that are logged are often concatenated into queries or log entries without sanitization — the same classes of injection that affect form fields apply to header values that are processed server-side.

• Bolted-on functionality escapes standard defenses — In mature applications with centralized security frameworks, the highest-yield areas are not the core functions but the features added after the framework was established. Debug functions, CAPTCHA implementations, third-party integrations, and recently added features often bypass the application's middleware-level input validation and authentication checks. WHY: these additions are frequently built by different developers, under time pressure, and without full awareness of the application's security conventions — they are structurally more likely to contain vulnerabilities.

• The site map is a prioritization tool, not just a record — The goal of mapping is not to have a complete list of URLs but to understand which areas deserve the most testing attention and what vulnerability classes are most likely present. A complete map with no prioritization is less useful than a partial map with clear next steps. WHY: testing time is always finite; the attack surface map must translate directly into a test plan.

Examples

Scenario: External penetration test of an e-commerce platform

Trigger: "I'm starting a pentest on a client's shopping site. I have authorization and they've given me a staging environment URL."

Process:

1. Configure Burp Suite as proxy; browse the full application — browse product catalog, register an account, complete checkout, test password reset
2. Review Burp's site map; note robots.txt discloses /admin/ and /staging-api/ — both unlinked from the visible application
3. Run Burp's content discovery against /admin/ — finds Admin, AdminLogin, Dashboard, ExportUsers, BulkDelete; ExportUsers returns 302 to login, BulkDelete returns 200 directly
4. Fingerprint: Server: Apache/2.4.41, X-Powered-By: PHP/7.3, session cookie named PHPSESSID, /shop/ uses REST-style URLs
5. Entry points catalog: 47 URL parameters, 12 POST fields, 8 cookies, X-Forwarded-For header processed for free-shipping threshold check
6. Map /admin/BulkDelete (no auth required, 200 response) → access control bypass; REST URL product IDs → path traversal; X-Forwarded-For processed → injection; checkout discount_code parameter → business logic; search sort parameter → SQL injection candidate

Output: Prioritized test plan with BulkDelete access control bypass as P0, SQL injection in sort parameter as P1, X-Forwarded-For injection as P2.

Scenario: Security review of an internal HR application source code

Trigger: "Can you review our internal HR application for security issues? Here's the repo."

Process:

1. Grep route definitions in routes.py and urls.py — identifies 84 endpoints including /api/admin/export-all-employees not referenced in the frontend
2. Search for all form inputs and API parameters; identify manager_id parameter that accepts arbitrary integers and appears in a raw string format SQL query
3. Check requirements.txt for outdated dependencies; find django==2.2.0 (end-of-life, multiple known CVEs)
4. Grep HTTP header processing: X-Employee-Level header used in authorization logic without validation
5. Search for commented-out code: finds # TODO: add auth check comment above three API endpoints
6. Map: direct SQL injection in manager_id, missing authentication on three endpoints, authorization bypass via X-Employee-Level spoofing, Django version vulnerabilities

Output: Written security assessment with four critical/high findings and remediation guidance.

Scenario: Bug bounty reconnaissance on a SaaS product

Trigger: "I want to map the attack surface of this SaaS product before I start testing — it's in my bug bounty scope."

Process:

1. Check scope definition — confirm allowed subdomains and excluded paths
2. Browse application across three privilege levels (unauthenticated, regular user, admin)
3. Run content discovery on each subdomain with a targeted wordlist inferred from observed naming patterns
4. Query site:target.com in Google; Wayback Machine reveals /v1/api/ endpoints from 3 years ago — test whether they still respond
5. Search GitHub for developer names found in HTML comments — find a developer's Stack Overflow post containing a full database schema
6. Identify mobile User-Agent triggers a different code path with less aggressive rate limiting on the login endpoint

Output: Attack surface map covering 6 subdomains, 312 endpoints, 4 distinct user roles, legacy API still live, and login brute-force vector on mobile code path.

References

• For the behavior-to-vulnerability matrix with deeper detail per vulnerability class, see attack-surface-vulnerability-matrix.md
• For technology fingerprinting indicators (file extensions, directory names, session token names, HTTP header signatures), see technology-fingerprinting-reference.md
• For wordlist generation strategies and inference-based naming approaches, see content-discovery-strategies.md
• For HTTP response code interpretation during brute-force enumeration, see response-code-interpretation.md

License

This skill is licensed under CC-BY-SA-4.0.

Source: BookForge — The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws by Dafydd Stuttard, Marcus Pinto.

Related BookForge Skills

This skill is standalone. Browse more BookForge skills: bookforge-skills