Applications

Web application pentest

A hands-on test of your web application — how it authenticates people, what it lets each of them reach and where its logic can be bent — carried out the way a real attacker would, then written up so your engineers can fix what we find.

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 · 15 services · one team

In-house

Web app

API

SaaS

Mobile

Client-side

External

Internal

Segment test

Wireless

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.

Scanners find the flaws that look the same everywhere. The ones that matter in your application usually don’t: a role that can read another customer’s records, a checkout step that can be replayed, an admin function that was only ever hidden by the menu. Those take a person who understands what your application is for.

We test every role you give us, from anonymous visitor to administrator, and we test them against each other. When we find something, we prove it — with the request, the response and the data it exposed — so nobody has to take our word for it.

OWASP Web Security Testing Guide OWASP Top 10 OWASP ASVS PTES

What we test

Authentication, password reset, multi-factor and session handling
Access control between roles, between users and between tenants
Injection of every kind the stack allows — SQL, command, template and cross-site scripting
Business logic: pricing, quantities, workflow order, approval steps and anything that can be replayed
File upload, parsing and download paths
Server-side request forgery and anywhere your application fetches a URL
Secrets, error handling, security headers and misconfiguration
Third-party components carrying known, exploitable issues

How it runs

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

Typically one to two weeks of testing for a mid-sized application, confirmed at scoping.

Scope and authorize

We agree what is in scope, what is off limits, and when we test. You get written authorization and named testers before anything starts.

Map the application

We walk the whole application as each role you have given us, so testing covers what the interface exposes and what it does not.

Test by hand

Tooling handles the repetitive sweeps. People decide what to chase, how to chain it and what it would actually cost you.

Prove the impact

Each finding is validated and evidenced, and where issues combine into something worse, we show that too — no false alarms forwarded to your team.

Report, readout and retest

You get the technical report, an executive summary, a walkthrough with the testers, and a retest to confirm your fixes worked.

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 role reading or changing another role’s data

Endpoints that enforce nothing because the UI never offers the button

Checkout, quota or approval steps that can be replayed or reordered

Stored cross-site scripting that fires in an administrator’s browser

Keys and internal URLs shipped in the client-side bundle

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 test environment that mirrors production, or written approval to test production
Working credentials for every role — two accounts per role where isolation matters
Any API documentation you already have (helpful, never required)
One named contact we can reach while testing is live

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

Others in Applications