Penetration testing

What a penetration test covers

A test is defined by its scope, not by its tooling. On a web application the work usually sits in six places, and a report that skips one of them describes a smaller system than the one running in production.

• Authentication: how accounts are created, how sessions are issued, and whether the password reset or the second factor can be walked around.
• Authorisation: whether one user, role or tenant can reach another's data by changing an identifier, a parameter, or the order of a sequence of requests.
• Input handling: injection into queries, templates, headers and file paths, tested against the categories the OWASP Web Security Testing Guide describes.
• Business logic: discounts, quotas, approval steps and state machines, where the defect is a sequence the code allows and the business does not.
• Session and token handling: fixation, expiry, revocation, and what happens to a session that already existed when the password changed.
• Configuration and exposure: verbose errors, debug endpoints, permissive CORS, missing security headers, and secrets left in client-side bundles.

Coverage is agreed in writing. Two applications of the same size can need very different scopes, because what sets the effort is the number of ways in, not the number of pages.

What a penetration test does not cover

Most misunderstandings about a report come from what the test was never asked to do. These are the usual ones.

• Denial of service and capacity: flooding a production system measures your patience rather than its security, and it belongs to a separate engagement.
• Source code review: a black-box test sees behaviour. It cannot see the branch nobody deployed, or the library that is only reachable behind a feature flag.
• Social engineering and physical access: phishing, pretexting and entering a building are separate exercises with their own authorisation.
• Compliance certification: a test produces findings, not an attestation. No report makes an organisation compliant with a framework on its own.
• Anything outside the agreed scope: a host, an API version or an environment left out of the scope document is untested, whatever the report implies.

A provider who will not say plainly what falls outside the scope is telling you something about the report you are about to pay for.

How a penetration test runs

The order matters more than the tooling. Each phase produces something the next one uses, and skipping a phase is how an assessment turns into a list of scanner output with no evidence behind it.

1. 01Scope and rules of engagement

   Hosts, accounts, environments, testing windows, and the person who can stop the engagement mid-run. Nothing is touched before that document exists: it is what separates a test from an intrusion.

2. 02Reconnaissance and mapping

   The tester maps what the application exposes: routes, parameters, roles, API versions, and the parts of the surface that no documentation mentions.

3. 03Threat model and test plan

   Effort follows what the application is for. A read-only status endpoint and a payment flow carry different risk, and a plan that treats them the same spends the budget in the wrong place.

4. 04Exploitation attempts

   Every hypothesis is tried against the running system. A suspected weakness stays a suspicion until it produces an effect the tester can demonstrate, with the request and the response that produced it.

5. 05Reporting and retest

   What was reproduced is written up with its impact in your context. Later, a retest says which findings are actually closed, and that part is the only one that stays useful after the fixes ship.

The phase order follows the structure of the Web Security Testing Guide closely enough that the report can be read by anyone who knows that document.

How long a penetration test takes

Duration follows scope, and anyone quoting a figure before reading the scope is guessing. What moves it: the number of distinct roles and tenants, the size of the API surface, whether a staging environment mirrors production, how many test accounts the team can create, and how quickly the client answers questions during the window.

The workable order is scope first, schedule second. A test shortened to fit a date does not produce a smaller result, it produces a result with unknown gaps. When a provider gives you a date before you have described the application, the date is the deliverable.

What the report contains

The report is a working document for whoever has to fix the finding, not a certificate for a drawer.

• A finding per verified issue, naming the endpoint, the parameter and the account it was reached with.
• Reproduction steps: the requests, in order, that produced the effect.
• Impact in your context, which is the part a severity score cannot supply.
• A severity score with the rating system named, so two reports can be compared honestly.
• A remediation direction for each finding, and its retest status once the fix ships.

Anything the tester could not reproduce belongs in a separate annex with its reason, not in the findings list. A suspicion dressed as a finding costs the team as much time as a real one, and teaches them to distrust the report.

Who reads it

• Engineering reads the reproduction steps and the affected endpoint.
• Product reads the business-logic findings, which rarely map to a single line of code.
• Whoever owns the schedule reads the severity vectors and the retest status.
• Leadership reads the summary, and should be told what the test did not cover.

How findings are scored

A severity score is an input to a decision, not the decision itself. CVSS measures the technical properties of a weakness, such as attack vector, complexity, privileges required and impact, and it says nothing about whether the affected feature sits behind a login, handles money, or was switched off last quarter. The same vector can mean different urgency in two companies. The score earns its place when the report puts the vector next to the business context, and it misleads when it is presented as a verdict.

Read the vector, not only the number. A high score on a feature nobody can reach is a scheduling question, and a medium on the login path is not.

Authorisation comes before the first request

A test runs on a written authorisation naming the target, the accounts, the window, and the person who can stop it. That document is what separates an assessment from an intrusion, and it protects the tester as much as the client. A provider who accepts a verbal go-ahead, or a scope that includes systems the client does not own, is not doing the client a favour.

Sources

Every technical statement on this page follows a public document. None of them is ours.

• OWASP Web Security Testing Guide — test categories, and the order they are run in
• OWASP Top 10 — the risk categories web applications share most often
• FIRST, CVSS v4.0 specification — the scoring system named under How findings are scored
• NVD, National Vulnerability Database — public identifiers for known vulnerabilities

Where a sentence on this page is not backed by one of these documents, it describes how we work rather than a rule of the trade.