Web Application Pentest (WEB VAPT)

A web application pentest is a person reasoning about what your application is for and then abusing it, while a vulnerability scan compares the application against a database of known conditions. The two answer different questions and one does not replace the other.

A scanner can tell you a header is missing or a library is old. It cannot tell you that changing an identifier in a request returns another customer's invoice, or that an approval step can be skipped by posting the final state directly. Authorisation and business logic flaws, the ones that cost money, have no signature for a scanner to match.

We still run automated tooling for coverage during vulnerability analysis, then test by hand everything it surfaced and everything it cannot reason about. Nothing in the report rests on tool output alone.

A web application pentest can run from any of the three starting positions, and for almost every application grey box with credentials for every role is the correct choice. What we are told before we start changes what the test can prove.

Black box

We start with nothing but the name of the target, the way a real attacker does. Realism is highest and coverage is lowest. Against an authenticated application most of the budget goes on reaching the part worth testing, and a horizontal authorisation flaw cannot be found at all.

Grey box

We start with the access a legitimate user or partner would have, which means a login for each role. This is the honest default. It is realistic enough and it reaches the logic flaws a black box run never gets to.

White box

We also receive documentation, configuration and where relevant source code. Coverage is highest and realism is lowest. It is the right choice when the question is completeness rather than plausibility, and we staff OSWE holders on source-assisted work.

A web application pentest needs working credentials for every role in the application, not one test account. A test performed as a single user cannot detect horizontal authorisation flaws, because there is no second user to reach across to.

In practice that means a login per role, and two users in any role that owns records, so we can prove whether one can read or change the other's data. Object and function level access control is tested per role and per resource, never sampled.

Where roles are withheld we state plainly in the report what was not testable. We do not quietly narrow the scope and report a partial test as a full one.

Most web application pentests take one to three weeks including reporting. The driver is the number of roles and distinct functions, not the page count. A small application with five roles takes longer than a large one with two.

The reason is that authorisation is tested per role and per object, so each additional role multiplies the checks rather than adding a few. Business logic testing scales the same way, with every workflow walked out of order and with the wrong values.

We confirm the timeline at scoping alongside the quote. The retest is a separate, shorter step once your fixes have landed, and it is quoted at the same time.

A web application pentest runs in production where it is safe to do so, because staging routinely differs in exactly the configuration that turns out to matter. Where production genuinely cannot be touched we say so at scoping, rather than testing a copy and reporting on it as though it were live.

In production

No production change is made without written agreement, and denial of service techniques are excluded by default. The rules of engagement fix the testing hours, the excluded techniques and the deconfliction route before any work starts, so nothing arrives as a surprise.

On staging

Staging is the right place for destructive test cases and for anything that would create real records or trigger real payments. It needs production-equivalent configuration, and where it differs materially the report says so, because a test of a different configuration is a test of a different system.

A web application pentest delivers an executive summary, technical findings with severity, reproduction steps and named owners, MITRE ATT&CK mapping, a prioritised remediation order and, once your fixes land, a retest report.

Every finding is proved, never asserted. If the report says something is exploitable, we exploited it, and the steps are written so your developers can see it themselves. The remediation order reflects real risk rather than raw CVSS, so two mediums that together reach cardholder data are not treated as two mediums.

You also receive a signed attestation of testing for procurement and auditors, and direct access to the tester who wrote the findings.

A web application pentest from us comes with a signed attestation of testing, not a certificate. The attestation states the scope, the dates, the standard applied and the outcome, which is what procurement teams and most auditors actually ask for.

We do not issue anything that implies a guarantee, because no test can support that claim. A test proves what was found in a fixed scope during a fixed window, and an honest document says exactly that.

If a tender asks for a certificate, send the attestation with the report and the retest report. That evidence chain is what the request is really after.

Yes, a web application pentest can and usually should cover the single page application and the API behind it together. A modern front end is a thin client over an API, and testing only the interface leaves the actual authorisation surface untested.

A test driven through the browser exercises the endpoints the interface happens to call. The API side constructs requests by hand, so every constraint the front end enforces is simply absent, and endpoints the interface never uses are reached as well.

We scope the two surfaces explicitly so you know which endpoints were tested directly. Our API pentest service describes how that side is sized.

After a web application pentest report is delivered you get a remediation call with the tester, then a scoped retest of the findings you fixed. The retest is quoted at the start, so it is a scheduled step and not an upsell.

Questions about a finding go to the person who found it. Most findings close faster in one call than in three emails, and the call is where a fix that would be wrong for your architecture gets caught.

The retest report is what turns a finding marked resolved into a finding with evidence behind it. It is the document your regulator or examiner reads for closure, alongside the original report.

A web application pentest should be repeated before a significant release goes live, after any material change to authentication or authorisation, and at least annually for anything internet-facing. If a regulator names an interval, treat it as a floor and not a schedule.

A new role, a new payment flow or a rewritten login are the changes most likely to introduce the flaws that matter, and each is a reason to test the affected area rather than wait for the annual cycle.

We run the same six phases on every engagement so two reports a year apart are comparable, and you can see what changed rather than reading two unrelated documents.

In the UAE a web application pentest is expected under the CBUAE regime for financial institutions, PCI DSS for any environment handling card data, and the ISR published by the Dubai Electronic Security Center for Dubai government entities and their suppliers.

CBUAE

Licensed banks, payment institutions and stored-value facilities must run independent periodic security testing with findings tracked to closure. The engagement produces the scope rationale, findings, owners and retest evidence an examiner asks for.

PCI DSS

Any environment that stores, processes or transmits cardholder data needs testing at defined intervals and after significant change. Scoping decides cost here more than anything else does.

DESC ISR

Dubai government entities and their suppliers must test proportionately to the classification of the information handled. Supplier connections are explicitly in scope, which is the part most organisations forget to include.

Abu Dhabi healthcare falls under ADHICS and federal entities under the UAE IAS, which tenders still call NESA. The same evidence chain serves both.

Our web application pentest follows the OWASP Web Security Testing Guide for test cases and uses the OWASP Application Security Verification Standard as the bar findings are measured against. Both are public, so you can check what was covered rather than trusting a label.

The engagement itself runs in six phases on every job: gathering information, threat modelling, vulnerability analysis, exploitation, post exploitation and reporting. That structure follows PTES and NIST SP 800-115, and it is why two reports a year apart are comparable.

Findings are mapped to MITRE ATT&CK so your detection team can see which techniques were used against the application and whether anything noticed. Severity is defended in the report, not read off a scanner.