Advisory

Web Application Penetration Testing in Australia

Hands-on testing of your web applications, customer portals and the APIs behind them, by a CREST-accredited team based in Australia. Every serious finding is proven by hand and retested after you fix it.

Web application penetration testing in Australia, led by CREST-registered testers.

Web application penetration testing is a controlled attack on your web application, run by experienced people, to find the weaknesses a real attacker would use. Vectra is a CREST-accredited penetration testing company in Australia, and one of our six CREST accreditations is App Security Testing. Every web app pen test is led by a CREST-registered Practitioner or Senior Consultant. We test customer portals, online stores, internal business applications and single-page apps, both signed in and signed out. Our testers work to the OWASP Top 10 and OWASP ASVS Level 2. Automated tools help us triage, but people do the testing, and each High-and-above finding is exploited by hand.

Web Application Penetration Testing

What a web application penetration test involves.

A summary of what a web application pen test from Vectra includes. Every test is scoped and quoted to your application.

  • Accreditation

    CREST-accredited company. App Security Testing is one of our six CREST accreditations.

  • Who tests

    A CREST-registered Practitioner or Senior Consultant leads every test. Our testers are based in Australia.

  • Standards

    OWASP Top 10 and OWASP ASVS Level 2, within our six-step CREST-aligned methodology.

  • Coverage

    Authentication, sessions, access control, business logic, input handling, payment flows and the API behind the application.

  • Environments

    Production with throttling and a live bridge to your team, or a staging environment checked against production.

  • Retest

    A retest window for every High-severity finding and above.

What we test in a web application penetration test.

Scanners find what is easy to find. Our testers spend their time on the flaws that need human judgement to uncover.

Authentication and sessions

We test sign-in, password reset, multi-factor prompts, lockouts, session tokens, timeouts and sign-out. A weak session can hand an attacker a valid account without any password.

Authorisation and access control

Can one customer read another customer's records by changing a number in the URL? We test for insecure direct object references (IDOR), missing role checks and privilege escalation.

Business logic abuse

A scanner cannot tell whether a workflow makes sense, but a tester can. We skip steps, replay requests, alter amounts and chain minor flaws into a genuine loss.

Injection and input handling

We test every input the application trusts, from forms and headers to file uploads, covering SQL injection, cross-site scripting (XSS), server-side request forgery and unsafe file handling.

Single-page and thick-client apps

Modern front ends move logic into the browser, and thick clients talk directly to back-end services. We test what the client conceals and what the server still trusts.

Payment and customer-data flows

Checkout, refunds, stored cards and personal records receive particular attention. We check how sensitive data moves, where it is stored and who can reach it.

Authenticated and unauthenticated testing

We begin as an outsider with no account, then test with credentials for each role, to show how far a stolen or malicious login could get.

SAST and DAST correlation

Where you provide source code, we match static and dynamic analysis results to the issues we exploit manually, pointing your developers to the root cause.

When you need a web application penetration test.

Test before an attacker finds the gap, and before a customer or auditor asks for independent evidence.

  • Before a new application, portal or major release goes live.

  • After significant changes to authentication, user roles or payment flows.

  • When a customer contract or security questionnaire requires an independent test.

  • When you need evidence for PCI DSS, ISO 27001 or APRA CPS 234.

  • After remediation of earlier findings, to confirm the fixes hold.

  • At least annually for applications that hold customer or payment data.

Why choose Vectra for web application pen testing.

A web application test is only as good as the people who run it. This is what sits behind ours.

CREST App Security Testing

Vectra holds six separate CREST accreditations, and App Security Testing is one of them. You can verify each accreditation on the CREST Marketplace before you engage us.

Proof, not scanner output

Burp Suite and OWASP ZAP speed up discovery and triage. A tester then proves each High-and-above issue by hand, so raw scanner output never reaches your report.

Experienced, credentialed testers

Between them, our testers hold OSCP, OSEP, CEH, eCPPT, CRTP, CRTE and CRT certifications. Not every tester holds every credential, and we confirm who is assigned at scoping.

Testing performed in Australia

Our testers are based in Australia and work nationally. Data storage and access arrangements are agreed with you for each engagement.

How we test a web application, step by step.

