Pentest methodology: the phases in order, and the standards behind them

What a pentest methodology is, and the phases in order

A pentest methodology is the written order of work behind a penetration test: what is agreed before anyone attacks, how the tester learns the target, how suspicions become proven findings, and how fixes get checked. PCI's penetration testing guidance has a report checklist that asks a blunt question: is the methodology clearly stated?

NIST SP 800-115 cuts the work into four phases, PTES into seven sections, PCI's guidance into pre-engagement, engagement and post-engagement; NIST says there are many acceptable ways to group it. For a web app, it runs in eight steps:

1. Scoping and rules of engagement: what is in and out, who may be attacked as whom, and what the tester may change.
2. Reconnaissance: what the app gives away to anyone who loads it.
3. Mapping: every reachable target, and which identity can reach it.
4. Discovery: which targets look weak, compared with known flaws.
5. Exploitation with proof: each suspicion tried for real, with the request that worked kept as evidence.
6. Impact: how far a working attack goes, in rows, data types and money.
7. Reporting: findings with proof, severity and fix, plus what was not tested.
8. Fix and retest: the same attack replayed after the fix, until it fails.

The web app pentest guide folds these into five steps. Here is each one on a real stack, with what it should leave in your report.

Each phase on a Next.js and Supabase app

Take a typical app built with a coding agent: Next.js on Vercel, Supabase for data, sign-in and storage, Stripe, and an AI provider behind an API route. The browser talks to Supabase with the public key, so the database policies are the access control.

1. Scoping and rules of engagement

You list every host in scope: the production domain, any preview domain, the Supabase project at https://YOUR_PROJECT_REF.supabase.co with its Edge Functions and storage, and your API routes. Stripe, the AI provider and your email sender stay out. Then the rules: the test window, the accounts, whether writes are allowed, what happens if real personal data is reached, how a critical finding is reported mid-test, and the source IP addresses. PCI's guidance adds success criteria: the point at which the test is complete. In NIST's model, no testing happens in this phase.

Your providers set rules too. Supabase lets customers test their own project's auth, database, Edge Functions, storage and realtime without prior approval, but forbids denial of service, request flooding and attacks on other customers. Vercel allows pentests on Pro and Enterprise plans, not Hobby, and never against its hosting infrastructure. In the report: the signed authorization, how ownership was proven, the scope, dates with a time zone, identities and limits. Testing only from the internet? See external penetration testing.

2. Reconnaissance

The tester loads the app as a browser does and reads every JavaScript chunk it downloads, including routes the menu never shows, and any public source maps. Out come the Supabase URL and public key, table names in calls like supabase.from('orders'), bucket names, API routes and the framework version. PTES calls this intelligence gathering; NIST makes it the first part of discovery. In the report: each key with the file it came from, and versions as observed in responses, not guessed.

3. Mapping

Each table, database function, bucket, Edge Function, API route and Server Action becomes a target, tagged with who can reach it: anyone, any signed-up user, one team, an admin. The closest PTES section, threat modeling, names the assets worth stealing (the profiles table, invoices in storage, your AI credits) and the likely attackers: for most young apps, a stranger with or without an account. In the report: the target list with the identity used against each.

4. Discovery

Each target is compared with known weaknesses: row level security (RLS) off on a table, a policy that only checks that the caller is signed in, a security definer function the public role can call, a public bucket of private files, a Next.js version inside the range of a CVE such as the middleware bypass. NIST calls this vulnerability analysis: automatic for scanners, while manual work can find new or obscure flaws, more slowly. A vulnerability scan stops here, with suspicions only (pentest vs vulnerability scan). In the report: leads tried and refused, kept apart from findings.

5. Exploitation with proof

Each lead is tried for real: as a stranger, as user A, then as user B asking for A's records, because many access control bugs only show between two accounts (IDOR and broken access control). The proof does the least harm: one row rather than the whole table, writes only on the tester's own records, no floods. On sensitive data, PCI's guidance says only a proof-of-concept test should be performed. NIST loops from attack back to discovery, since a working attack often reveals new targets. In the report: for each finding, the exact request, the identity, the response and the time, with personal data masked.

6. Impact

