Broken access control
Users can reach data or functions they aren’t entitled to – for example, other customers’ orders by changing an ID (IDOR) or admin functions without admin rights. Broken access control tops the OWASP Top 10.
Penetration Testing
Web Application Penetration Testing
Online shops · Portals · Online banking · SaaS
Your web application is accessible around the clock – including to attackers. With web application penetration testing, we manually examine online shops, customer portals, online banking platforms, and SaaS applications for exploitable vulnerabilities – from access control and injection to business logic.
- Fixed price after scoping
- Free retest
- Quote within 24 hours
Definition
What is web application penetration testing?
Web application penetration testing – also known as a web app pentest – is a controlled security assessment in which we attack your application the way a real attacker would: through the browser, through manipulated requests, and through the interfaces running in the background. The goal is to find exploitable vulnerabilities, prove their actual impact, and show you concrete ways to fix them.
For many companies, web applications are the digital storefront – and at the same time the gateway to sensitive data: customer accounts, orders, payment information, contracts, or health data. Because they are publicly accessible, they are constantly probed by automated tools. Often, a single missing authorization check is enough to read other customers’ data.
Automated scanners detect known patterns such as outdated libraries or missing security headers. But many of the most dangerous flaws lie in your application’s logic: a voucher that can be redeemed any number of times, a shopping cart that accepts negative quantities, or an approval step that can be skipped. Only someone who understands the application will find flaws like these – which is why our penetration testers rely primarily on manual testing.
A web pentest also provides evidence for compliance and customer requirements: for the regular review of security measures under Art. 32 GDPR, for ISO/IEC 27001:2022 (Annex A, controls 8.8 and 8.29), for PCI DSS 4.0.1 when you accept card payments, and for security requirements in tenders and supplier assessments.
Our approach
How we test your web application
We follow the OWASP Web Security Testing Guide (WSTG) and the OWASP Application Security Verification Standard (ASVS) and supplement both with application-specific test cases. Before we modify the first request, we make sure we understand your application: Which roles exist? Which data needs protection? Which processes must not be abused under any circumstances?
We then test the functionality from the perspective of every agreed role – without logging in, with a customer account, with extended employee privileges, and with administrator rights. Using an intercepting proxy, we analyze and manipulate the traffic between browser and server, test inputs for injection, examine sessions, tokens, and file uploads, and try to break through authorization boundaries both horizontally and vertically.
We verify every finding manually and, where it makes sense, back it up with a controlled proof of concept. That way, your team sees exactly what an attacker could achieve – and doesn’t waste time on false positives.
Common vulnerabilities
Web application vulnerabilities
Injection
Unvalidated input is executed as part of a command or database query. Through SQL, command, or template injection, attackers read out databases, alter records, or execute code on the server.
Cross-site scripting (XSS)
Injected JavaScript runs in other users’ browsers, hijacks their sessions, alters content, or triggers actions on their behalf.
Weak authentication
Missing protection against brute-force and credential stuffing attacks, two-factor authentication that can be bypassed, or password reset links that can be guessed or reused.
Insecure session management
Predictable session IDs, missing cookie attributes, or sessions that remain valid after logout enable session hijacking and account takeovers.
Business logic flaws
Prices, quantities, or discounts can be manipulated, process steps skipped, or limits bypassed via race conditions – all with technically “valid” requests.
Server-side request forgery (SSRF)
The application fetches URLs supplied from outside, for example when importing images. Attackers can use this to reach internal systems or cloud metadata services that hold stored credentials.
Misconfiguration & outdated components
Exposed admin interfaces, debug modes, verbose error messages, or plugins with known vulnerabilities – a common entry point, especially in shop systems and CMSs.
Testing focus
Every web application has its own risks
An online shop is attacked differently than a banking portal. We tailor test cases and depth of testing to your application.
Retail
Online shops & e-commerce
For online shop security, what matters most are the shopping cart, checkout, and customer account – wherever money and personal data flow.
- Price, quantity, and voucher manipulation
- Payment integration and order status
- Embedded scripts on payment pages (PCI DSS 4.0.1, Req. 6.4.3)
Finance
Online banking & financial portals
Here, the integrity of every transaction and protection against account takeover are what count.
- Strong customer authentication and transaction approval
- Manipulation of amounts, payees, and limits
- Session security and fraud scenarios
Platforms
Portals & SaaS applications
Customer, partner, and employee portals as well as SaaS front ends serve many users – often multiple tenants on a single platform.
- Tenant isolation and role models
- Single sign-on with SAML and OpenID Connect
- File uploads, exports, and integrations
Process
How your web pentest works
From scoping to retest – clearly planned and closely coordinated with your team. The process follows our proven approach to penetration testing, supplemented by web-specific steps.
-
01
Scoping
We clarify the application, environment, roles, and particularly critical functions. Within 24 hours (on business days), you receive a fixed-price quote.
-
02
Preparation
You provide test accounts for all relevant roles and name a contact person. Together, we define the testing period, off-limits areas, and how to handle your web application firewall.
-
03
Analysis & mapping
We map functions, parameters, roles, and data flows and derive test cases from them – including abuse scenarios for your business processes.
-
04
Manual testing
We test based on the OWASP WSTG, verify every finding manually, and use controlled proofs of concept to show what an attacker could achieve. We report critical vulnerabilities immediately – during the test, by phone or email to the agreed contact person.
-
05
Report & debrief
You receive an executive summary, technical findings with CVSS ratings, and remediation recommendations – explained in a debrief with your development team on request.
-
06
Retest & test certificate
We retest fixed vulnerabilities free of charge. With the test certificate, you can prove to customers, partners, and auditors that the test was carried out.
Reporting
A report for management and development
The report addresses two audiences. In just a few pages, the executive summary shows senior management where the application’s security stands and where action is needed. The technical section gives your development team everything it needs to reproduce and fix each vulnerability.
- Executive summary with an overall rating and the most important areas for action
- Findings with evidence such as requests, responses, and screenshots
- Risk rating using CVSS and mapping to the OWASP categories
- Concrete remediation recommendations for development and operations
- Free retest of fixed vulnerabilities
- Test certificate upon completion of the test
How secure is your web application, really?
Tell us briefly about your application – after scoping, you’ll receive a fixed-price quote within 24 hours.
FAQ
Frequently asked questions about web application penetration testing
Didn’t find your question? Call us at +49 2932 465265-0 or email info@rootsektor.de.
How much does a web application penetration test cost?
The effort depends on the range of functionality, the number of user roles, the complexity of the business processes, and the testing perspective. Roles carry particular weight: permissions have to be tested against each other across all roles – both horizontally and vertically. After a short scoping session, you receive a binding fixed-price quote within 24 hours (on business days) – with the free retest already included.
Do you test in production or in a test environment?
Both are possible. Ideally, we use a staging environment that technically mirrors production – there we can run in-depth tests without touching real customer data. If we test in production, we agree on time windows, avoid destructive tests, and work exclusively with test accounts and test data.
Black box, gray box, or white box – what do you recommend?
For most web applications, we recommend a gray-box test with test accounts for each role. This lets us use the available time to also test the areas behind the login – where access control, business logic, and sensitive data come together. A black-box test shows what an anonymous attacker can achieve from the outside; with a white-box test, we also get insight into the source code – ideal in combination with a code review.
When should a web application be tested?
Before go-live at the latest, then at least once a year and after significant changes – such as a new checkout or payment process, a new login or SSO integration, a framework change, or a move to a different hosting environment. If you deploy frequently, you should build security testing into your development process and commission targeted tests of individual changes.
Which standards do you follow?
We follow the OWASP Web Security Testing Guide, the Application Security Verification Standard (ASVS), and the OWASP Top 10. The organizational framework is provided by the penetration testing guideline of the BSI (Germany’s Federal Office for Information Security). We rate every vulnerability using CVSS so you can prioritize findings consistently.
Isn’t a web application firewall enough?
A web application firewall blocks many known attack patterns, but it doesn’t fix vulnerabilities in your application. Flaws in access control or business logic consist of entirely legitimate requests and usually pass through a WAF unhindered; on top of that, filter rules can often be bypassed. That’s why, on request, we test both with and without the WAF – so you can see how secure the application itself is.
What do you need from us for the test?
Usually the application’s URLs, test accounts for all relevant roles, a contact person, and the agreed testing window. For white-box tests, we also need source code or architecture documents. On request, we sign a non-disclosure agreement before any sensitive documents are exchanged.
Related pages
Have your web application tested
Tell us about your application, the scope, and your preferred dates. We’ll agree on the scope with you and send you a fixed-price quote within 24 hours of scoping – for companies in Germany and internationally.