Service · Software testing and QA

Penetration testing

Picture a supplier offering its customers a B2B portal for downloading drawings, tracking orders and filing complaints. The portal has grown over the years, several contractors have worked on it, and each company sees only its own data. That, at least, is the intention. What if a customer bumps the order number in the address bar by one and receives a competitor's drawing? Authorisation flaws of this kind are among the most common and most damaging, and no automated scanner reliably spots them. A penetration test is a controlled attack commissioned in writing by the system owner. We work remotely within an agreed scope and time window, avoid anything destructive, and deliver a report showing what we found, how serious it is and how to fix it.

Written consent
from the system owner up front
OWASP
WSTG and ASVS as the basis
Manual
logic and permission flaws
Retest
confirms the fixes

Everything this covers

We agree the scope together. For web applications and their surroundings, these are the usual focal points.

Settle the details with an engineer

Scope and test type

Black box with no prior knowledge, grey box with test accounts for each role, or white box with access to the code. For most applications we recommend grey box, as it finds the most for the same budget.

Permissions

Horizontal and vertical privilege escalation: can a customer see others' data, can a basic user reach admin functions, do disabled accounts still work?

Authentication and sessions

Password rules, second factor, password reset, session lifetime and single sign-on via Entra ID or ID Austria where used.

Inputs and uploads

Injection into database and operating system, cross-site scripting, crafted files and parameters that alter prices, quantities or customer numbers.

APIs and apps

Whether the API itself enforces who may do what, whether it limits request rates and whether the app stores secret keys on the device.

Surroundings

Reachable admin consoles, outdated components, missing security headers, open cloud storage and forgotten test systems.

Report and retest

Every finding with a CVSS score, evidence and a suggested fix, a management summary, and confirmation once issues are resolved.

Our working method

Nothing starts without signed authorisation. You receive our IP addresses beforehand so your team can recognise us in the logs.

01

Scoping and consent

Scope, test type, time window, emergency contacts and the owner's authorisation, plus the host's where systems are hosted externally.

02

Testing

Mapping the attack surface and manual probing with tools such as Burp Suite, with no denial of service and no changes to real data.

03

Report

Delivered encrypted to named recipients and walked through over video with developers and management.

04

Retest

Checking the fixes and issuing a final confirmation for your records.

A vulnerability scan is not a penetration test. Scanners find known holes in outdated software and missing settings, which is valuable. But they have no idea that customer A must never see customer B's data. Those logic errors are what make the difference, and only someone examining the application by hand, as an attacker would, will find them.

Frequently asked questions

Because attacking someone else's systems without permission is a criminal offence, however well meant. Consent must come from the real owner. If the system runs with a host or service provider, we obtain their agreement as well.

We steer clear of destructive techniques, but some residual risk comes with any test. That is why we prefer a test environment. On live systems we only work within the agreed window and with a current backup.

No. You receive a report covering scope, methodology and findings, and a confirmation after the retest. That normally satisfies customers, insurers and ISO 27001 auditors.

At least annually and after major changes, such as a new interface, a new login method or a move to the cloud. For essential and important entities under NIS2, it can be one element of the required risk management.

Like a master key. It explains how to get in. Keep the circle of recipients small and do not put it in widely shared folders until every finding has been fixed.

Let us test the security of your application

Describe the application, its user roles and who owns it. We will suggest scope, test type and a schedule.

Availability
Monday to Friday, 8:00-17:00 Austrian time (CET/CEST), reply within one working day
Meetings
By video on Microsoft Teams or Google Meet

We only use cookies that are technically required: to run the website and to remember the location you picked. There are no advertising or tracking cookies. Details are in the privacy notice.