Web & API Penetration Testing Program

Point a scanner at a multi-tenant API and it will confidently report the missing security headers and miss the finding that actually matters: that changing tenant_id from 4021 to 4022 returns another customer’s invoices. A scanner sees one request at a time. It has no concept of “this user shouldn’t be allowed to do that”, which is precisely the definition of Broken Object Level Authorization — the single most common serious flaw in modern APIs, and the one automation is structurally blind to.

This program is for engineering teams, SaaS platforms and enterprises that need hands-on, evidence-based testing against the OWASP Web Security Testing Guide and the API Security Top 10. It finds the high-severity logic and authorisation flaws scanners can’t reach, then hands back reproduction steps and fixes an engineer can act on — because a finding nobody can reproduce is a finding nobody fixes.

Why Detection Matters During Testing

Most pen tests stop at the vulnerability. This one treats the test as a live exercise for your defenders as well.

Every payload is sent with the blue team in mind, and we track which attacks your monitoring — Cloudflare WAF, AWS CloudTrail, the internal SIEM — actually caught versus which sailed through unseen. Each action is logged with timestamps and source IPs, so afterwards your team can line their alerts up against our timeline and find the gaps. The uncomfortable-but-useful result is usually the same: the exploitation succeeded and nothing fired, which tells you as much about your detection as about the vulnerability. One honest limit — an in-scope, authorised test is noisier and more cooperative than a real adversary, so “we detected the pentest” is encouraging, not proof you’d catch a patient attacker.

How We Test

It starts with clarity on your environments, your authentication boundaries and the business workflows that actually matter — the depth of the test tracks directly with how much of that context you disclose. Where we focus:

1. Reconnaissance & Surface Mapping The deprecated v1 API still live behind v2, the forgotten admin panel, the environment variables leaking in a response. The old and forgotten surface is where the real weaknesses hide, because it skipped the security review the current version got.

2. Authentication & Authorisation Testing OAuth flows, JWT handling, session generation, and privilege escalation both horizontal (another user’s data) and vertical (admin functions). Authorisation is where the severe findings cluster, so it gets the most manual time.

3. Input Validation & Injection SQL injection, SSRF, XSS and XXE with payloads shaped to the endpoint’s actual technology, not a generic wordlist fired blindly.

4. API-Specific Flaws BOLA/IDOR, broken function-level authorisation, mass assignment and excessive data exposure, worked systematically against your OpenAPI/Swagger spec — which is also the honest dependency here: an inaccurate or missing spec means blind testing and thinner coverage.

5. Business Logic Weaknesses Race conditions, state manipulation, and logical bypasses — a cart total edited client-side, a payment step skipped, a discount applied twice. This is the category no scanner will ever find, because the request is individually valid and only the sequence is the attack.

Tooling is Burp Suite Professional, OWASP ZAP, Postman, Nuclei and ffuf, plus custom Python and Bash for protocol-specific cases — but on this kind of work the tools accelerate a human tester, they don’t replace one.

What You Get: Clear, Actionable Results

No 300-page PDF of scanner noise padded to look thorough. Findings your engineers can act on the same day:

• Technical Narrative Step-by-step reproduction for every finding — the actual HTTP requests and responses — with CVSS v3.1 scoring. Bear in mind the base score deliberately encodes no business context, so we flag where your context should push urgency up or down rather than leaving the number to speak alone.

• Risk Register CSV or Excel that imports straight into Jira or ServiceNow, so findings land in the engineers’ queue instead of dying in an email thread.

• Remediation Guide Code-level fixes with OWASP and CIS alignment — addressing the root cause, so BOLA gets a real authorisation check rather than a patch on the one endpoint we happened to test.

• Retest Report Once fixes ship, we re-exploit each finding to confirm it’s genuinely closed — not marked resolved — and provide a signed attestation. This closes the loop the initial report opens.

Typical Vulnerability Impact Matrix

Severity	Finding	Attack Vector & Business Impact	Remediation Priority
Critical	BOLA / IDOR	Authenticated user manipulates tenant_id in API requests to access/modify financial records of other clients.	Immediate (0-24h)
High	SQL Injection	Lack of parameterized queries on an internal reporting dashboard permits extraction of the user credential table.	High (1-3 Days)
Medium	Missing Rate Limiting	Password reset endpoint lacks throttling, allowing brute-force token enumeration for account takeover.	Medium (1-2 Weeks)
Low	Security Header Misconfiguration	Missing Strict-Transport-Security and Content-Security-Policy headers, slightly increasing client-side attack surface.	Low (Next Sprint)

A Typical 30-Day Engagement

• Days 1–3: Setup and planning Lock scope, review the API documentation, provision test credentials across privilege levels (BOLA testing needs at least two real accounts to prove cross-tenant access), and allowlist our testing infrastructure.

• Days 4–12: Active testing A baseline automated pass to clear the obvious, then the bulk of the time on manual authentication, authorisation and business-logic testing — where the findings that matter live.

• Days 13–15: Analysis and reporting Compile evidence, score with CVSS, and write reproduction narratives clear enough to act on without us in the room.

• Day 16: Debrief and handoff Walk the team through the findings and the fixes, live, so questions get answered before the remediation sprint starts.

• Days 17–30: Remediation and retest Your team fixes; we verify each fix actually closes the finding rather than moving it.

The bigger picture: the assessment is a point-in-time snapshot — the next feature branch can reintroduce exactly what you just fixed — so the real value comes from wiring this into the development pipeline rather than running it once a year for a compliance tick. Human testing tells your engineers where the genuine risk is and why; feeding that back into how they build is what stops the same class of flaw returning.