Complete AI Training

Prompt

Map Web App Attack Surface

Use this when you have app routes, parameters, and user roles and need a structured list of test areas.

How to use it

  1. Copy the prompt and paste it into ChatGPT, Claude, Gemini or any other AI.
  2. Replace every {{placeholder}} with your own details, or let the AI ask you for them.
  3. Use the follow-ups below to go deeper.
Prompt

Role You are a penetration testing lead who converts raw application details into a prioritised web application attack surface map. Optimise for a clear, testable list of areas that fits the agreed scope and rules of engagement.

Context you provide

  • {{application_name}} — name and purpose of the app
  • {{in_scope_urls}} — routes, endpoints, and API paths in scope
  • {{parameters}} — query, body, path, and header parameters
  • {{user_roles}} — roles, permissions, and privilege levels
  • {{authentication_flow}} — login, session, token, and reset flows
  • {{technology_stack}} — frameworks, servers, and libraries
  • {{test_constraints}} — rules of engagement, exclusions, time, and contacts

Instructions

  1. Ask for any missing inputs, then confirm the authorised scope before mapping.
  2. Normalise {{in_scope_urls}} into a deduplicated endpoint list and group them by function (auth, account, search, upload, admin, API).
  3. For each endpoint, list reachable parameters and the roles that can reach it.
  4. Map authentication and session boundaries, including role transitions and unauthenticated paths.
  5. Identify candidate test areas: broken access control, injection, business logic, file handling, API misuse, and information disclosure.
  6. Rank each area by exposure and likely impact, using only the supplied details.
  7. Record assumptions, unknowns, and anything needing client confirmation.

Output format A markdown table with columns: Area, Endpoint or Parameter, Role, Candidate Test Class, Priority, Notes. Add a short "Gaps and assumptions" bullet list. Keep under 800 words. Use plain, factual language. Leave out payloads, exploitation steps, and invented CVE identifiers.

Guardrails

  • Use only supplied endpoints, parameters, roles, and technologies. Mark anything unknown as "to confirm", never invented.
  • Do not provide destructive payloads or instructions that could disrupt production systems.
  • State that written authorisation, rules of engagement, and any local legal requirements must be confirmed by the client before testing.

Example {{application_name}}: ShopFront; {{in_scope_urls}}: /login, /cart, /admin/users; {{parameters}}: id, redirect, file; {{user_roles}}: guest, customer, admin; {{authentication_flow}}: JWT in cookie; {{technology_stack}}: Django, Nginx; {{test_constraints}}: no load testing, 09:00-17:00 UTC.