Testing web applications
Front end, backend and the interfaces behind them, tested by hand along the OWASP Web Security Testing Guide. With reproduction steps and a retest.
Front end, backend and everything in between
A web penetration test is a commissioned attempt to break into a web application. What gets tested is the application itself, the interfaces behind it and the services both run on, along the same routes an attacker would take. Other names for the same thing: web pentest, web application penetration testing, pentest for web applications and APIs.
A web pentest examines the application, the services behind it and the ways the two speak to each other. Front end, backend, database and interfaces, because a gap rarely sits where the screen suggests.
We work by hand and with tools. The automated run finds the known and delivers the surface; the findings that matter come about afterwards, manually. The frame is the OWASP Web Security Testing Guide, the BSI requirements and OSSTMM.
Whether we see the source code is your decision. Without it we test like an external attacker; with it we get deeper and faster. For your own developments the second route is usually the more economical one.
An input that becomes a query
A search field in a shop takes whatever somebody types and passes it on to the database. If instead of a product name it holds a quote mark and an always-true condition, the database answers with everything it has.
That is the classic, and it still occurs, usually at the one place somebody added later: a filter, an export, a search across two tables. The frame for it is the OWASP Top 10 and the ASVS, which also lets you evidence what depth of testing was reached.
What a web pentest covers
The OWASP Web Security Testing Guide divides testing into eleven categories. Here they stand in five groups, so that the list stays readable; in the report every finding is mapped to its category. What weighs heavier in your case depends on the application.
Authentication, session, permission
Whether a session can be taken over, whether a user reaches somebody else's data, whether an administrative function is reachable without the matching role. Plus password rules, second factor, and the question of how many attempts a login allows. This is where the findings with the largest consequences sit.
Input and data
SQL and NoSQL injection, cross site scripting in all three forms, attacks on XML, path traversal, file uploads, deserialisation, server side request forgery. Everything that turns an input into an instruction, plus error messages that give away more than they need to.
Application logic and client
CSRF and clickjacking, the cases in which a process can be run through in an order nobody intended, and the client-side half: DOM-based attacks, CORS rules, messages between windows. For this class there is no scanner.
Configuration and deployment
Server and framework configuration, security headers, directory listings, forgotten management interfaces, backup files and test environments that shipped along with it. The most common finding that has nothing to do with the code.
Cryptography and components
Transport encryption and its settings, the handling of secrets and session attributes, outdated methods. Plus the patch state of the libraries and frameworks in use, because a known gap in a dependency counts exactly as much as one of your own.
Harmless alone, a takeover when chained
Three findings rated low can together lead to code execution on the server. An upload without a type check, a path that can be manipulated, and an error message that gives away the storage location: taken on its own, each of those sits far down the list.
So our tests do not end with the finding but with the attempt to use it further. The report then contains the chain with its steps, and the rating follows what was reachable in the end.
A scanner cannot do that. It rates every find on its own, and the connection between them is exactly the part a person sits at the test for.
How a web pentest works
Five to ten days, depending on scope and the number of roles.
Understand
The application gets used first: which functions exist, which roles, where data arises. Without that step you test forms rather than processes.
Record the entry points
Every parameter, every upload, every interface. In a modern application the larger part sits in the API behind it.
Test and chain
The classes from the OWASP Web Security Testing Guide, each reproduced and confirmed by hand. Then the attempt to join the finds together.
Report
Every finding with reproduction steps, a rating against the agreed scheme, and a route to a fix that suits the application.
Retest
After the fixes we examine the same findings again. Only that turns the report into evidence.
From bespoke development to the shop
Bespoke applications and portals, content management systems such as Drupal, TYPO3 or WordPress, shop systems, progressive web apps, and the interfaces behind them. With off-the-shelf software the emphasis shifts to configuration, extensions and patch state, because the core gets tested by many and your adaptations by nobody.
If the interface is the larger part, we test it in the same engagement.
A report your team can work from.
Every finding comes placed: with risk, effort and the route to a fix.
Management summary
The position on one page, readable for management and the board.
Technical findings
Every finding with a unique finding ID, evidence and reproduction steps.
Risk rating to BSI
A traceable rating of every find against a recognised scheme.
Prioritised recommendations
Concrete recommendations in the order in which they take effect.
Closing meeting
On request, a joint walk-through of the results with your teams.
Retest
On request, a re-examination of the fixed weaknesses, with confirmation of the state.
What we need, and what is not included
From you we need the addresses of the application under test, one user account per role, a contact for the duration of the test and a written release. If the application sits with a hosting provider, we obtain their permission together with you. If there is a test environment we test there; otherwise in production with agreed restrictions.
Not included are attacks on people and on availability. Phishing simulations and social engineering are services of their own, and we do not carry out load or denial of service tests. The server under the application belongs in the external penetration test, and an interface that stands on its own in the API test. A source code review is not a penetration test but a service of its own that combines well with one.
Common questions about web pentests
A deliberate attempt to break into a web application, under engagement and within agreed limits. What gets tested is the application, the interfaces and the services behind them, along the same routes an attacker would take.
The result is a list of findings with reproduction steps and a rating of what was reachable with them. Certified testers carry out the work, and the findings come about by hand.
Bespoke applications and portals, progressive web apps, interfaces such as REST and GraphQL, content management systems such as Drupal, TYPO3 or WordPress, shop systems and site builders.
With off-the-shelf software the emphasis shifts: the core gets tested by many; your extensions, your configuration and your patch state by nobody. That is where the findings sit.
The classes from the OWASP Web Security Testing Guide. Most commonly: SQL and NoSQL injection, cross site scripting in all three forms, cross site request forgery, faults in authentication and authorisation, path traversal, unchecked file uploads, deserialisation and server side request forgery.
The finding with the largest consequences is usually the permission: a logged-in user who reaches data that is none of their business.
Before a new application goes live, after larger changes to functions or architecture, after a security incident, and after that on a recurring basis once a year.
For applications released frequently, a smaller test per release is more effective than one large one a year. For evidence under NIS2 or towards customers, it is the recurring rhythm that counts.
In six steps. Getting to know it: objectives, scope and limits are fixed, along with the question of which system is tested how. Reconnaissance: the structure, the technology in use and the functions are recorded. Testing: the entry points are attacked deliberately, findings confirmed and chained together.
Documentation: every finding with reproduction steps, a rating and a route to a fix. Presentation: a walk-through for the team and for management, with room for questions. Retest: after the fixes we examine the same findings again.
By demonstrable practice. In the web field, OSCP and OSWE are the certifications with a practical examination: whoever holds one had to find and exploit weaknesses under time pressure rather than tick boxes.
Plus the questions a proposal should answer: is the testing manual or is a scanner delivered, is there a review of the report, is a retest included, and are references from comparable environments named.
They answer a question that otherwise only gets answered when something goes wrong: what is actually reachable with this application. A scanner delivers a list of possible problems; a test shows which of them together lead to access.
Concretely, three things come out of it: an order of work for fixing instead of a list, evidence towards customers and regulators, and for your development team the finding along with the route to it, from which the same class of fault can be avoided in future.
If there is a complete test environment, there. Otherwise in production with agreed restrictions: no mass mail, no orders, no load tests. Whatever we change, we log and undo.
Yes, and ideally one per role. Without authentication only what is public anyway can be tested, and the findings on permissions only arise in the comparison between two accounts.
In a modern application it is the larger part, and we test it in the same engagement when front end and backend belong together. If the interface stands on its own, for instance as a product for partners, a separate API test is the better route.
The effort follows the number of functions, roles and interfaces. A smaller application is around five days; a portal with several tenants and interfaces is considerably more.
A thirty minute conversation in which you show us the application is enough for a first assessment. The penetration testing overview page also carries a calculator for a guide figure.
Certifications and memberships.
Talk to us.
A first conversation usually takes 30 minutes. We look at where you stand and tell you frankly whether we are the right partner.