Web application penetration testing
Your web app is the front door to customer data, payments and admin. We test it logged in, role-aware, reading the JavaScript and probing the assumptions your developers made under deadline.
What this engagement is
For most Australian businesses the web application is the highest-value, highest-exposure surface they run: customer records, invoicing, internal admin, the thing a ransomware crew would actually like to reach. Firewalls and scanners raise the floor. They do not think like someone who has a test account, a weekend and a motive.
A web application penetration test is an authorised, manual attack against that application. We work through every in-scope role, every trust boundary and every workflow that moves money or data, then we write down what a determined attacker would actually do, with evidence.
This is the engagement we recommend first if you have a customer portal, a SaaS product, or an auditor asking for independent testing of the system users actually log into.
What we actually look for
Access control and IDOR
Horizontal and vertical privilege gaps, object-level access, forced browsing, and the admin functions hiding behind a CSS class.
Authentication and session
Password reset, MFA bypass, session fixation, cookie flags, JWT handling, and account enumeration that actually works.
Injection and XSS
SQL, command, SSTI and stored/reflected XSS, including the ones that only fire in a privileged role or a forgotten export.
Business logic
Price tampering, workflow skipping, race conditions on vouchers and payments, and the 'this should never happen' states.
Server-side request forgery
Blind and full SSRF against cloud metadata, internal admin and partner callbacks.
File handling and uploads
Content-type lies, polyglots, path traversal, and the preview pipeline that executes what it should only store.
Questions buyers ask before they sign
How long does a web application penetration test take?
Most web engagements are one to three weeks of active testing, depending on roles, screens and integrations. Add a few days either side for scoping and reporting. If you have an audit or launch date, tell us and we plan backwards from it.
Do you test production or staging?
Either. We prefer a staging environment that mirrors production so destructive edge cases are safe. We regularly test production under written rules of engagement, defined windows and a no-strike list.
What access do you need?
The application URL, at least one test account per user role, and written authorisation. Source code is optional. Grey-box with credentials finds far more than black-box guessing and is what we recommend.
Will testing break the application?
Denial-of-service is excluded unless you explicitly request it. Testing creates extra traffic and test data. We agree windows and contacts up front. Careful manual testing against a healthy application is low risk.
Is retesting included?
Yes. After you remediate we verify each fix at no extra cost, reissue the report with updated statuses, and provide an attestation letter.
Often scoped alongside
API penetration testing
Your SPA is a skin. The API is the product. We test REST, GraphQL and internal service APIs for the authorisation bugs that turn one user's …
Learn more > [mob]Mobile app penetration testing
The store listing is not the threat model. We assess the iOS and Android clients and the APIs they call, on-device and on the wire, mapped t…
Learn more > [cld]Cloud security review
Most cloud incidents are not zero-days. They are a public bucket, an over-privileged role, a key in a repo, and no logging when it matters. …
Learn more >Scope this test
Send the target, the roles and the deadline. You will get a fixed quote in AUD, usually within two business days.