Web & API
Penetration Testing

Your application follows rules.
Attackers look for exceptions.

We test what happens when someone bypasses a workflow, changes an identity or calls an API in a way you never intended.

WEB & API / SECURITY REVIEW
Web applicationBrowser · API client
API endpointREST · GraphQL
SERVER-SIDE SECURITY CONTROLS
  1. 01

    Authentication

    Who is making the request?

    IDENTITY
  2. 02

    Authorization

    Can they access this resource?

    ACCESS
  3. 03

    Business logic

    Is this action valid in this workflow?

    WORKFLOW
Protected data & business operations
We test the controls behind every critical request.

01 / ACCESSAnonymous & authenticated testing

02 / SURFACEBrowser, REST & GraphQL

03 / CONTEXTMultiple roles & business workflows

WHAT WE INVESTIGATE

Where application flaws
become business losses.

Coverage follows your architecture and highest-value journeys. These are the questions we bring to the assessment.

01

Can an attacker take over an account?

Test password recovery, MFA transitions, session handling and OAuth flows for gaps that allow impersonation.

RECOVERY FLOWS · TOKENS · SSO
02

Can a user become an administrator?

Check role boundaries, object ownership and writable API fields for privilege escalation and unauthorized changes.

AUTHORIZATION · MASS ASSIGNMENT
03

Can a valid workflow be abused?

Challenge checkout, refunds, approvals and account changes by skipping steps, replaying requests or testing concurrency.

BUSINESS LOGIC · RACE CONDITIONS
04

Can an API expose more than it should?

Assess REST and GraphQL access controls, sensitive responses, legacy endpoints and differences between API versions.

REST · GRAPHQL · DATA EXPOSURE
05

Can input reach a dangerous interpreter?

Trace untrusted input into database queries, templates, operating-system calls and browser rendering.

SQL INJECTION · SSTI · XSS
06

Can the server be used as a foothold?

Investigate URL fetchers, file uploads and parsers for SSRF, path traversal and unsafe execution paths within the agreed scope.

SSRF · FILE UPLOADS · PARSERS

OWASP Web and API guidance informs coverage; your application's behavior determines the test cases.

THE SPACE BETWEEN ASSESSMENTS

What changed since
your last pentest?

A report reflects the application that was tested. New endpoints, permissions and integrations can introduce risks that the previous assessment never examined.

51weeks

without a scheduled pentest
when testing takes place for one week each year.

ONE YEAR OF APPLICATION CHANGE52 WEEKS
Scheduled pentestChanges continue between assessments
New API endpointsPermission changesNew integrationsCritical releases
Illustrative annual schedule. Pentest duration varies; automated security testing and other controls may continue throughout the year.

TEST AFTER MAJOR APPLICATION CHANGES

Align pentesting with your releases.

Combine a broad assessment with focused testing of significant changes. Review affected workflows, verify the fixes and agree the next checkpoint around your release plan.

Plan your next assessment

ASSESSMENT DEPTH

A login page is only
the beginning.

The strongest coverage comes from testing the same action across different identities, interfaces and states.

Across identities

Compare anonymous, customer, support and administrator access. Verify that the server enforces the permissions the interface implies.

Across interfaces

Follow actions from the browser to the API. Check whether direct requests bypass restrictions, hidden controls or validation in the UI.

Across workflow states

Revisit actions after logout, role changes, approval, cancellation and token expiry. Test whether earlier permissions remain usable.

BUILD THE RIGHT SCOPE

Bring the journeys
you cannot afford to lose.

Start with a high-level overview. We agree the access, boundaries and testing windows before you share sensitive material.

Applications & APIs
Domains, API specifications or collections, key integrations and the target environment.
Roles & critical journeys
Test identities, permission expectations, payments, approvals and sensitive data flows.
Boundaries & safeguards
Excluded systems, third-party permissions, rate limits, test data and escalation contacts.
Delivery expectations
Release dates, reporting needs and remediation priorities. Duration follows the agreed scope.

BEFORE WE BEGIN

A few practical
questions.

Can you test an API without a web interface?

Yes. An OpenAPI specification, Postman collection or documented request set provides a starting point. We also need authentication details, test accounts and the expected permissions for in-scope operations, shared through an agreed secure channel.

Do you need source code?

Source code is not required for a typical black-box or grey-box assessment. Architecture context and test accounts help us go deeper. Source-assisted testing or a separate code review can be agreed where it adds value.

Can testing run against production?

Where appropriate and explicitly authorized, with agreed testing windows, rate limits, test accounts, exclusions and escalation contacts. Staging is preferable for tests that could alter data or affect availability. Testing cannot be guaranteed risk-free.

What will my engineering team receive?

A report with affected endpoints, prerequisites, reproducible evidence, impact and remediation guidance, plus a findings walkthrough. Agreed findings can be retested after remediation within the 90-day retest window.

LET'S TALK ABOUT YOUR APPLICATION

Which workflow would
hurt most if it failed?

Discuss your application

Engineer-led scoping · Mutual NDA available