Start by recording the application’s roles, observed requests, inputs, data flows and trust boundaries. A visible menu is only one view of the system. A short map helps you choose a testable question; it does not prove a vulnerability or establish complete coverage.
This guide provides a planning method for authorized training apps. Its examples and time allocation are illustrative, not results from a reported lab experiment. Technical sources reviewed: October 16, 2026.
What a useful map should show
Separate three labels in your notes: observed for a captured request or confirmed configuration, inferred for an explanation consistent with that evidence, and unknown for what you cannot establish. For example, an application returning saved content does not identify its database product or prove that it has a separate database server.
The OWASP architecture mapping guidance describes identifying components and their interactions. With developer documentation or authorized source access, you may verify more than a browser-only view allows. Record that limitation instead of drawing an invented backend.
1. Record requests rather than just menu items
Perform a normal task in the lab while observing browser developer tools or an approved intercepting proxy. Record the HTTP method, path, relevant parameters, current account and response purpose. Include background requests that support the task. The OWASP entry-point checklist covers request and response analysis, including inputs outside visible form fields.
A client-side route may display an application shell while a separate API supplies the data. An endpoint name such as /admin is a lead, not evidence of unauthorized access. Record only the accounts and endpoints you actually observed; “system” may describe a component rather than a login role.
2. Trace a small data flow and mark gaps
Choose one feature, such as saving a profile. Note where a value enters, where you can observe it again, and what remains unknown between those points. Distinguish immediate responses, later reads and visible state changes. Seeing a saved value does not tell you which validation occurred internally.
Example planning note: “Display name submitted in a JSON request; visible on a later profile read; server-side validation and storage implementation unknown.” This supports a question about handling that value without asserting SQL injection, XSS or a particular storage technology.
3. Define who should be allowed to do what
A trust boundary is a point where data or actions pass between different trust contexts, such as browser to server or one account’s objects to another’s. Write the expected policy before testing. PortSwigger distinguishes authentication, session management and access control: identifying a user does not establish permission for every resource.
For an authorization exercise, use two lab accounts and objects you control. First confirm each account can perform the intended allowed read. Then compare the prohibited case while keeping the relevant request context consistent. Check returned data and actual effects, not just a status code or page title. Missing menu links, sequential IDs and a 200 response alone do not establish an authorization defect.
4. Classify inputs without predicting the result
Group observed inputs by location: query string, path, form or JSON body, cookie, and header. Add their apparent purpose, such as object identifier or search term. These are application-layer inputs; their names do not reveal whether the server trusts them. A field named role is a hypothesis to investigate, not proof that changing it changes privileges.
5. Record what your tools actually covered
Keep the tool mode, accounts, routes and actions included in a run. A report with no findings does not demonstrate that every role, workflow or endpoint was exercised. Compare its observed coverage with your map before choosing a follow-up. For a wider discussion of evidence and validation, the existing web exploitation essentials guide develops those distinctions.
6. Treat session state as a separate question
Record how a lab identifies subsequent requests and what happens when you log out. A confirmation screen or a removed browser cookie does not by itself demonstrate that a previous session can no longer authorize a request. Follow the lab’s rules for testing old credentials or tokens, and protect captured session material in your notes.
The OWASP logout test also discusses server-side invalidation and separate application and SSO sessions. Describe which session you tested; returning through SSO may create a new session rather than revive the one you logged out of.
7. Leave a reproducible next step
End the map with one question, the evidence needed to answer it, and a safe stopping point. “Check authorization” is too broad. “Compare a read of account A’s test object under accounts A and B, then record the response contents” is a bounded task when the lab permits it. If evidence contradicts your hypothesis, update the map.
Use ten minutes as a first-pass budget
An illustrative allocation is two minutes to confirm scope and available accounts, three to observe one normal workflow, two to label evidence and unknowns, and three to write one follow-up question. That totals ten minutes. Setup, troubleshooting and deeper validation need separate time. Stop with an incomplete map if necessary; the timer does not certify coverage.
Plan time from your own session records
The former complexity-and-depth estimator has been removed because its weights were not validated. Track actual setup, observation, testing and note-taking time instead. Use several comparable sessions to plan your next session, and keep unfamiliar technology or missing prerequisites as separate uncertainties.
Choose a lab that supports your question
Choose OWASP Juice Shop when you want to observe a JavaScript-heavy application and REST API workflows. For a self-hosted PHP training app, check the DVWA project instructions, including its warning against public exposure. For a focused authorization exercise, use a relevant PortSwigger lab linked from its access-control guide. This is a choice by learning goal, not a universal difficulty ranking.
A copyable evidence template
Lab and version:
Authorized scope and allowed actions:
Account / role / test object owner:
Observed method, path and input locations:
Normal workflow and expected permission:
Evidence reference (redact tokens):
Observed data flow:
Inferred components and reasons:
Unknowns:
Hypothesis and comparison needed:
Result, limitations and next step:Review the notes by asking: Can another learner identify the account and object involved? Is the claimed result supported by the recorded response or state? Have alternative explanations been checked? Which parts of the application were never observed? These questions improve the usefulness of the record without adding an unsupported success score.
Keep practice inside the authorized environment
Apply the lab’s scope and permitted methods wherever you are practicing. A vulnerable training application is not permission to test unrelated services. Avoid real personal data and reusable passwords in lab accounts, and redact tokens before sharing notes. Country-specific legal permission cannot be inferred from this technical guide.
Questions before the next session
Do you need a paid proxy? Begin with the requests visible in browser developer tools. Choose additional tooling when the task requires capabilities that view does not provide. Whatever the tool, record limitations; neither a captured workflow nor a completed lab establishes full application coverage.
What should you do next? Select one permitted feature, observe its normal behavior, and fill the template through “Unknowns.” Choose one unanswered question for the next practice block. If time is limited, adapt the two-hour study routine to your available time rather than treating a fixed schedule as a completion promise.