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 · 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.

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

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

Auditors evaluating monitoring (CC4.1) and system operations (CC7.1) commonly look for independent security testing of the application in scope, and enterprise buyers usually ask for a recent pentest summary alongside the SOC 2 report.

SOC 2 readiness

ISO 27001

Control 8.29 calls for security testing in development and acceptance; an independent application test is how many organizations evidence it for customer-facing systems.

ISO 27001 readiness

PCI DSS

Requirement 11.4.1 defines penetration testing to include the application layer, and e-commerce checkouts and payment applications are exactly where attackers aim.

PCI DSS readiness

HITRUST

Patient portals and clinical applications are often the in-scope systems customers care most about, and application testing supports the related requirement statements.

HITRUST readiness

SOC 1

When customers reach the financial application through the web, testing it supports the objective that access is restricted to authorized users.

SOC 1 readiness

ISO 42001

The application wrapped around your model is part of the AI system, and its weaknesses are AI-system risks your impact and risk assessments should account for.

ISO 42001 readiness

FedRAMP

The customer-facing application is usually the largest part of the attack surface inside the boundary, and the place agency reviewers look hardest.

FedRAMP readiness

GovRAMP & TX-RAMP

Public-facing portals for residents and staff are the most exposed part of most state cloud services and the first thing a 3PAO or agency reviewer probes.

GovRAMP & TX-RAMP readiness

HIPAA

Patient portals, provider dashboards and scheduling apps put ePHI one broken access check away from the wrong person.

HIPAA readiness

NIST CSF

Platform and data security outcomes for the applications that hold your customers’ data are only proven by testing them.

NIST CSF readiness

Privacy: GDPR, CCPA & state laws

GDPR Article 32 and the CCPA’s reasonable-security duty both depend on applications that don’t leak personal data through broken access control.

Privacy: GDPR, CCPA & state laws readiness

Risk assessment

Validates the risks in the applications that hold customer data and gives auditors independent evidence that the related controls work.

Risk assessment readiness

Security program

Tests the applications your customers depend on and backs your secure development policy with real evidence.

Security program readiness

M&A due diligence

For software and SaaS targets, testing the product itself shows whether the asset you are paying for carries security flaws your new customers will eventually find.

M&A due diligence 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 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