Then the reach: how many rows, which columns, read or write, and what it chains into. A Supabase secret key (sb_secret_...) or legacy service_role key found in the bundle bypasses RLS and reaches the whole database. A policy open to any signed-in user turns a free sign-up into a copy of your customer list. PTES calls this post exploitation. In the report: the impact in your terms (data types, row counts, who can do it) and how severity was set.

7. Reporting

In NIST's model, reporting runs alongside the other phases, with logs and periodic reports before the final one. PCI's suggested outline holds an executive summary, scope, methodology, limitations, a testing narrative, the findings, the tools used and cleanup instructions, and says that merely reporting lists of vulnerabilities does not meet the intent of a pentest. The pentest report sample walks through a finding with its proof. Phase 8, fix and retest, has its own section below.

The penetration testing standards, compared

Five documents come up when customers, auditors and testers talk methodology. Each has a free edition, and most have not changed in years.

The phases have barely moved since 2008. What these documents predate is the stack AI tools generate, where the browser talks to the database and the access rules live in its policies, so a report should say which tests ran, not only which standard. For a web app, a sound proposal names PTES or NIST for the phases and the WSTG for test cases, plus PCI's guidance when card data is in scope (PCI DSS penetration testing).

What the methodology section of a report should state

"We followed OWASP and PTES" tells you very little. The section should let you repeat the test, or compare two reports line by line:

• The standard and its version. OWASP asks for versioned test IDs, such as WSTG-v42-ATHZ-04, because IDs can change between versions.
• The type of test: black box, grey box with test accounts, or white box with the code (what code access adds).
• The identities: anonymous, user A, user B, an admin, and how each was obtained.
• The window and origin: dates with a time zone and source IP addresses, to find the test in your logs.
• The automated and manual split, which PCI's report checklist asks to see.
• Limitations: what was not allowed (deletes, floods), what could not be reached (an admin role with no test account) and why.
• How severity was set, with the scale explained.
• Evidence and cleanup: how proofs are stored and destroyed, and which test accounts were removed.

Red flags of a scan sold as a pentest

• Nobody asks you to prove you own the app or to agree rules of engagement.
• Your app has logins, and nobody asks for test accounts.
• The methodology names standards but never says which tests ran against which targets.
• Findings come without a request and a response, or say the application "may be vulnerable".
• CVEs are claimed from a version string, with no sign that the vulnerable behaviour was observed.
• Most findings are missing headers, none involves two users, and no retest is offered.

PCI's guidance states the rule behind these flags: simply running an automated tool does not satisfy the penetration testing requirement, because the tool cannot interpret what it finds to assess the true risk.

Which phases software can run, and which need a human

The automated penetration testing guide goes deeper on where software stops.

How Keybrum maps onto the phases

Keybrum is the automated side, built for apps made with AI tools. It only attacks an app whose owner proved ownership, then covers reconnaissance, mapping, exploitation and retest. Its attacks target Supabase and Firebase rules, leaked secrets, unprotected AI endpoints, unsigned Stripe webhooks and IDOR across two accounts, and each finding comes with the request that worked. CVEs are proven by behaviour, never with remote code execution or denial-of-service payloads. Cloudflare's security-audit skill is part of its code audit, whose findings are then proven live. Your coding agent reads each fix through Keybrum's MCP server.

Retesting: a finding closes when the attack fails again

A fix is a claim until the attack that proved the flaw fails on the live app. PCI's guidance says exploitable vulnerabilities must be corrected on production systems and the testing repeated. NIST lists retesting among the ways to verify a fix, and notes that the testers can only verify it by repeating the original test. PTES stops at reporting, so put the retest in the contract.

A retest replays the same request, identity and target: the stranger's read of profiles now returns nothing, user B's request for A's invoice is refused. Then it tries the doors next to it, since PCI notes that a flaw found in one area of an app may exist in others: a table locked by RLS can still leak through a view or a database function, and a route fixed for reads can still accept updates.

PCI adds two rules: a retest report shows both dates, the original findings and each result; and when fixes drag on, a new test may be needed, because the app being retested is no longer the app that was tested.

Comparing proposals? Ask each tester, person or tool, to walk you through these eight phases on your stack and to show a redacted sample report. For budgets, see penetration testing cost; for timing, penetration testing for startups.