Every Vectra engagement follows the same six CREST-aligned steps. This is how each step applies to a web application.

  1. Step 1: Scope & kick-off

    We agree the URLs, user roles, test accounts, environment and testing window, then confirm the rules of engagement and escalation contacts.

  2. Step 2: Threat modelling

    We map who uses the application, what data it holds and how orders or records move, and record abuse cases for your workflows.

  3. Step 3: Reconnaissance

    We crawl the application to list every page, parameter and hidden route, along with the frameworks and third-party scripts it loads.

  4. Step 4: Exploitation

    Testers work through the OWASP ASVS Level 2 requirements manually, and every High-and-above finding receives a proof of exploit.

  5. Step 5: Post-exploitation

    We demonstrate what an initial foothold leads to, such as other users' data, administrative functions, back-end systems or stored secrets.

  6. Step 6: Reporting & retest

    You receive the report and a debrief with your developers. Once the serious findings are fixed, we verify the fixes in a retest.

What you receive after a web app pen test.

The report is written for two audiences. Executives get a plain account of business risk, while developers get the technical detail they need to fix each issue the first time.

These deliverables are consistent across every Vectra engagement. The complete list is on our main penetration testing page.

  • Executive narrative report

    Findings explained in business, legal and reputational terms for your executive team and board risk committee.

  • Technical findings

    Exact reproduction steps for each issue, the affected pages and parameters, and screen captures of the exploit chain.

  • Remediation guidance and developer debrief

    Developer-ready remediation, a suggested code fix where applicable, and a walkthrough session with your development team.

  • Retest and portal access

    A retest of High-and-above findings, plus 90 days of portal access to track remediation.

Compliance a web application pen test supports.

A web application test is often the evidence an auditor or customer asks for. We can map the report to the frameworks you answer to, so a single test serves several obligations.

PCI DSS

Application-layer testing for requirement 11.4, from Australia's first certified QSA company. Our PCI team also covers payment-page script requirements 6.4.3 and 11.6.1.

ISO 27001

Annex A control 8.29 requires security testing during development and acceptance. A penetration test before go-live provides direct evidence for that control.

SOC 2 readiness

A recent penetration test is common evidence for the security criteria. We prepare you for the examination, and an independent CPA firm issues the report.

APRA CPS 234

APRA-regulated entities must systematically test the controls protecting their information assets. A web application test provides independent evidence for that program.

Privacy Act (APP 11)

APP 11 requires reasonable steps to protect personal information. Testing the applications that collect and store it is one of those steps.

Customer due diligence

Enterprise and government buyers often ask suppliers for a recent independent test. The executive report gives you a clear summary to answer them.

How we scope and quote a web app pen test.

The number of roles, pages and workflows determines the effort, so we scope and quote each application individually.

Related penetration tests.

Web applications rarely stand alone. These tests are often scoped alongside them.

API penetration testing

REST, GraphQL and gRPC APIs tested in their own right, including partner and machine-to-machine traffic.

Mobile app penetration testing

iOS and Android apps that share a back end with your web application, tested on the device and over the network.

Cloud penetration testing

The AWS, Azure or Google Cloud platform your application runs on, from identity to storage.

All penetration testing

Network, wireless, OT, AI agent and red team engagements, and how every Vectra test is run.

Web application penetration testing near you.

Our city pages cover the sectors, compliance needs and procurement routes that matter to buyers in each location. Each one also lists the local office contact details.

Web application penetration testing FAQs.

What is the difference between a web app pentest and a vulnerability scan?

A vulnerability scan is automated: it looks for known weaknesses and outdated software, but it cannot judge whether a business workflow makes sense. A web app pentest is performed by a person who signs in, tries each user role and chains small flaws into real impact. We use scanners for triage, then prove each High-and-above issue manually. Scanning suits ongoing checks between penetration tests.

Do you need our source code?

No. Most web application tests are performed without source code, from the same position as an external attacker. If you can share the code, we correlate SAST and DAST results with the issues we exploit manually, which helps your developers locate the root cause faster. We can also perform an in-depth code review as a separate engagement.

Can you test our web app in production?

Yes. Production testing uses throttled request rates, pre-approved limits on destructive actions and a live bridge to your team, so any problem is raised while the test runs. If you would rather we test a staging environment, we first check that its configuration genuinely matches production, so the results still apply to the live application.

Do you test the API behind the web application?

Yes, where it is included in scope. Most modern web applications are a front end sitting on an API, and many serious flaws live in that API layer. Testing both layers together lets us follow an attack from the browser through to the back end. For APIs that also serve partners or mobile apps, see our API penetration testing page.

What does OWASP ASVS Level 2 mean?

The OWASP Application Security Verification Standard (ASVS) is a detailed list of security requirements for web applications. Level 2 is the level OWASP recommends for most applications that handle sensitive data or business transactions. Testing against ASVS Level 2 gives a deeper and more repeatable result than the OWASP Top 10 alone, which only describes the most common risks.

Start with a conversation.

Speak to us about your cyber governance and compliance requirements.

Send us a message

What can we help with?

A sentence or two is plenty. We'll ask for detail when we reply.