Web app pentest: what gets tested, how it runs, how to prepare

What a web app pentest is, and what it is not

A web application penetration test, or web app pentest, is an attack on your own app, run with your written permission, to find out what someone else can actually do with it: read data that is not theirs, skip a login, call a route meant for admins, reach a secret key. NIST's technical guide to security testing describes the attack phase as verifying suspected weaknesses by attempting to exploit them. So every finding in a good report comes with the request that worked, and you can replay it yourself.

That is the difference with a vulnerability scan. A scanner matches versions and responses against known patterns and returns a list of things that might be wrong. A pentest proves which ones are real, and finds the bugs a scanner cannot see without context: one user reading another user's records, a price changed in the request, a permission that only exists in the interface. The pentest vs vulnerability scan guide compares the two in detail.

It matters most for apps that were built fast. The OWASP Top 10:2025 puts broken access control first and says 100% of the applications tested in its data set had some form of it. In apps generated with AI tools, the pattern is on public record: CVE-2025-48757 was assigned after a researcher found that 170 of 1,645 Lovable apps tested, about one in ten, let unauthenticated visitors read or write data because of missing or weak row level security (RLS). Lovable disputes the CVE, on the grounds that each customer is responsible for protecting their own app's data.

Black box, grey box or white box?

The three names describe how much the tester knows before starting. They change what the test can find, so choose on purpose.

For an app with user accounts, grey box is the sensible default. Many access control bugs only appear when user B asks for something that belongs to user A, and a black box tester without two accounts cannot see that. If your code sits in a repository you control, as it usually does with apps built in Cursor or Claude Code, adding a white box pass is cheap: reading the RLS policies, the Firebase rules and the API handlers tells the live attacks where to look. The white box, black box and grey box guide shows what each one finds on a generated app.

The phases of a web application penetration test

NIST SP 800-115 splits a penetration test into four phases: planning, discovery, attack and reporting. Vendors rename and subdivide them, but the shape holds. The fifth step below is the one that decides whether anything got safer. The penetration testing methodology guide compares the standards behind these phases.

1. 1

   Scope and rules of engagement

   List every domain, subdomain, API host and backend project in scope, and what is out, such as your payment or email provider. Agree on the test window, the accounts to use, what the tester may write or delete, and who to call if something breaks. In NIST's model no testing happens in this phase: it ends with documented approval.

2. 2

   Discovery

   The tester maps the attack surface: pages, JavaScript bundles, API routes, Server Actions, the backend the browser talks to, the keys and table names shipped in the bundle, source maps, forgotten subdomains. Then comes vulnerability analysis: comparing what was found, framework versions included, with known weaknesses.

3. 3

   Attack

   Each suspicion is tried for real: as a stranger, as user A, then as user B asking for A's data. A careful tester proves impact with the least harm possible: one row read rather than the whole table, writes rolled back, no denial of service.

4. 4

   Report

   Each finding gets a severity, the affected endpoint, the exact request and response that proved it, the impact in plain words and the fix. NIST notes that reporting runs alongside the other phases. In practice, ask to hear about a critical finding the day it is found, not in a PDF at the end.

5. 5

   Fix and retest

   You fix, then the same request and its variants are replayed. Close the finding only once the attack fails.

What gets tested on a modern web app

The categories are old; where they live has moved. In a React or Next.js app on Supabase or Firebase, the browser often talks to the database directly, so the database policies are the access control. An external pentest covers the rest of what you expose: domains, storage and the server behind the app.

• Authentication. Sign-in with no rate limit, reset links returned in the API response, sign-up that reveals which emails exist, session cookies without HttpOnly or Secure.
• Access control. User B reading or changing A's record by swapping an id, known as an IDOR; a role field accepted in a profile update; Supabase policies or Firebase rules that only check that someone is signed in.
• Data exposure. API responses that return whole rows, with emails and internal flags, when the screen shows a name; public storage buckets holding private files.
• Injection. SQL built from strings; user content rendered as raw HTML; a server that fetches any URL it is given, called server-side request forgery (SSRF).
• Misconfiguration. A served .env file or .git folder, public source maps, debug pages, permissive CORS, missing security headers. See the exposed .env guide.
• Secrets. Keys that reached the bundle through a NEXT_PUBLIC_ or VITE_ variable: OpenAI, Stripe secret, Supabase service role. Next.js and Vite copy those variables into the browser code at build time.
• Known CVEs. For example the Next.js middleware bypass, CVE-2025-29927, or React2Shell, CVE-2025-55182, which CISA lists as exploited in the wild. A good test proves the flaw by its behaviour, not from a version number.
• AI routes and webhooks. AI endpoints that answer anyone and spend your credits (unprotected AI endpoints), payment webhooks that skip the signature check (Stripe webhook security).

OWASP Top 10 2025, mapped to Next.js, Supabase and Firebase

Most reports map findings to the OWASP Top 10. The 2025 edition reordered it, added Mishandling of Exceptional Conditions, widened Vulnerable and Outdated Components into Software Supply Chain Failures, and folded SSRF into Broken Access Control. Here is what each category looks like in a modern app, and how a tester checks it.

