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
- Copy the prompt and paste it into ChatGPT, Claude, Gemini or any other AI.
- Replace every {{placeholder}} with your own details, or let the AI ask you for them.
- Use the follow-ups below to go deeper.
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
- Ask for any missing inputs, then confirm the authorised scope before mapping.
- Normalise {{in_scope_urls}} into a deduplicated endpoint list and group them by function (auth, account, search, upload, admin, API).
- For each endpoint, list reachable parameters and the roles that can reach it.
- Map authentication and session boundaries, including role transitions and unauthenticated paths.
- Identify candidate test areas: broken access control, injection, business logic, file handling, API misuse, and information disclosure.
- Rank each area by exposure and likely impact, using only the supplied details.
- 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.