Web application penetration testing for Australian organisations
Your organisation’s web applications and services handle customer data, processes transactions, and expose business logic to the internet. Web application penetration testing determines whether your applications can withstand a targeted attack against their authentication, access controls, input handling, and business logic.
dotSec’s web application penetration tests go beyond automated scanning. Our assessors combine automated discovery with manual exploitation techniques drawing on the OWASP Web Security Testing Guide (WSTG) to identify vulnerabilities that scanners consistently miss, including business logic flaws, chained attack paths, and access control failures. Every finding is validated, assessed for real-world exploitability, and reported with prioritised remediation guidance.
What is web application penetration testing?
A web application penetration test is a controlled security assessment in which an assessor attempts to identify and exploit vulnerabilities in a web application, its APIs, and/or its supporting infrastructure. The assessor works from the perspective of an attacker, testing how the application responds to manipulation of its inputs, authentication mechanisms, session management, access controls, and data handling.
The scope of a web application test generally (influenced by client requirements) extends beyond the visible interface. A modern web application typically includes a front-end user interface, one or more back-end APIs (REST, GraphQL, or SOAP), authentication and session management logic, file upload and processing functionality, and administrative interfaces.
Each of these components presents a distinct attack surface.
Web application penetration testing differs from vulnerability scanning in the same way that external network penetration testing does. A vulnerability scanner identifies the potential presence of known weaknesses. A penetration tester validates each finding, attempts exploitation, identifies how individual issues combine into higher-impact attack paths, and assesses the real business consequences of a successful compromise.
It also differs from static application security testing (SAST) and other development-lifecycle testing tools. SAST analyses source code for potential flaws without running the application. A penetration test exercises the running application in its deployed environment, testing how it actually behaves under attack. The two approaches are complementary, and dotSec can include source code review as part of a broader web application security engagement where it adds value.
What dotSec tests in web application assessments
dotSec’s web application penetration tests are informed by the OWASP Web Security Testing Guide (WSTG) and aligned with the OWASP Top 10:2025 risk categories. Each engagement is scoped to the specific application, but testing typically covers the following areas.
Authentication and session management
We test how the application verifies user identity and maintains session state. This includes password policies and brute-force protections, multi-factor authentication implementation, session token generation, expiry, and invalidation, account lockout and recovery mechanisms, and single sign-on (SSO) integration where applicable.
Access controls and authorisation
Broken access control is the number one risk category in the OWASP Top 10:2025. We test whether users can access resources, functions, or data beyond their intended permissions. This includes horizontal privilege escalation (accessing another user’s data), vertical privilege escalation (accessing administrative functions), insecure direct object references (IDOR), missing function-level access controls, and server-side request forgery (SSRF).
Input validation and injection
We test how the application handles user-supplied input across all entry points, including form fields, URL parameters, HTTP headers, cookies, and API request bodies. Testing covers SQL injection, cross-site scripting (XSS), command injection, XML/JSON injection, and other injection vectors relevant to the application’s technology stack.
API security
Most modern web applications rely on APIs, and API endpoints often expose more functionality than the front-end interface suggests. We test REST, GraphQL, and SOAP APIs for authentication and authorisation weaknesses, excessive data exposure, rate limiting and abuse controls, input validation flaws, and insecure endpoint configurations. API testing follows the same methodology applied to the broader application.
Business logic
Automated scanners cannot identify business logic flaws because they require an understanding of what the application is supposed to do. We manually test for flaws in workflows such as payment processing, multi-step transactions, discount and coupon logic, user registration and onboarding, and any process where the sequence or conditions of operations matter. Business logic flaws are frequently the highest-impact findings in web application assessments.
Cryptography and data protection
We assess how the application protects data in transit and at rest, including TLS configuration, encryption of sensitive data fields, secure storage of credentials and API keys, and cryptographic implementation weaknesses.
Server-side configuration
We assess the application’s deployment environment for misconfigurations that could aid an attacker, including verbose error messages, default credentials on administrative interfaces, unnecessary HTTP methods, missing security headers, and exposed development or staging environments.
Why web application penetration testing matters
Web applications are publicly accessible by design. They handle sensitive data including credentials, payment information, personal records, and proprietary business data. They change frequently as development teams release new features. And they depend on complex chains of frameworks, libraries, and third-party integrations, each of which can introduce vulnerabilities.
This combination of exposure, sensitivity, and complexity makes web applications a primary target. They are consistently among the most exploited entry points in Australian cyber incidents.
Several compliance frameworks require or strongly recommend regular web application security testing:
- PCI DSS v4.0.1 Requirement 6.4 mandates that public-facing web applications are protected against known attacks, and Requirement 11.4 requires penetration testing at least annually and after significant changes. dotSec is a PCI QSA company and a PCI DSS-compliant service provider.
- ISO 27001:2022 Annex A controls A.8.25 (Secure development life cycle), A.8.26 (Application security requirements), and A.8.28 (Secure coding) all support the case for regular application security testing as part of an ISMS.
- APRA CPS 234 requires APRA-regulated entities to test the effectiveness of information security controls commensurate with the criticality of the assets they protect. For organisations with customer-facing web applications, application-layer testing is a direct way to meet this obligation.
- The ACSC Essential Eight maturity model addresses patching of applications and restriction of administrative privileges, both of which are informed by web application pen test findings.
For organisations that operate a managed SOC or SIEM, web application pen test findings also provide context for detection rule tuning, and implementing a managed WAF after an assessment provides an additional layer of protection for findings that require longer-term code-level remediation.
The web application penetration testing process
dotSec follows a structured methodology for each web application engagement.
Scoping and reconnaissance
We work with you to define the application scope, including URLs, user roles, API endpoints, and any areas to exclude. We then gather information about the application’s technology stack, architecture, and authentication model to plan the assessment.
Discovery and analysis
We map the application’s attack surface, identifying all entry points, user roles, data flows, and integration points. This phase combines automated crawling and scanning with manual analysis to build a complete picture of the application’s functionality.
Exploitation and validation
We attempt to exploit identified vulnerabilities to determine their real-world impact. This includes chaining lower-severity findings into higher-impact attack paths where possible. Every finding is manually validated to eliminate false positives.
Reporting and remediation guidance
We deliver a detailed report that includes an executive summary suitable for management and compliance audiences, technical detail for each finding including evidence of exploitation, risk ratings consistent with industry standards, and prioritised remediation guidance that your development team can act on. Where relevant, we reference specific OWASP Top 10:2025 and WSTG identifiers for each finding.
Remediation verification
After your team has addressed the findings, dotSec can conduct targeted retesting to verify that remediations are effective and that no new issues have been introduced.
Web application penetration testing FAQ
What is the difference between a vulnerability scan and a web application penetration test?
A vulnerability scan uses automated tools to identify the potential presence of known weaknesses. It is fast and broad, but it produces false positives and cannot identify logic flaws, chained attack paths, or context-dependent vulnerabilities. A penetration test goes further: an assessor manually validates each finding, attempts exploitation, and assesses real business impact. dotSec also provides vulnerability scanning and assessment services as a complementary service between pen test engagements.
How often should we pen test our web applications?
At a minimum, annually and after any significant change to the application, such as a major feature release, a change to the authentication mechanism, or a migration to a new hosting environment. PCI DSS requires annual testing plus testing after significant changes. Organisations with active development cycles or high-risk applications may benefit from more frequent testing.
Do you test APIs as part of a web application pen test?
Yes. Most modern web applications rely on APIs, and we test REST, GraphQL, and SOAP endpoints as part of the standard engagement scope. API testing covers authentication, authorisation, data exposure, input validation, and rate limiting.
What do we need to provide before the assessment?
At a minimum, we need the URLs and environments to be tested, a description of user roles and access levels (and test accounts for each role, for authenticated testing), any areas to exclude, and your preferred testing window. For a grey-box or white-box assessment, we may also request architecture documentation or source code access.
Can you test applications hosted in the cloud?
Yes. dotSec tests web applications regardless of hosting environment, including AWS, Azure, GCP, and on-premises infrastructure. For cloud-hosted applications, we work within the shared responsibility boundaries of each provider and handle any provider-specific authorisation requirements during scoping.
What is the difference between web application pen testing and red teaming?
A web application pen test focuses specifically on the security of the application and its supporting infrastructure. A red team engagement simulates a broader adversary campaign that may combine web application exploitation with social engineering, network intrusion, and physical access to achieve a defined objective. Red teaming tests your organisation’s detection and response capabilities across multiple attack vectors. Web application pen testing tests the application itself.
Does web application pen testing satisfy PCI DSS requirements?
PCI DSS v4.0.1 Requirement 11.4 mandates penetration testing of in-scope systems, which includes any web application that stores, processes, or transmits cardholder data. Requirement 6.4 also requires that public-facing web applications are protected against known attacks. A web application penetration test conducted by a qualified assessor can help satisfy both requirements. dotSec is a PCI Qualified Security Assessor (QSA) and understands the specific evidence requirements.
Can you include source code review in a web application assessment?
Yes. While our standard web application penetration test is a dynamic assessment of the running application, we can include static analysis (source code review) as part of a broader engagement where it adds value. This is particularly useful for custom-built applications with complex business logic. Source code review and penetration testing are complementary: code review identifies flaws that may not be reachable through the running application, while pen testing identifies issues that only manifest at runtime.
How does web application pen testing relate to AI penetration testing?
If your web application incorporates AI or LLM components, such as a chatbot, document processing, or recommendation engine, those components introduce additional attack vectors including prompt injection, training data extraction, and insecure output handling. dotSec’s AI penetration testing service can be combined with a web application assessment to cover both traditional application vulnerabilities and AI-specific risks.
What next?
If your organisation needs a web application penetration test, whether for compliance, risk reduction, or as part of a secure development programme, dotSec can scope an engagement to match your requirements.
Web application pen test findings can feed directly into remediation programmes across secure configuration and hardening, managed WAF deployment, and SOC and SIEM detection tuning. For organisations with governance and compliance requirements, dotSec’s GRC specialists can help align findings with your risk register and provide audit-ready evidence.
Premier Australian cyber security specialists
