VAPT / Penetration Tester interview preparation

A penetration test starts with permission and boundaries, not tooling. For an owned training application, write a rules-of-engagement document identifying the application, test accounts, permitted methods and exercise window. If testing for another party, obtain explicit written authorisation from someone with authority over the systems. Include third-party exclusions, emergency contacts and stop conditions. A hostname in scope does not automatically authorise testing its hosting provider, identity service, payment processor or every address discovered during application use.

Define how evidence will be handled before collecting it. Use synthetic users and records, minimise captured content, and store artifacts in an access-controlled folder with a cleanup schedule. State that denial-of-service, credential guessing, persistence and access to unrelated data are excluded from this beginner lab. Document which actions need additional approval and how to pause when unexpected sensitive information appears. Your artifact should make it possible for another tester to distinguish an allowed verification step from an unauthorised escalation.

Build the lab with an owned application and two disposable accounts, then take a backup or snapshot. Verify that its traffic cannot accidentally target production services or send messages to real people. Establish a restoration procedure and test it with a harmless configuration change. If availability degrades or a scope boundary becomes unclear, stop and contact the designated owner. A professional decision to avoid an unsafe test is valid evidence of judgement, not a failure to complete an exploitation sequence.

Map normal application behaviour before testing unusual inputs. Browse the owned application as a guest and each test user, recording routes, request methods, authentication requirements and business actions. Distinguish a read operation from a state-changing action even when both look like simple links. Your artifact is a compact endpoint inventory with expected permissions and data sensitivity. This helps select meaningful tests and avoids treating every response difference or exposed technology name as a confirmed vulnerability by itself.

For each potential finding, use a repeatable sequence: restate the claim, verify safely, assess contextual severity, choose fix, defer, accept or false-positive, and write the evidence. A scanner might identify a missing header, but its practical impact depends on application behaviour and other safeguards. CVSS describes technical severity; actual prioritisation also needs exposure, exploitation evidence, asset importance and business impact. Record tool versions and relevant settings without implying that a tool's output is authoritative or complete.

In the lab, compare an unauthenticated request with an authenticated request to a harmless profile page. Capture status codes and a minimal response excerpt, ensuring no real personal information is present. If the result is ambiguous because of caching or redirects, investigate those mechanisms before writing a finding. Use OWASP WSTG to structure coverage and OWASP Top 10:2025 to communicate broad risk categories. Neither reference guarantees that every application-specific weakness has been tested or that unobserved flaws are absent.

Broken object-level authorisation occurs when a server accepts an object reference without enforcing the caller's right to that object. Create two owned users, A and B, with equivalent roles, and give each one a synthetic private note. Record the intended policy: each user may read only their own note. Successful authentication establishes who the caller is; it does not establish permission to every requested record. Your test matrix should cover both allowed access and explicitly forbidden cross-user access.

Capture user A's ordinary request for A's note using an approved local inspection tool. While remaining authenticated as A, replace only the note reference with the identifier of B's known synthetic note. Do not enumerate identifiers or target other users. Compare the response with the expected denial and confirm that any returned content is genuinely B's note, not cached A content or a generic page. Preserve only the minimal request and response fields needed to reproduce the result.

Repeat the direction from B to A if it remains within scope, then document the server-side outcome. An appropriate implementation denies unauthorised access without returning protected content; a hidden button or unpredictable identifier is not sufficient authorisation. Recommend an ownership or entitlement check tied to the authenticated principal on every relevant request. For retesting, verify both cross-user denials and successful legitimate reads, including any alternate endpoint in scope. Stop immediately if the exercise reveals information outside the two owned accounts.

Authentication testing should validate a defined security property without creating unnecessary risk. In the owned application, inspect how sessions are created, how logout changes server-side validity and whether protected routes reject unauthenticated requests. Use disposable credentials and avoid brute-force testing in this beginner exercise. Record cookie attributes and the application context rather than assuming one attribute proves security. Your artifact is a session-behaviour table showing the request, expected result, observed result and any uncertainty about caching or token expiry.

If you own the application's code and database, review password storage using synthetic accounts. Passwords should be processed with an appropriate adaptive password-hashing scheme, such as Argon2id following current OWASP guidance, not stored in plaintext or reversibly encrypted for login comparison. Record algorithm configuration without exposing secrets or full credential material. A secure hash does not repair weak authentication flows or stolen sessions. Recommend parameter review and migration planning, considering system capacity and compatibility rather than copying settings without testing.

Review transport configuration against the protocol actually used. TLS 1.3 authenticates certificate-based handshakes through CertificateVerify signatures; it does not use RSA key transport. Certificate validation and endpoint identity remain important, while encryption alone does not establish that an application is trustworthy. In a local lab, inspect a known TLS connection and document its negotiated version and certificate context. Explain visibility limits and configuration dependencies instead of claiming that a successful handshake proves secure business logic or correct user authorisation.

A useful finding helps an owner reproduce and fix a specific problem without exposing unnecessary data. For the two-user access-control exercise, include the affected route, preconditions, intended policy, minimal reproduction steps and synthetic evidence. Explain the observed consequence separately from hypothetical extensions. If only read access was tested, do not claim write access or organisation-wide compromise. Your report should distinguish confirmed findings, unverified observations and tests not performed because of scope, safety constraints or missing access to required systems.

Assign technical severity using a documented method and explain contextual priority separately. A laboratory note-reading flaw demonstrates a mechanism, but production impact depends on actual data, exposed users and deployment conditions. Recommend server-side entitlement enforcement and regression tests rather than merely obscuring identifiers. Record the owner's disposition as fix, defer, accept or false-positive, supported by evidence. Deferred or accepted findings need an accountable owner and review condition; the tester should not silently decide that business risk is acceptable.

Retest the deployed change rather than relying on a developer's statement that the code was updated. Confirm the environment and build, repeat the original forbidden request, and verify that legitimate owner access still works. Add a relevant alternate route only if authorised, and state the retest's coverage limits. Attach dated before-and-after evidence with sensitive fields removed. Finally, restore lab settings, delete disposable accounts as agreed and record cleanup, retaining the report according to the approved evidence schedule for this exercise.