Applications

API & web services pentest

A test of the APIs behind your products and integrations — REST, GraphQL and the endpoints nobody documented — focused on the authorization and rate-limit failures that make an API far easier to abuse than the app in front of it.

Book a scoping call All services

areas covered

stages, scoping to retest

In-house

testers, never subcontracted

portal.cyberlysecure.com/acme-health/coverage

Acme Health — Test coverage4 practices · 16 services · one team

In-house

Web app

API

SaaS

Mobile

Client-side

External

Internal

Segment test

Wireless

Vuln. assessment

Cloud config

Hardware & IoT

AI & LLM

Social eng.

Physical

Red team

ApplicationsNetworkCloud & devicesPeople & premises

6 in scope · one team · one report

In-house testers 0 subcontracted

Every surface one team

What this is

What the test covers.

An API has no interface to hide behind. Every endpoint is reachable, every parameter is editable, and the checks a web front end performs for convenience mean nothing to a client the attacker writes themselves.

We test your API as its own attack surface: what each token can reach, what happens when an identifier is changed, and what an automated caller can do before anything stops them.

OWASP API Security Top 10 OWASP Web Security Testing Guide OWASP ASVS

What we test

Object-level authorization — changing an id to reach data that belongs to somebody else
Authentication and token handling: JWT validation, OAuth flows, refresh, revocation and expiry
Property-level authorization and mass assignment on create and update calls
Rate limiting, pagination abuse and unrestricted resource consumption
Input validation and injection across every parameter, header and body field
GraphQL introspection, query depth, aliasing and batching abuse
Server-side request forgery and outbound fetches
Undocumented, deprecated and older-version endpoints still answering in production
Webhook and callback handling, including signature verification

How it runs

From scoping call to retest, here’s what happens.

Typically one to two weeks, depending on how many endpoints and roles are in scope.

Scope and authorize

We agree the endpoints, environments and test windows in writing, and note anything that must not be touched.

Build the map

From your specification, traffic capture or the client itself, we enumerate every endpoint — including the ones the documentation forgot.

Test authorization first

Every endpoint is exercised with each token type, then with the wrong token, then with no token at all.

Push the limits

We test what an automated caller can extract, trigger or exhaust, and what your logging and rate limits do about it.

Report, readout and retest

Findings arrive with the exact request that proves them, and we retest your fixes once they ship.

What it surfaces

The kind of thing this test tends to find.

Real examples of what this engagement uncovers — anonymized, and never every time. What matters is that you find out before somebody else does.

One customer’s token retrieving another customer’s records by id

Fields accepted on update that were never meant to be client-controlled — roles, balances, flags

Tokens that stay valid after logout, password change or user deactivation

Old API versions still live and still vulnerable long after the new one shipped

Endpoints an automated client can call without limit, in cost or in volume

Frameworks this test supports

Testing that counts toward your framework.

These programs call for this test, or their assessors and your customers expect it. If one of them is on your desk, readiness and testing come from the same team.

SOC 2

APIs are often the real edge of the system in a SOC 2 description; testing them shows the logical access controls in CC6 hold where customers and integrations connect.

SOC 2 readiness

PCI DSS

Payment APIs and integrations with gateways and processors are part of the application layer an assessor expects to see tested.

PCI DSS readiness

ISO 42001

Most AI features are reached through APIs; testing them shows that model endpoints enforce authorization and do not expose one customer’s data to another.

ISO 42001 readiness

CSA STAR

The CCM expects APIs to be designed, tested and protected to the same standard as the application; an API test evidences those controls directly.

CSA STAR readiness

FedRAMP

APIs that agencies integrate with cross the boundary by design; testing them checks authentication, authorization and tenant isolation where federal data moves.

FedRAMP readiness

GovRAMP & TX-RAMP

Integrations with state systems move sensitive data through APIs; testing them checks authentication and authorization where that data crosses the boundary.

GovRAMP & TX-RAMP readiness

HIPAA

FHIR and HL7 interfaces, EHR and payer integrations, and partner APIs move PHI between systems and need authorization tested record by record.

HIPAA readiness

Privacy: GDPR, CCPA & state laws

APIs carry personal data to partners and apps, and an authorization flaw there can expose records in bulk.

Privacy: GDPR, CCPA & state laws readiness

DORA

EU financial customers usually integrate through your APIs, so authorization, data exposure and abuse of those interfaces are what their vendor-risk teams ask about first.

DORA readiness

Vendor & third-party risk

Tests the API integrations that connect vendors to your systems, where third-party access often reaches further than anyone intended.

Vendor & third-party risk readiness

Getting started

What you get, and what we need from you.

What you get

Technical report — Every finding, the evidence behind it and clear guidance your engineers can act on.
Executive summary — Your risk explained in plain language for leadership and the board.
Attestation letter — Signed confirmation of testing to hand your auditors.
Readout call — A walkthrough with the people who tested your systems.
Retest — Confirmation your fixes worked, documented for whoever needs to see it.

What we need from you

A base URL and an environment that mirrors production
Credentials or tokens for each role and, where tenancy matters, two separate accounts
An OpenAPI or GraphQL schema, or a traffic capture, if you have one
One named contact for the duration of the test

Missing something on this list? Bring it to the call — we scope around what you have.

Others in Applications