Web & API penetration testing, scoped per project, evidence per finding.
A two-week manual review of your production web application and HTTP / GraphQL APIs against OWASP WSTG and ASVS. Authenticated session testing, business-logic flaws, IDOR, injection chains, SSRF, deserialisation. Findings reproduced with the exact request that proves them — not screenshots, not "trust the consultant".
Five phases over fifteen working days.
Boundaries between phases are soft — phase three starts as soon as scope is signed, phase four runs in parallel with the last days of testing. The day numbers are illustrative for a typical mid-size SaaS engagement.
- §01Scoping & authorisationDays 1-3
Kick-off call, written scope agreement, signed authorisation, ownership verification (DNS TXT or panel screenshot). Read-only access to staging where it accelerates work; production untouched until explicitly approved per surface.
- §02Surface mappingDays 3-5
Subdomain enumeration, certificate transparency review, public-source intelligence, retired-but-still-online asset hunt. The picture an attacker assembles in week one, captured before manual testing begins.
- §03Manual reviewDays 5-12
Authenticated and unauthenticated testing aligned to OWASP WSTG v5. Focus areas weighted by your stack and threat model — e.g. fintech apps see disproportionate time on session, IDOR, business-logic; content platforms on CSP, XSS sinks, file-upload paths; multi-tenant SaaS on cross-tenant access boundaries.
- §04Reproducible evidenceDays 10-13
Each finding gets the exact request, response, or capture that proves it. Severity scored against the scenario actually possible in your deployment, not against a generic CVSS table. Where the finding has remediation impact in the same sprint, the patch suggestion ships with the finding.
- §05Delivery & walkthroughDays 13-15
Written report — executive summary, technical findings, mapped to OWASP WSTG / ASVS / MITRE ATT&CK, remediation notes per item. Live walkthrough with the engineering team. 30-day post-delivery window for clarification and re-tests at no additional cost.
Six surfaces of a typical web stack.
The list below is a coverage map, not an exploit recipe — the public version of the report names finding categories without describing reproduction steps. The full delivered report includes the request, payload, and response per finding for the engineering team only.
- ·Login / signup flows
- ·Password policy & reset
- ·MFA enforcement
- ·Session lifecycle, fixation, hijack vectors
- ·OAuth / SSO grants & redirect URI handling
- ·IDOR across tenant / user boundaries
- ·Vertical & horizontal privilege escalation
- ·Role-based access control gaps
- ·API endpoint authorisation parity with UI
- ·SQL / NoSQL / OS command injection
- ·Server-side template injection (SSTI)
- ·Deserialisation paths
- ·Mass-assignment, prototype pollution
- ·File upload abuse
- ·Stored, reflected, DOM XSS
- ·CSRF posture and token validation
- ·Clickjacking, frame-ancestors
- ·Open redirect chains
- ·PostMessage / window.opener leakage
- ·GraphQL introspection & query depth
- ·Rate-limit & anti-automation
- ·Race conditions on payment / inventory
- ·Workflow bypasses & out-of-order step abuse
- ·SSRF (cloud metadata, internal services)
- ·Webhook validation
- ·TLS posture, header set, cookie flags
- ·Secrets disclosure (.env, .git, debug panels)
A report your engineering team will actually act on.
The deliverable is shaped for the team that owns the codebase, not a board slide deck. Length is set by the findings, not by perceived value-per-page.
2-3 pages, decision-makers
Risk posture against your threat model, top three findings in plain language with the business consequence stated, recommended next steps with rough effort estimates.
One section per finding
Title · severity · CWE · OWASP WSTG / ASVS reference · MITRE ATT&CK technique. Reproduction steps with exact request and response. Remediation note scoped to the stack we found in the audit.
What we tested, what we didn't
Explicit table of WSTG categories covered, time spent per category, and items deferred — with the reason and our recommendation for follow-up.
After remediation, included
Within 30 days of delivery, re-runs of the original tests against your patched build are included at no additional cost. The annex documents the verification result per finding.
What one finding looks like in the delivered report.
Anonymised, redacted-to-the-bone excerpt from a recent engagement. Severity, references, reproduction, and remediation — formatted exactly as the engineering team receives them. Real reports include the raw evidence files (request, response, dig output, screencast) attached as the evidence/ folder described in our reproducer discipline.
An authenticated tenant of acme.example can read invoices belonging to any other tenant by incrementing the invoice_id path parameter on the export endpoint. The session token is validated; the resource ownership is not.
- endpoint GET /api/v2/invoices/{id}/export
- version build 2026.04.18-acme
- scope all tenants on production
- OWASP WSTG · WSTG-ATHZ-04
- OWASP ASVS · V4.2.1, V4.2.2
- MITRE ATT&CK · T1190 / T1078
- OWASP Top 10 2021 · A01 — Broken Access Control
# Authenticate as tenant-A, then read tenant-B invoice 4,210 TOKEN=$(curl -sX POST "https://acme.example/api/auth/login" \ -d '{"email":"tenant-a@x.io","pw":"…"}' | jq -r .jwt) curl -sI "https://acme.example/api/v2/invoices/4210/export" \ -H "Authorization: Bearer $TOKEN" # Expected: HTTP/1.1 403 Forbidden # Actual: HTTP/1.1 200 OK · Content-Type: application/pdf · 184 KB
// invoices.controller.ts — add ownership check before .export() const invoice = await prisma.invoice.findUnique({ where: { id } }); if (!invoice || invoice.tenantId !== req.user.tenantId) { return res.status(404).json({ error: "not_found" }); }
Returning 404 (not 403) avoids leaking the existence of cross-tenant resources. Add the same check to GET /invoices/{id} and DELETE /invoices/{id} — confirmed unaffected at the time of testing but follow the same authz path.
07_retest.sh exit 0 · verified 2026-04-22 · ticket SEC-118
fixed in PR #4421 · merged by [redacted] · prod 2026-04-21 Findings cross-referenced to the rulebooks your auditors already use.
What this engagement does not cover.
We can extend scope on request — but the boundaries below are the default for a single web-pentest engagement so you can plan accordingly.
- ×Mobile clients (iOS / Android). Separate engagement; we use MobSF + manual review for those.
- ×Cloud infrastructure audit. Separate engagement; CIS Benchmarks-based review across AWS / GCP / Azure.
- ×Source-code review. Available as an add-on; otherwise grey-box from authenticated session perspective only.
- ×Social-engineering / phishing simulation. Separate engagement with explicit HR & legal sign-off.
- ×DDoS or load testing. Out of scope; we recommend a load-testing specialist.
Want a scoping note for your stack?
Send us the URL of your application, the rough size of your codebase, and any compliance deadline you are working against. We reply within two working days with a fixed-fee estimate and a proposed timeline.