Web Penetration Testing

Web applications are the primary interface to the outside world and are therefore a popular target for attacks. We simulate real-world attacks on your applications and APIs to identify which vulnerabilities can actually be exploited, rather than simply providing a list of theoretical vulnerabilities.

Request a test Process, methodology and scope of the report

Web Application
Pentesting

Offensive Security

Target

Web applications and APIs

Basis

OWASP Top 10 and WSTG

Perspective

from unauthenticated to privileged

Prerequisite

Test system and test accounts per role

When a web test is due

A new application, portal or online shop is going live.
A client requests a test report for the application prior to approval.
Following a major release, particularly if authentication or authorisation logic has been modified.
The application processes personal data or payment-related data.
An external agency has carried out the development and you wish to have the status independently verified.
An audit in accordance with ISO 27001, BSI Basic Protection or NIS2 requires evidence for critical applications.
The application has been migrated from a monolithic to a microservices architecture with many new APIs.

What exactly is audited

Web application

The classic assessment: login, forms, business logic, session handling and the question of what users can achieve beyond their intended capabilities.

API

REST or GraphQL interfaces used by the front-end, but which often allow more than the interface suggests. A common finding: endpoints that are not linked to in the frontend but are accessible without protection.

Single-page applications

Applications in which the majority of the logic runs in the browser. We check whether security-related decisions are actually made on the server side or can be circumvented on the client side.

Mobile Backend

If a mobile app is connected to the same server logic, we test the interface independently of the app itself, as it is often subject to less rigorous testing than the web interface.

What we test

Vulnerability analysis – systematic assessment against the OWASP Top 10 and WSTG.
Authentication and session handling – login processes, token management, password and recovery functions.
Permissions and role logic – whether a user can access other users’ data or functions, both horizontally and vertically.
Input processing – how the application handles unexpected or manipulated inputs.
APIs – endpoints that are not visible in the front-end but respond openly, including rate limiting and authorisation per endpoint.
Business logic – processes that function technically correctly but can be exploited, such as discount logic or ordering processes.
Configuration – security headers, error messages, exposed debug or admin areas.
Exploitation – targeted assessment to determine whether a vulnerability is practically exploitable or exists only in theory.

What we frequently see

Findings	Why it matters
SQL injection	Injecting code into database queries, often granting access to the entire database.
Cross-site scripting	Scripts executed in other users’ browsers, potentially leading to account takeover.
Insecure direct object reference (IDOR)	Third-party data records can be accessed via a modified ID in the query; one of the most common vulnerabilities of all.
Insecure authentication	Weak password policies, lack of rate limiting, insecure session handling.
Server-Side Request Forgery	The application can be tricked into making requests to internal systems that would otherwise be inaccessible from outside.
Misconfigured APIs	Exposed endpoints without authorisation checks, often carried over from the development stage.
Vulnerable dependencies	Outdated libraries with known, publicly documented vulnerabilities.
Faulty business logic	Technically valid processes that can be manipulated for personal gain.

“Every line of code can be a point of entry if security isn’t taken into account.”

How a test works

Scoping

We define the scope of testing, roles, test accounts and time slots, including an agreement on whether to use the production or test system.

Reconnaissance

Application mapping: functions, endpoints, technologies used and attack surface.

Vulnerability analysis

Systematic testing in accordance with the OWASP WSTG, supplemented by a manual analysis of the business logic that is not covered by automated scanners.

Exploitation

A controlled test to determine whether a discovery is of practical use, without altering or deleting real data.

Report and final discussion

Delivery of the findings, including risk classification, evidence and recommendations for each issue, followed by a joint discussion with your development team.

Test against production or test system

Test system

The preferred option. We carry out testing at full intensity without having to take into account live user data or ongoing business operations. This requires the test system to behave functionally in the same way as the production environment.

Production system

This is possible if no comparable test system exists. We will then agree in advance which actions are excluded – such as making actual payments or sending real emails – and avoid destructive assessments of production data.

We will openly discuss both of these points with you during the scoping meeting: A test against an outdated test system that does not reflect the production state only provides insight into the test system itself.

What you provide

Access to the application, ideally on a test system.
Test accounts for each authorisation level to be tested, so that authorisation checks can be carried out.
A brief overview of the application’s functions, should the application not be self-explanatory.
A technical contact from the development team to answer any queries.
For APIs, the relevant documentation or interface description, where available.

What you’ll take away from this

Every finding comes with a risk rating, a clear step-by-step guide to reproducing the issue, and a specific Recommendation, so your development team can get started straight away without having to reproduce the issue themselves first. We also explain business logic findings in context, as – unlike technical vulnerabilities – they cannot always be clearly assigned to a standard category.