Home  /  Services  /  Web Application Testing
Services · Applications & APIs

Web and API
penetration testing.

Scanners find the classes that are easy to pattern-match. They do not find the ones that actually get startups breached: an object ID you can increment, a role check missing on one endpoint, a workflow you can run out of order. Those need a human, and that is what this is.

01
Who this is for

Built for product teams shipping faster than they can review.

01

Startups closing their first enterprise deal

The security questionnaire arrived and it asks for a third-party penetration test. You need real coverage and a report that survives a procurement review, without a six-week enterprise engagement.

02

SaaS with multi-tenant data

Tenant isolation is the finding that matters most and the one automated tools are worst at. If one customer can reach another customer's records, nothing else on the report is as important.

03

Teams shipping weekly

Findings arrive as SARIF and JSON, mapped to MITRE ATT&CK, so they land in your existing pipeline as tickets rather than as a PDF nobody opens twice.

02
Coverage

What we actually test.

Weighted toward the classes that scanners under-report and that cause real incidents in SaaS products.

01

Broken access control

IDOR and BOLA across every object type, horizontal and vertical privilege escalation, and tenant isolation tested from a real second tenant rather than assumed from the code.

02

Business logic

Workflows run out of order, steps skipped, negative and boundary quantities, race conditions on state changes, and price or entitlement manipulation. No scanner has a signature for your checkout flow.

03

Authentication and session

Registration and reset flows, token handling and expiry, JWT validation and algorithm confusion, OAuth and SSO misconfiguration, MFA bypass paths.

04

API surface

REST and GraphQL, undocumented and legacy endpoints, mass assignment, over-permissive responses, introspection exposure, and rate-limit gaps on the endpoints that matter.

05

Injection and server-side classes

SQL injection, SSTI, SSRF, deserialisation, file upload handling and path traversal, validated with proof rather than reported on a signature match.

06

Client-side and supporting surface

Stored and DOM-based XSS, CSRF where state changes allow it, CORS misconfiguration, security header gaps, and secrets left in front-end bundles.

03
How the engagement runs

Six steps, every time.

The same disciplined sequence on every engagement, so you know what is happening and when, and so nothing reaches your report unproven.

01

Scope

A conversation, not a form. We agree the boundary, the accounts, the timing and the escalation contact, and it is enforced technically.

02

Map

We build the real picture of what is reachable, which is almost always larger than the inventory you were given.

03

Prove

Every candidate finding is actively validated against a baseline. Anything that fails is demoted or dropped before it reaches you.

04

Chain

Confirmed findings are linked into the routes an attacker would walk. One finding is a ticket. A path is a breach.

05

Report

Evidence, reproduction steps, prioritised remediation and detection content, as SARIF, JSON and HTML mapped to MITRE ATT&CK.

06

Retest

You fix, we verify, and the report is updated. A finding is not closed because someone said it was.

04
Straight answers

The questions we actually get.

Can you test our staging environment?

Yes, and it is usually the right call. Staging needs to mirror production closely, especially in authorisation logic and data model, or findings will not transfer. We will tell you honestly if a staging environment is too divergent to be worth testing.

Will testing take our application down?

The methodology is non-destructive by design and scope is enforced technically, not just agreed in a document. We coordinate any test that carries load risk in advance and give you a contact throughout.

How is this different from a scanner or a bug bounty?

A scanner reports what matches a signature and cannot reason about your business logic. A bug bounty gives you unpredictable coverage and no guarantee anyone looked at your permission model. This is systematic manual coverage with a defined scope, a named tester, and every finding actively confirmed.

What do we receive at the end?

Evidence and reproduction steps for every finding, prioritised remediation, and detection content your team can deploy. Delivered as SARIF, JSON and HTML, mapped to MITRE ATT&CK. Plus a retest of the fixes.

We are a small startup. Is this affordable?

Scope drives cost, and scope is a conversation rather than a fixed package. A focused test on a single product with a defined authorisation model is a very different engagement from a full estate. Ask, and you will get a real number before committing to anything.

Start here

Scoping is
a conversation.

Tell us what you are protecting and what worries you. You will get an honest answer on whether this engagement is the right next step, who would run it, and what it would cost, before you commit to anything.

Direct line contact@lahavsec.com
Offensive Security · Defensive Value
Accepting new engagements