APPLICATION SECURITY / WEB & API

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.

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.

ONE FLAW. A DIFFERENT LEVEL OF ACCESS.

A password reset.
An account takeover.

A recovery email can be legitimate.
The link inside it may not be.

If an application builds reset links from an untrusted host header, an attacker may redirect the recovery link to a domain they control. A user following that link can expose a valid reset token.

We examine the full chain: how the URL is constructed, where the token travels and whether it can be redeemed to take over the account.

See how findings are documented (sample PDF, opens in new tab)
ILLUSTRATIVE FINDINGHIGH IMPACT

Password-reset poisoning

Untrusted URL construction → stolen reset token

  1. 01
    Trust is misplaced

    The recovery service accepts an attacker-controlled host value.

  2. 02
    A genuine email carries a poisoned link

    The test user follows the reset link, exposing its token.

  3. 03
    The token unlocks the account

    The attacker redeems the captured token before it expires.

REMEDIATION DIRECTION

Use a trusted, configured origin for recovery URLs. Enforce single-use, short-lived tokens and review proxy-header trust.

Demonstration scenario, not a client finding. Requires a vulnerable reset flow and user interaction; severity depends on the application.

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