Web Application Penetration Testing
What is a web application penetration test?
A web application penetration test is a manual security assessment of a web-based application — anything from a customer portal or SaaS product to an internal business system accessed through a browser. A tester works through the application the way an attacker would, looking for vulnerabilities that could be used to access data, manipulate functionality, or compromise the accounts of users or administrators.
The key word is manual. Automated scanners can find known issues quickly, but they miss logic flaws, broken access controls and the kind of multi-step vulnerabilities that require a human to chain together. A penetration test combines tooling with hands-on testing to find what scanners leave behind.
What we test
Our web application penetration tests follow the OWASP Web Security Testing Guide (WSTG), which is the industry-standard methodology for this type of assessment. In practice, that means we look at:
Authentication and session management - whether login mechanisms can be bypassed, whether sessions expire correctly, whether password reset flows can be abused, and whether multi-factor authentication is implemented in a way that actually holds up.
Access controls - whether users can access data or functionality they shouldn't. This includes testing whether one user can view or modify another user's records, whether admin functions are properly restricted, and whether API endpoints enforce the same controls as the front end.
Injection vulnerabilities - SQL injection, command injection, and similar flaws that allow an attacker to interfere with the application's backend systems or databases.
Cross-site scripting (XSS) - whether an attacker can inject malicious scripts into the application that execute in another user's browser, which can be used to steal session tokens or perform actions on a user's behalf.
Security misconfigurations - default settings left in place, unnecessary features enabled, error messages that reveal internal system details, and missing security headers that browsers rely on for protection.
Business logic flaws - vulnerabilities specific to how your application works, such as the ability to skip steps in a checkout process, manipulate prices, or access features before paying for them. These are the issues automated tools almost never find.
Sensitive data exposure - whether the application handles personal information, credentials or payment data in a way that could expose it in transit, in logs, or through the API responses it sends back to the browser.
Who needs a web application penetration test?
Any business that runs a web application holding customer data, financial information or login credentials has a reasonable case for regular testing. In practice, we see two common drivers.
Compliance requirements. ISO 27001 expects organisations to assess the security of their applications as part of their information security management programme. PCI DSS requires penetration testing for any system that handles or connects to cardholder data. If your application takes payments, stores card data, or sits within scope of a PCI assessment, a web application penetration test is not optional. SOC 2 auditors will also typically want to see evidence of application security testing.
Proactive testing before something goes wrong. A lot of Auckland businesses come to us after building or significantly updating a web application and wanting to know whether it is actually secure before it goes into production or before a larger customer asks the question. Finding a broken access control issue in a test is considerably less damaging than finding it because a customer reported it or because it appeared in a breach notification.
What the process looks like
We start with a scoping call to understand the application, the tech stack, and what you want us to focus on. For most web application tests we work in a grey-box model — we have user accounts and some context about how the application is built, which lets us test more thoroughly in the time available than a completely blind approach would allow.
Testing typically runs over two to five days depending on the size and complexity of the application. We work in a test environment where possible, or coordinate timing with you if testing needs to occur against production.
At the end of the engagement you receive a written report with two audiences in mind: a management summary that explains what we found and what it means in plain language, and a technical section that gives your developers everything they need to reproduce and fix each issue. Findings are rated by severity so you can prioritise what to address first.
We are also available after delivery to walk through the findings with your team and answer questions about remediation.
Retesting
Once your team has addressed the findings, we offer a retest to confirm the fixes hold up. This is particularly useful when you need to demonstrate to a customer, auditor or insurer that identified vulnerabilities have been resolved.
Based in Auckland, working across New Zealand
We work with businesses across Auckland and New Zealand. Most web application testing is conducted remotely, which keeps costs down and means we can work with clients anywhere in the country.