Your first penetration test should end with a finding that another person can verify and a repair that a team can test again. Imagine a museum preparing a volunteer portal. Visitors can read public event information, volunteers can manage their own shifts, and supervisors can download rosters for their assigned galleries. The museum wants a limited assessment of a rehearsal deployment filled with fictitious records. The deliverables are an agreed scope, a record of checks actually executed, and a set of findings that can be handed to the people who own the affected components.
Agree on the scope and write down expected behavior
Ask the application owner for exact hostnames, the build identifier, the testing window, and the people who can stop the run. Include request budgets, accounts and roles, permitted state changes, and where redacted evidence may be stored. Agree on a reset procedure before generating uploads or sending notifications. A link from the portal to a shared identity provider or a third-party upload destination does not bring those services into scope. If a redirect takes you away from the rehearsal deployment, record the dependency and leave the destination alone unless the owner separately authorizes it.
Map one ordinary journey end to end. A volunteer logs in, requests a shift, receives a decision and checks the revised schedule. A supervisor logs in, reviews the request, and exports the roster for the assigned gallery. Record which steps depend on a background job, which operate directly on a resource, and where role or ownership changes the outcome. Ask the business owner what should happen when a volunteer is removed from a shift after an export has already been created. If the rule has not been decided, record the gap as a question; the observed behavior alone cannot tell you which outcome was intended.
Turn the map into a set of check cards. Each card needs a build, a test identity, the relevant fixture state, an expected result, a way to collect evidence and a stop condition. A roster card can start with one fabricated volunteer in each gallery. The expected result is that an East Gallery supervisor can download the East roster but cannot retrieve the West roster. Have someone who understands staffing policy review the cards before execution. They may spot a legitimate cross-gallery exception or a role that your fixtures have not modeled.
Capture a baseline and select a tool for each job
Use a separate browser profile with synthetic accounts and walk through the normal journeys. Record the routes used, where state changes, and which steps return sensitive fields. Developer tools can capture a useful first inventory without installing anything. An intercepting proxy can help compare two authorized requests, but configure the capture to stay within the rehearsal domain. Redact authorization headers, cookies and any persistent identifiers before attaching examples. A proxy installed in a general-purpose browser profile could record unrelated sessions, so keep the test profile separate and remove any test trust settings when done.
Choose scanners according to the evidence you need. A configuration check can surface an exposed diagnostic page or a missing header; an inventory comparison can show that a release includes a component you did not expect. Keep target lists explicit and disable automatic expansion, destructive checks and uncontrolled retries. Inspect the tool's default templates before execution. Treat the output as a list of leads and write down which lead was confirmed, could not be reproduced or was outside scope. A version match may need confirmation of the deployed artifact or a backported fix; a missing header needs a concrete explanation of what that omission enables in this particular application.
A methodology assistant can draft check cards from a sanitized role matrix. A request comparison tool can isolate changes between two fixture identities. An evidence assistant can turn confirmed observations into a report while preserving test IDs and unresolved questions. Before using any of them, check where inputs are sent, whether the tool can be limited to the approved target, and whether it distinguishes observed results from inferred causes. Test its output using one known allowed case and one known denied case before trusting it on a longer run. If it cannot preserve the distinction, use a manual comparison or a smaller test harness.
For practice, OWASP Juice Shop is a deliberately vulnerable application that can be run in a private lab. Walk through a normal shopping action before exploring a training challenge, and use the exercise to practice recording a clean baseline, a specific observation and a retest condition. A result in the lab tells you how your evidence collection works. The museum report must still come from checks run against the authorized museum rehearsal build.
Reproduce a finding without broadening the test
Suppose a volunteer follows a saved bookmark and receives a roster download. Confirm which identity is actually active before opening a finding; an old supervisor session could explain the result. Establish a clean baseline with a supervisor and the expected East Gallery fixture, then repeat the observation with a separate volunteer session. Check whether the body contains protected roster data, a harmless placeholder or a sign-in page returned with a success status. If the application queues an export and later serves the file from another endpoint, record generation and retrieval as separate actions. The owner needs to know which boundary failed.
A scanner might also flag an upload endpoint. Ask the owner which content types are permitted, then use inert files with recognizable labels to test the documented behavior. Check the response, the expected storage state, and whether the file is visible to another approved fixture identity. Keep a failure to reject an unsupported type separate from a failure to restrict reads after upload; different components may be responsible. If requests leave the authorized destination, start triggering operational alerts or write data beyond the agreed fixture, stop and give the owner the request IDs and time window. Resume when the environment has been checked and the affected part of the plan is clear.
Report evidence, impact and the route to a fix
Start the report with tested and excluded scope, build identifiers, timing and limitations. Give each finding a stable ID and include the preconditions, expected behavior, observed behavior, affected role and the smallest evidence sample that proves the difference. Explain practical impact. Access to cross-gallery contact details means something different from a cosmetic warning in an isolated rehearsal environment. Keep unverified scanner output in a separate appendix or issue list, and do not use a tool's severity label as the final priority without explaining the evidence.
For the roster finding, propose a policy check tied to the current identity and gallery on the export endpoint and again at retrieval. Create retest cases for a volunteer, the authorized East Gallery supervisor and the West Gallery supervisor. The volunteer and the unrelated supervisor should not obtain the file; the authorized supervisor must still be able to complete the normal workflow. If the fix also revokes old download links, add a case using an old synthetic link. Save the fixed deployment ID and retest date with the results. A removed download button can be useful interface feedback, but the evidence for closing the finding comes from the service boundary.
A useful remediation table gives the owner one action per issue, the expected completion signal and the person who will retest. For example, item P-03 can point to the redacted download evidence and a three-role fixture; item P-04 can say that third-party object storage could not be exercised within scope. Keep unresolved questions visible in the release discussion. A short summary for the museum's project lead can state the impact and the coverage gaps, while the technical attachment gives the developer enough information to reproduce the issue without obtaining raw logs or production records.
Questions that come up in a first assessment
Is a clean scan enough to approve release?
Check whether the scanner could reach the authenticated workflows and whether the fixture data put the application into the relevant state. A scan of the landing page cannot establish that an approved roster is protected. Record what you executed, what you skipped and what would be needed to test the missing path.
Why did a finding disappear when I repeated the test?
Compare the deployment, account, fixture and timing. An expired link and a newly generated link are two different cases. A background job may have finished between requests. Recreate the necessary state with synthetic data and record the exact point at which results diverge. If the evidence remains incomplete, leave the issue open as awaiting confirmation.
Can source review replace testing in the rehearsal build?
Source review can identify a missing permission check and suggest where to focus. A runtime check can show that a particular identity received a particular response from the deployed system. Report them separately when only one is available. If the team later gives you a rehearsal build, use the source finding to create a specific runtime check with a positive control.