Web Application Penetration Testing in Australia: What It Is, How to Scope It and What to Expect
Web application penetration testing in Australia: pen test vs scan vs QA, scope, written authorisation, preparation, reports, remediation and retesting.
What is web application penetration testing?
A web application penetration test is an authorised, time-boxed attempt by skilled testers to find and exploit weaknesses in your application within an agreed scope, producing a report of verified findings, risk ratings and fixes. It differs from an automated vulnerability scan, which checks for known issues, and from QA, which checks that features work as intended. A clean test does not prove an application is secure; it shows what was found by those testers, in that scope, at that time.
This guide is for Australian businesses commissioning a test for a customer portal, SaaS product, booking system or other web application. It explains the types of testing, how to scope a test, authorisation, preparation, what testers examine, reports, remediation and retesting. If you are commissioning a test for a customer portal or payment integration, scope those journeys explicitly.
Disclosure: ZSpace Labs does not offer specialist penetration testing. We build applications and fix issues found by independent testers. For the build-time security baseline, see building a secure customer-facing web application.
Key takeaways
- Penetration testing, vulnerability scanning and QA answer different questions; you usually need all three.
- Scope by application, environments, user roles and APIs, and say what is out of scope.
- Get written authorisation from every owner of systems in scope, and check cloud and SaaS testing policies.
- Prepare test accounts for each role, a stable environment and contacts for incidents during testing.
- Expect findings with evidence, risk ratings and fixes, not a pass or fail certificate.
- Fix, then retest. Track remediation like any other work.
- Use an independent tester, separate from the team that built the software.
Penetration test vs vulnerability scan vs QA
| Penetration test | Vulnerability scan | QA testing | |
|---|---|---|---|
| Question answered | What can an attacker actually do? | Are known weaknesses present? | Do features work as intended? |
| Who or what | Skilled testers, tools as support | Automated tools | Testers and automated tests |
| Strengths | Business logic, authorisation, chained issues | Frequent, broad, cheap | Functional correctness |
| Limits | Time-boxed snapshot | Misses logic flaws; false positives | Not designed to find attacks |
| Typical frequency | Before launch, after major change, periodically | Continuously or weekly | Every release |
Types of testing
Black box testers start with no inside knowledge, like an external attacker. Grey box testers get user accounts and some documentation, which is usually the most efficient for web applications because it lets them test authorisation between roles. White box testing adds source code access and architecture review. Many tests also cover the APIs behind the application; see API security best practices. Methodologies such as the OWASP Web Security Testing Guide describe what a thorough web test covers (OWASP WSTG).
Scoping the test
- Application URLs, environments (production or a production-like staging) and versions.
- User roles to test, with a test account for each, including administrators and different tenants.
- APIs, mobile app backends and third-party integrations in scope.
- Out of scope: denial of service, social engineering or physical testing unless explicitly agreed.
- Testing windows, rate limits and systems that must not be disrupted.
- Data handling: what testers may access and how they protect and delete it.
- Deliverables: report format, severity scheme, a debrief and a retest.
Authorisation and rules of engagement
Testing without permission can be unlawful, even against systems you use. Before testing starts, have a signed authorisation from the owner of each system in scope, and check the testing policies of your cloud host and any SaaS components; some require notice or restrict certain tests. Agree rules of engagement: dates and times, source IP addresses, contacts on both sides, what happens if testers find a critical issue or evidence of an existing compromise, and how to stop testing quickly.
Preparing for the test
- A stable environment with realistic, non-production data where possible.
- Test accounts for each role and tenant, with sample data.
- Architecture overview, API documentation and a list of recent changes.
- Monitoring and alert owners informed, so testing is not mistaken for an attack (or so you can see whether alerts fire).
- Backups confirmed for any environment that will be tested.
- A named technical contact available during testing.
What testers typically examine
A web application test commonly covers authentication and session handling, authorisation between users, roles and tenants, input handling and injection, business logic (for example, changing prices or skipping approval steps), file uploads, configuration and security headers, error handling and information leakage, and dependencies with known vulnerabilities. The OWASP Top 10:2025 lists the most critical web application risk categories, with broken access control first (OWASP).
Reports, remediation and retesting
A useful report has an executive summary, the scope and method, and for each finding: description, evidence, affected components, risk rating with reasoning, and specific remediation advice. Ask for a debrief with your developers.
Then fix in priority order, starting with critical and high findings, and fix root causes, such as a missing authorisation check in a shared function, rather than single instances. Ask the tester to retest fixed findings and update the report. Track remediation dates; findings that sit open for months are a common audit problem.
Worth noting
If testers find evidence that the application has already been compromised, treat it as an incident: follow your incident response plan, preserve evidence and assess whether the Notifiable Data Breaches scheme applies. See cyber incident response planning.
Choosing a testing provider
- Experience testing applications like yours (SaaS, payments, health data, APIs).
- Named testers and their qualifications; some buyers ask for CREST-accredited firms or certified testers.
- A sample report with client details removed.
- Clear methodology, rules of engagement and data handling.
- Independence from the team that built the software.
- Retesting included or priced.
- Where testers are located and how they handle your data, especially personal information (APP 8 may apply). For general supplier checks, see choosing a web development company in Australia.
Common mistakes
- Treating a vulnerability scan report as a penetration test.
- Scoping only the public pages and not authenticated roles or APIs.
- Testing without written authorisation or checking host policies.
- Fixing individual findings but not the shared cause.
- No retest, so fixes are never verified.
- Presenting a test report as proof the application is secure.
Related guides
For building securely in the first place, see secure web application development. For operating a site safely, see website security for Australian small businesses. For stores, ecommerce security audit covers pre-test reviews.
Sources
OWASP Web Security Testing Guide; OWASP Top 10:2025; OAIC, APP 8.
Tables and checklists are ours. Nothing here is legal advice. ZSpace Labs does not provide penetration testing services.
Conclusion
A penetration test is a valuable, time-boxed look at your application through an attacker's eyes. Scope it around real roles, data and APIs, authorise it properly, prepare your environment, insist on evidence-based findings, fix root causes and retest. Combine it with secure development and regular scanning, and never treat a single report as proof of security.
Need help fixing findings from a test?
ZSpace Labs is an India-based, remote-first technology studio working with Australian and international businesses on secure web applications. We do not perform penetration tests, but we can help your team remediate findings and build security into delivery.
Common questions.
A penetration test is an authorised, time-boxed attempt by skilled testers to find and exploit security weaknesses in an application, the way an attacker might, within an agreed scope and rules. The output is a report of findings with evidence, risk ratings and remediation advice. It shows what the testers found in that period, not that no other weaknesses exist.