Your web applications handle customer data, process transactions and expose business logic to the internet. Web application penetration testing shows whether they can withstand a targeted attack on their authentication, access controls, input handling and business logic.
years testing for government and enterprise
CREST-accredited through CREST ANZ
Our tests go beyond automated scanning. Assessors combine automated discovery with manual exploitation, drawing on the OWASP Web Security Testing Guide (WSTG), to find the business logic flaws, chained attack paths and access control failures that scanners miss.
Every finding is validated, assessed for real-world exploitability and reported with prioritised remediation guidance.
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 its supporting infrastructure. The assessor works from an attacker’s perspective, testing how the application responds to manipulation of its inputs, authentication, session management, access controls and data handling.
Like external network penetration testing, it goes further than vulnerability scanning. A scanner reports the possible presence of known weaknesses. A penetration tester proves which ones matter.
validates each finding by hand
attempts real exploitation
chains individual issues into higher-impact attack paths
assesses the business consequences of a successful compromise
Penetration testing also differs from static application security testing (SAST), which analyses source code without running the application. A penetration test exercises the running application in its deployed environment. The two are complementary, and we can include source code review in a broader engagement where it adds value.
Our 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 your application, but testing typically covers these seven areas.
We test how the application verifies identity and maintains session state: password policies and brute-force protection, multi-factor authentication, session token generation, expiry and invalidation, account lockout and recovery, and single sign-on (SSO) where it is used.
Broken access control is the top risk in the OWASP Top 10:2025. We test whether users can reach data or functions beyond their permissions, covering horizontal and vertical privilege escalation, insecure direct object references (IDOR), missing function-level checks and server-side request forgery (SSRF).
We test how every entry point handles user-supplied input, including form fields, URL parameters, HTTP headers, cookies and API request bodies. Testing covers SQL injection, cross-site scripting (XSS), command injection, XML and JSON injection, and other vectors relevant to your technology stack.
API endpoints often expose more functionality than the front end suggests. We test REST, GraphQL and SOAP APIs for authentication and authorisation weaknesses, excessive data exposure, missing rate limits, input validation flaws and insecure endpoint configuration.
Scanners cannot find business logic flaws because they do not know what the application is meant to do. We test workflows such as payments, multi-step transactions, discounts and registration by hand. These flaws are often the highest-impact findings in an assessment.
We assess how the application protects data in transit and at rest: TLS configuration, encryption of sensitive fields, storage of credentials and API keys, and weaknesses in cryptographic implementation.
We look for deployment misconfigurations that help an attacker, such as verbose error messages, default credentials on administrative interfaces, unnecessary HTTP methods, missing security headers, and exposed development or staging environments.
Web applications are publicly accessible by design. They handle credentials, payment information, personal records and proprietary business data. They change often as development teams release new features, and they depend on chains of frameworks, libraries and third-party integrations, each of which can introduce vulnerabilities.
That combination of exposure, sensitivity and complexity makes web applications a primary target. Several compliance frameworks require or strongly recommend regular web application security testing.
Requirement 6.4 requires public-facing web applications to be protected against attacks, and Requirement 11.4 requires penetration testing at least once every 12 months and after significant changes (PCI SSC document library). dotSec is a PCI QSA company and a PCI DSS-compliant service provider.
Annex A controls A.8.25 (Secure development life cycle), A.8.26 (Application security requirements), A.8.28 (Secure coding) and A.8.29 (Security testing in development and acceptance) support regular application security testing as part of an information security management system (ISMS).
Requires APRA-regulated entities to test the effectiveness of their information security controls, commensurate with the criticality of the assets they protect. For customer-facing web applications, application-layer testing is a direct way to meet this obligation.
The Essential Eight maturity model addresses patching applications and restricting administrative privileges. Web application pen test findings inform both.
Findings can feed directly into secure configuration and hardening, managed WAF deployment (protection while code-level fixes are made) and SOC and SIEM detection tuning.
Our GRC specialists can help align findings with your risk register and provide audit-ready evidence.
We follow a structured methodology for each web application engagement, in five phases, informed by the OWASP Web Security Testing Guide.
We work with you to define the scope, then gather information about the application’s technology stack, architecture and authentication model to plan the assessment. Scoping agrees:
We map the application’s attack surface: every entry point, user role, data flow and integration point. Automated crawling and scanning are combined with manual analysis to build a complete picture of what the application does.
We attempt to exploit the vulnerabilities we find to determine their real-world impact, which includes:
We deliver a detailed report containing:
Once your team has addressed the findings, we can retest the affected areas to verify that remediations are effective and that no new issues have been introduced.
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 validates each finding, attempts exploitation and assesses the real business impact. dotSec also provides vulnerability scanning and assessment services between pen test engagements.
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 move to a new hosting environment. PCI DSS requires annual testing plus testing after significant changes. Applications with active development cycles or high risk may need more frequent testing.
At a minimum: the URLs and environments to be tested, a description of user roles and access levels (with 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 ask for architecture documentation or source code access.
Yes. We test web applications in any hosting environment, including AWS, Azure, GCP and on-premises infrastructure. For cloud-hosted applications, we work within each provider’s shared responsibility boundaries and handle any provider-specific authorisation requirements during scoping.
A web application pen test focuses 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 detection and response across multiple attack vectors; web application pen testing tests the application itself.
If your web application includes AI or LLM components, such as a chatbot, document processing or a recommendation engine, those components add attack vectors including prompt injection, training data extraction and insecure output handling. Our AI penetration testing service can be combined with a web application assessment to cover both.
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.
Not sure what to include in scope? We can advise based on your application, its users and your compliance obligations.
