Penetration testing
Application pentesting, what many call ethical hacking, analyses your software in depth (web, API and mobile) looking for the flaws that really matter. Not just the technical ones a tool detects, but the business logic and access control ones that only an expert eye finds by testing the application the way an attacker would, with time and patience. Where a scanner sees forms, we see how to skip the payment, read another customer's data or sneak in without permission.
Manual, expert analysis, not just automated: the difference between a list of alerts and a proven flaw.
Why expert
Automated tools find the known and the obvious. But the flaws that really cost money live in your application's logic, in how permissions and steps fit together, and only a person who understands what your software does and attacks it with judgement can see that.
Scope
Anything that is software with its own logic, where the attack goes through the application itself and not through the network. Web, API and mobile share the same idea: break what the application takes for granted. This is what is known as web pentest, API pentest and mobile pentest.
The bulk of the work. Business logic, authentication and access control, injection (SQL injection, XSS) and configuration, following the OWASP Top 10 and going beyond it where needed.
The backend of nearly everything, with its own permission logic. Tokens, limits, endpoint-by-endpoint authorization, with the OWASP API Top 10 as a baseline.
Android and iOS. Reverse engineering, data stored on the device, communications, certificates and the APIs behind them, following the OWASP MASVS standard.
Approach
How much information we ask of you to start changes what we find. There is no better option than another, there is the one that fits what you want to know.
Blind, like an outside attacker with no credentials or information. It measures what breaks from the street.
With a normal user and some context. The usual balance between realism and depth.
With access to the code and the documentation. Maximum depth, ideal before launching something critical.
What it includes
It is not running a tool and forwarding its report. It is expert work on your application, with the proof of each flaw and the path to close it.
From injection or misconfiguration to business logic abuses that only show up by hand.
Web, API and mobile against the reference standards, without stopping at the checklist when the flaw is deeper.
Every finding comes demonstrated and explained, not as a maybe that came out of a tool.
Not just what fails, but how to fix it, in language your developers understand.
When you fix, we test what we found again to confirm it is truly closed.
One executive with the business risk and another technical with the detail to resolve it.
All designed so the report does not end up in a drawer, but in commits that close the hole.
When
You are about to release a new application or a major version and you want to ship without known holes.
Your application handles personal data, health or money, where an access flaw is costly in fines and in trust.
A client, a certification such as ISO 27001 or the ENS, or the PCI DSS standard for payments asks for proof of your software.
You have rewritten a part, integrated a new API or changed the permission model, and that opens new doors.
Method
We agree which applications are in scope and in which mode (black, grey or white), based on what you want to know and how much context you give us.
Tools for the obvious and expert work by hand for the logic and the access, which is where the big stuff is.
Every flaw demonstrated, with its business risk and how to fix it, in language your team understands.
When you fix, we test what we found again to confirm it is closed.
Fits with
An attacker does not tell the application and the network apart: they jump from one to the other. That is why application pentesting complements infrastructure pentesting, which is continuous and measures your network, systems and perimeter exposure. And when reaching the bottom of the software is needed, the source code audit reviews what white box begins to uncover.
And while your team fixes, what is not yet closed does not stay exposed: with Sondriva, our SOC, we watch the attack attempts against your application in real time. The report, moreover, serves as evidence for your ISO 27001, your ENS or the PCI DSS standard for your payment applications: the same work put to use twice.
Questions
A scanner finds the known and the obvious, and hands you a list of maybes. An application pentest adds the human eye: someone who understands what your software does and tries to break its logic, its access control and its permissions. The costliest flaws, like seeing another customer's data or skipping a payment, are almost never caught by a tool, because they are not a coding error but a design one.
It depends on what you want to know. Black box attacks blind, like an outside attacker with no credentials. Grey box starts from a normal user and some context, and is the usual balance between realism and depth. White box adds access to the code and the documentation for maximum coverage. We decide it with you based on the application and the risk you are taking on.
All three. The web is usually the bulk of it, but APIs are the backend of nearly everything and have their own permission logic, and Android and iOS mobile apps add on-device storage, communications and the APIs behind them. We test whatever you have.
Yes, as a baseline. We use the OWASP Top 10 for web, the OWASP API Top 10 for APIs and the OWASP MASVS standard for mobile, but we do not stop at the list: the interesting part is usually in the business logic, which no checklist covers.
Yes. When your team fixes what we found, we test it again to confirm the flaw is truly closed and not just papered over. Finding the flaw is half the work.
The usual and safest approach is to work on a test environment that mirrors the real one, especially if the application handles data or payments. If we need to touch production, we agree it beforehand and do it carefully so as not to affect your operation or your data.
They complement each other. Application pentesting is point-in-time and deep, with a human eye on the logic of each application. Infrastructure pentesting is continuous and measures your network, systems and perimeter exposure. Since an attacker jumps from the application to the network and back, many organisations need both.
Yes. The report and the proof that your fixes work count as evidence for your ISO 27001 or your ENS, and the PCI DSS standard requires security testing of the applications that handle payments. It is the same work put to use to harden the app and to comply.
Shall we talk?
Tell us which application you want to put to the test, web, API or mobile, and we will propose the approach that fits best.
Get in touch