Run the two-account test on your own app

You do not need a tester to try the most common finding. Create two accounts in your own app, sign in as each one in a separate browser profile, and copy each access token from the Authorization header in the developer tools Network tab. Then ask for one of A's records as B.

# Run against your own app only, with two test accounts you created.
# 1. As user A, read one of A's records and note its id.
curl -s "https://your-app.example/api/orders/A_ORDER_ID" \
  -H "Authorization: Bearer $TOKEN_A"

# 2. As user B, ask for the same id.
curl -s -w "\nHTTP %{http_code}\n" "https://your-app.example/api/orders/A_ORDER_ID" \
  -H "Authorization: Bearer $TOKEN_B"

# Supabase: the same check through the REST API of your own project.
# Use the table and id of one of A's rows, and B's access token.
curl -s "https://YOUR_PROJECT_REF.supabase.co/rest/v1/orders?id=eq.A_ORDER_ID&select=*" \
  -H "apikey: $SUPABASE_PUBLISHABLE_KEY" \
  -H "Authorization: Bearer $TOKEN_B"

On Supabase, the Supabase RLS guide shows the policies that stop it. On Firebase, paste your rules into the Firebase rules checker. On Next.js, remember that a Server Action is reachable by a direct POST request even when the page that renders it checks the session: the Next.js docs say to verify authentication and authorization inside each action.

How to prepare your app for a pentest

A pentest is only as good as the access it gets. Sort these out before day one.

• Write the scope. Every domain, subdomain and API host, plus the backend projects behind them: Supabase project ref, Firebase project ID. Name what is out of scope too, such as your payment or email provider.
• Prove you own it. Expect to prove you control each domain, for example with a DNS TXT record or a file on the site, and to sign a written authorization. Be wary of anyone who will test without one.
• Read your providers' rules. Supabase lets customers test their own project without prior approval, but forbids denial of service, request flooding and cross-tenant attacks. Vercel allows non-volumetric tests on Pro and Enterprise plans without notice, not on Hobby; volumetric tests need Enterprise and advance notice, and you pay the usage the test generates.
• Create test accounts. Two per role: two regular users, two admins if you have an admin area, in two different teams if your app is multi-tenant. Give each one some data, so there is something to protect.
• Pick the environment. Production shows the real configuration. Staging is safer for write tests, but only tells you about production if it runs the same build, the same policies or rules and the same environment variables.
• Back up and seed. Take a database backup and use test records you can afford to lose.
• Let the tester through. Tell your team the dates. To test the app rather than the firewall, allowlist the tester's IP addresses: Vercel suggests setting them to Bypass in the project firewall.
• Share what helps. The list of roles, the tables holding personal data, an OpenAPI file if you have one, and repository access for a white box test.

How to read a pentest report

A report is useful when each finding can be replayed and fixed without a meeting. Check that every finding has these four parts.

• The proof: the exact request, the identity that sent it (anonymous, user A, user B) and the response that showed the problem.
• The impact in your terms: which data, how many rows or users, read or write.
• A severity, usually a CVSS score. On the CVSS scale, 0.1 to 3.9 is low, 4.0 to 6.9 medium, 7.0 to 8.9 high and 9.0 to 10.0 critical.
• The fix, at the right layer: a database policy, a server-side check, a header, an upgrade. Hiding a button is not a fix.

Read severity with your own data in mind. An IDOR rated medium on a generic scale can be the worst finding in the report if the records are invoices or medical notes. Watch for three kinds of padding: findings with no proof, pages of informational notes about headers, and CVEs claimed from a version string alone. The sample pentest report shows what a finding with proof looks like.

Retesting: when is a finding actually fixed?

Replay the exact request that proved the finding, with the same identity. If it now fails, check the variants before you close it:

• The same bug on sibling routes: fixed on /api/orders/:id, still open on /api/invoices/:id.
• Other methods on the same route: reads blocked, updates still allowed.
• Other doors to the same data: a table locked by RLS but still readable through a view or a database function.
• Leftovers: a leaked key removed from the code but never rotated, a private page still served from a cache.

Then keep retesting. A fix lives in code that keeps changing, and a coding agent asked for a new feature can rewrite the route you just fixed. A pentest from last spring says little about the app you shipped this week, which is why we attack again after every fix and on every deploy.

Manual pentest or automated attacks?

Both have a place. A human tester is the best way to find flaws specific to your business: a refund that can be claimed twice, an invite link that grants the wrong role, a chain of small bugs. Automated attacks cover the known classes every time the code changes, with the same proof. For a small team, a workable order is automated attacks from the first deploy, then a manual test before a big launch or an enterprise deal. See automated penetration testing, penetration testing for startups and penetration testing cost.

Keybrum is the automated side, built for apps made with AI. It runs more than 100 attacks as a stranger and as two signed-in users: Supabase tables, functions and storage, Firebase rules, IDOR across accounts, secrets in the bundle, unprotected AI routes, unsigned Stripe webhooks, exposed .env files, and Next.js and React CVEs proved by behaviour, never with remote code execution or denial-of-service payloads. It only attacks apps whose owner proved ownership, and your coding agent reads each finding and its fix through MCP.