Pillar 03

Web & API Testing

Your website and its interfaces are the part of your business permanently exposed to everyone on earth. They are tested accordingly.

Web applications fail in ways scanners rarely catch, because the interesting flaws are about logic and authorisation rather than syntax. A scanner cannot know that customer 41 should not be able to read invoice 82. That judgement has to be applied by hand.

Web & API Testing — Reed Sentinel

What we check

What we check

Injection

SQL, command, template and header injection across every parameter that reaches an interpreter.

Broken access control

Whether one authenticated user can reach another user’s data by changing a value — the single most common serious flaw we find.

Authentication and sessions

Login handling, session fixation and expiry, password reset flows, multi-factor enrolment, and the account-recovery path attackers actually use.

API surface

Undocumented and deprecated endpoints, unauthenticated methods, rate limiting, and whether the API enforces what the interface implies.

Transport and headers

TLS configuration and certificate handling, tested against current standards rather than a pass mark from three years ago.

Platform and plugins

CMS versions, plugin vulnerabilities, exposed admin panels, directory listing and backup files left in web-accessible paths.

How it works

How it works

01

Scope and authorisation

Which domains, environments and accounts are in scope, plus test credentials and a rate limit agreed in writing.

02

Map the surface

Full enumeration of routes, parameters and endpoints, including what is reachable but undocumented.

03

Test by hand

Automated coverage first, then manual work on logic and authorisation, which is where the serious findings live.

04

Report and re-test

Reproduction steps for every finding, so your developers can confirm the fix themselves before we verify it.

What we usually find

What we usually find

Web and API findings cluster around authorisation rather than exotic exploitation. The serious ones are rarely subtle in hindsight — they are simply things no automated tool can reason about, because they require knowing what the application is supposed to permit.

One customer able to read another’s data

Change an identifier in a URL or request body and receive a record belonging to somebody else. This is the single most common serious flaw we find, and no scanner reliably detects it because only a human knows who should have seen what.

Endpoints that exist but are not linked

Debug routes, staging interfaces, old API versions and administrative functions still live and reachable, simply absent from the navigation. Obscurity is not access control.

Authentication without rate limiting

Login, password reset and one-time-pin endpoints that accept unlimited attempts, turning a weak password policy into an open door and a four-digit PIN into a formality.

Errors that explain the system

Verbose stack traces and database errors returned to the browser, handing an attacker the framework, the schema and often the query itself.

What you get

What you receive

Reproduction steps for every finding

Written so your developers can confirm the issue and the fix themselves, without needing us in the room.

Findings mapped to real impact

What each flaw would let someone actually do to your business, stated before the technical detail.

Remediation with specifics

The change required, at the layer it belongs — not “sanitise inputs” as a general instruction.

A verified re-test

Once fixed, each finding is re-attempted using the original steps and the report reissued.

You will know the price before you commit.

A twenty-minute call is enough to agree what gets checked and what it costs. Nothing on your systems is touched until you have signed to say we may.

Book a free callarrow_forward