Web Application Pentest

What a web application pentest covers

A web application pentest is the systematic security assessment of a web application within a clearly defined scope. The goal: find as many vulnerabilities as possible, verify that they are exploitable and document them so your team can fix them efficiently. For how pentesting differs from other assessment types, see our overview of penetration testing across the DACH region.

The decisive word is manual. We do use automated tools where they help, but they supplement and never replace manual analysis. A scanner detects known vulnerabilities based on patterns. It does not understand what your application actually does: which role is allowed to see which data, which workflows can be abused against their business rules and which functions are truly critical. That is exactly where the vulnerabilities with the greatest damage potential live, and exactly where we focus.

Every assessment is tailored to your application, with or without authentication, depending on requirements and risk profile.

What we test

The exact scope is tailored to your application during scoping. The core areas are the same in every web application pentest:

• OWASP Top 10 and beyond: the best-known vulnerability classes as a baseline, extended with attacks that no checklist covers.
• Authentication & session management: login, registration, password reset, session handling and permission handling, the critical functions of every application.
• Authorisation & IDOR: access control across roles and objects. Can user A read or modify user B's data? Can a regular user reach admin functions?
• Business logic flaws: errors in the application flow that can be abused against its business rules. No automated tool finds this class, because it requires understanding what the application is for.
• APIs (REST & GraphQL): interfaces and data flows, from authentication and authorisation to injection and excessive data exposure.
• Injection classes: SQL injection, cross-site scripting (XSS), command injection and related attacks against every place where your application processes input.

When a web application pentest makes sense

The typical occasions for an assessment:

• Before go-live: a new application or a relaunch is going online, and you want to know what an attacker finds before they find it themselves.
• After major changes: new authentication, a new API, a new role model. Every change to critical functions can introduce new vulnerabilities.
• On request: when customers, partners or auditors require a current pentest report.
• As a recurring check: your application keeps evolving, regular tests keep the security level in step with development.

Our methodology: from scoping to retest

A web application pentest with us runs in four steps. You know at every point what is happening and what comes next.

1. Scoping

In a joint kickoff we define which applications, user roles and interfaces are in scope, which environment we test in and in which time window. You get a clear list of prerequisites up front, such as test accounts and required allowlisting, so the test can start without delay.

2. Testing: white, grey or black box

The testing depth depends on the chosen approach:

• White-box: full insight including source code or architecture documentation. Maximum testing depth per testing day.
• Grey-box: test accounts for every relevant role, but no source code. The best trade-off for most applications, because authorisation flaws between roles become visible.
• Black-box: no prior knowledge and no access, from the perspective of an external attacker. Realistic, but with the least testing depth in the same time.

During the test we report critical findings immediately instead of waiting for the final report.

3. Report

We document every finding with reproduction steps, a risk rating and a concrete remediation recommendation. The report works on two levels: technically precise for your development team, clearly summarised for management and auditors.

4. Retest

Once your team has fixed the vulnerabilities, we re-test every finding and update its status in the report. That documents that the gaps are actually closed, not just that they were found.

Web application pentest or red teaming?

A web application pentest is the right approach when you want to secure a specific application. It works through a defined scope and uncovers as many vulnerabilities there as possible.

A red teaming assessment, by contrast, pursues a specific objective across every vector, from technology to social engineering to physical access, and additionally tests how well your defence detects the attack. Red teaming is worthwhile once the fundamental vulnerabilities are already fixed. The web application pentest is the more suitable and more affordable starting point when a single application is the target. The two are not mutually exclusive: many companies start with pentests and expand to red teaming later.

What you get

• Report with reproducible findings: every vulnerability with reproduction steps, documented for both technical teams and management.
• Risk rating per finding: clear severity levels, so your team knows what to fix first.
• Prioritised recommendations: concrete measures sorted by impact and effort.
• Retest: re-verification of the fixed vulnerabilities with an updated report status.

Certified testers, traceable methodology

A pentest is only as good as the person performing it. Our team works with a high certification density (OSCP, OSEP, OSWE, CRTO, CRTO2). Particularly relevant for web applications is the OSWE certification, which requires practical proof of white-box exploitation at the code level.

Our methodology follows established standards such as the OWASP Testing Guide and PTES, so the results are comparable and traceable for auditors. In the initial call we are happy to show you a sample report and explain our approach.

Remote testing from Vienna is the standard, and we work on site as needed, across Austria, Germany and Switzerland, on a clean contractual basis (GDPR data processing agreements or the Swiss DSG).

Frequently asked questions

How long does a web application pentest take?

A typical web application pentest takes one to three weeks, depending on scope: the number of user roles, functions and interfaces. A small application with few roles sits at the lower end, a large platform with several APIs at the upper end. We define the exact effort together during scoping.

What is the difference between a pentest and a vulnerability scan?

A vulnerability scan is automated and detects known vulnerabilities based on signatures, false positives included. A penetration test is performed manually: we verify every vulnerability, chain individual findings into real attack paths and find flaws in authorisation and business logic that no scanner can detect.

Do you test in production or staging?

Both are possible. A staging environment that closely mirrors production is ideal: there we can test at full depth without any risk to running business processes. We test production environments with clear precautions: agreed time windows, dedicated test accounts and no potentially destructive tests.

What access and prerequisites do you need for the test?

For a grey-box test we need test accounts for every relevant user role, the URLs of the target systems and a technical contact for questions. Existing API documentation speeds up the test. A black-box test without any access is also possible, but delivers less testing depth in the same time.

How is the retest handled?

Once your team has fixed the reported vulnerabilities, we re-test every finding and document the result in an updated version of the report. This gives you verifiable evidence for management, customers or auditors that the gaps are actually closed.