Yaamlabs
Offensive Security

Web Application Penetration Testing

Your web application and the APIs behind it, tested by hand against the running system. Every finding ships with a working reproduction, not a scanner signature.

Most web breaches do not come from a missing patch. They come from access control that trusts the client, a workflow that can be replayed, or an object reference nobody checked. Scanners see the pages that link to each other and stop there. They cannot reason about who should reach what, or which step of a purchase can be skipped.

We test with real accounts, at every privilege level, against the environment you ship to. Authentication, authorisation, business logic and the APIs behind the interface, worked by hand. Automated tooling maps the surface and flags the obvious; it does not decide what counts as a finding. The engineer who finds the bug writes it up, and confirmed findings reach your channel as they land, not in a report on the last day.

Usually, one of these is true

  • An enterprise customer or a prospect's security review asks for a recent third-party penetration test report before they will sign.
  • You are about to release a feature that changes authentication, billing, or how one tenant's data is separated from another's.
  • A SOC 2 or ISO 27001 audit needs evidence of application testing that maps to its control set.
  • A bug bounty report or an internal review surfaced an access control flaw, and you want the whole authorisation model checked, not just that one endpoint.

What we test

We scope to the application, its roles and the APIs it depends on. Grey-box by default: real accounts at each privilege level, so testing reaches the logic behind the login rather than stopping at the front door.

  • Authentication and session. Session fixation, token lifetime and revocation, MFA enrolment and reset, password reset flows, and every path that issues a credential without one.
  • Access control. Horizontal and vertical checks on every object, role and tenant boundary, insecure direct object references, and the endpoints the interface never calls.
  • Business logic. Workflow steps taken out of order, replayed and negative quantities, coupon and limit abuse, and race conditions on anything that moves money or state.
  • Injection and server side. SQL, NoSQL, template and command injection, server-side request forgery, unsafe deserialisation, and upload paths that trust the filename or content type.
  • The API surface. REST, GraphQL and webhooks behind the interface: introspection, batching abuse, mass assignment, and missing object-level and function-level checks.
  • Client side and SSO. Cross-site scripting, CSRF, CORS misconfiguration, and OAuth and SAML flows: redirect handling, token scope, and what a compromised third party can reach.

How the test runs

Five stages, agreed in writing before anything starts. One named engineer, one shared channel, findings as they are confirmed.

  1. Scope. We agree targets, accounts, rate limits, test windows and an abort path in writing, then sign rules of engagement. Nothing is touched before that.
  2. Map. We walk every route, role and API the application exposes, including endpoints the interface never calls, so testing covers the whole surface rather than the happy path.
  3. Test by hand. Manual testing against the running application at each privilege level. Tooling narrows where to look; a finding is confirmed by exploiting it, not by a scanner rating.
  4. Report live. Confirmed findings reach your channel with a working reproduction as they land. Anything critical is reported within the hour of being confirmed.
  5. Retest. Once fixes ship we re-run the affected tests, confirm what actually closed, and issue a letter of attestation.

What you get

  • Findings report. Each issue with a working reproduction, the affected requests, a CWE mapping and a CVSS v4.0 rating, written by the engineer who found it.
  • Executive summary. A short account of what was tested, what was found and what it means for the business, for people who will not read the technical detail.
  • Remediation guidance. Specific fixes tied to your stack and framework, ordered by risk, for the developers who will close them.
  • Live channel access. Direct contact with the tester throughout, so questions are answered as findings arrive rather than weeks later.
  • Retest and attestation. A second pass over the fixes and a letter of attestation for your customers and auditors, included in the engagement.

What we need from you

  • Two test accounts per role, including one administrator, on a staging environment that mirrors production.
  • A reachable test environment, plus any allowlisting our source addresses need to get through a WAF or IP filter.
  • API documentation where it exists: an OpenAPI or Swagger file, a Postman collection, or example requests and responses.
  • A named technical contact who can reset test data, clear locked accounts and answer questions while testing runs.
  • Written authorisation to test, and confirmation of anything explicitly out of scope, such as third-party systems or denial-of-service.

What we can show you

  • Research, not only testing. 70+ CVEs published by our researchers, with research acknowledged by Apple, Microsoft, Google OSS VRP, Facebook, Twitter, Adobe, Intel and the U.S. Department of Defense. The same eye for a novel bug goes into your application.
  • The tester writes the report. No account-manager layer and no junior bench. The engineer who finds the bug writes it up, so nothing is lost in a hand-off to a report writer.
  • The fix comes with the finding. One team runs testing, hardening and engineering, so a finding can become a fix without a hand-over, and the retest and attestation are part of the engagement.
  • Your name stays yours. Mutual NDA and PGP before you send anything. Evidence stays encrypted and least-privilege, and is destroyed after the retest on request. Client names stay undisclosed.

Standards we work to

We structure the work against the public methodologies your reviewers already recognise, so the report maps onto the framework you report into without translation.

  • OWASP WSTG
  • OWASP Top 10
  • OWASP API Security Top 10
  • OWASP ASVS
  • PTES
  • CWE
  • CVSS v4.0

Common questions

Do you test black box or grey box?

Grey-box by default. We work from real accounts at each privilege level, because most serious web flaws live behind the login, in access control and business logic, where an unauthenticated scan never reaches. We can run a black-box phase first if you want to see what an outsider finds with no help.

Do you test in production or staging?

A staging environment that mirrors production is safest, and it is what we recommend. We can test production where that is the only realistic option, but we agree destructive actions, rate limits and test windows in the rules of engagement first, and we avoid anything that risks live data or availability.

Do you just run a scanner?

No. Tooling maps the application and flags the obvious issues, which frees time for the manual work. Every finding is confirmed by exploiting it by hand and comes with a reproduction you can run yourself. We do not report a scanner result we have not verified.

Will the report satisfy our SOC 2 or ISO 27001 auditor?

It gives auditors what they ask for: an executive summary, technical findings with evidence, CVSS v4.0 ratings, remediation, and a retest confirming fixes. We do not issue certifications ourselves. We produce the independent testing and evidence an assessor needs and work alongside whoever signs off.

What happens if you find something critical mid-test?

We report it to your channel within the hour of confirming it, on the escalation path agreed at kickoff, with the reproduction attached, rather than holding it for the final report. If it is serious enough to warrant pausing, we agree that with you before going further.

Related services

Tell us about the system in the chat or on the contact page. Yaali, our AI agent, answers first and brings in an engineer.