Offensive testing
Web application penetration testing for Australian organisations.
Manual testing of web applications and their APIs: sign-in, sessions, access control, business logic and injection, scoped and quoted in writing first.
At a glance
- Re-testInside the agreed scope
- ManualEvery finding reproduced by a tester
- OWASP ASVSThe checklist behind the coverage
Overview
A tester works through the application the way its users do, signed in as each role, then the way an attacker would. Every finding is reproduced by hand, and the re-test confirms closure on the deployed application.
Where testing runs
Black Shard is an Australian software engineering and cybersecurity firm. Testing runs remotely against the application wherever it is hosted, inside an agreed window, with access provisioned for the test and removed at the end.
What a web application test covers
The scope names the application, its environments and the roles a tester signs in as. Testing works through each area against OWASP guidance, with the Application Security Verification Standard (ASVS) as the checklist behind the coverage.
- Authentication: sign-in, password reset, MFA enrolment and recovery, and account lockout
- Session handling: how tokens are issued, expire, end at logout and travel between devices
- Access control: every role tried against every function, and one user's records tried from another's account
- Business logic: workflows taken out of order, limits bypassed, and prices or quantities altered in transit
- Injection: SQL, command and template injection, and cross-site scripting in every input the application trusts
- File uploads, redirects and the server-side requests the application makes on a user's behalf
Authenticated testing
Most of what matters in a web application sits behind the sign-in. A test runs with an account for each role in scope, so the tester reaches what a customer, a staff member and an administrator each reach, then tries for what each should not.
An unauthenticated pass maps what the application exposes before sign-in: the login and reset flows, public endpoints, and anything reachable without a session.
Test accounts and environments
Test accounts are provisioned for the testing window and removed at the end. Testing runs against a staging environment that matches production where one exists, and against production inside an agreed window where it does not, with destructive techniques excluded by default.
API penetration testing
The API behind a web application is tested as a surface of its own, because anyone holding a session can call it directly. Every endpoint in scope is checked for authorisation, for access to records the caller does not own, and for data a response returns that the screen never shows.
- Authorisation on every endpoint and method, including those the interface never calls
- Object-level access: one user's or one tenant's record identifiers tried from another account
- Mass assignment: fields the API accepts that the interface never sends
- Rate limits on the requests an attacker would repeat, such as sign-in and password reset
Testing an API on its own
API penetration testing also runs on its own for a public or partner API, scoped from its specification or a collection of sample requests.
How a web application test runs
Six stages, each recorded in the report with what was done and when.
- Scoping: the application, environments, roles and exclusions agreed in writing, with the quote
- Mapping: every page, route, API endpoint and role recorded before testing starts
- Testing: each area worked by hand, with automated tooling used for coverage
- Exploitation: weaknesses confirmed and chained only as far as the rules of engagement allow
- Reporting: each reproduced finding written up, then a debrief with the tester
- Re-test: once fixes are deployed, each finding tested again and its status recorded
The report and the re-test
The report opens with a summary of overall exposure for the executive who signs off, then ranks each finding by severity for the engineers who fix it. Every finding carries the affected route or endpoint, reproduction steps with the requests and responses captured, the business impact and the fix.
Re-testing
A re-test of the findings in the original report sits inside the scope. It confirms each one is closed on the deployed application and records its status, so the report a customer or insurer reads shows the position after the fixes.
Confidentiality
Findings are the client's information. They are held in confidence and disclosed to a third party only with the client's consent.
Applications we build and run
The testers work beside the engineers who build and run applications in production for regulated Australian clients, so an application is read the way the people who ship one read it. The GRM LAW portal, Aurii and the Stone Leaf Capital portal are among the systems we build and run.
Multi-tenant designs such as Aurii, where each practice's data is kept apart in the database itself, are the reference for the tenant boundary tests.
Certification and method
Black Shard holds SMB1001:2026 Gold, verifiable on the CyberCert public registry. OWASP guidance and the ASVS are methodologies we test against.
How a web application test is scoped
Every test is scoped and priced before the work starts, in writing, and the quote names what drives it. The free pen test scope builder turns these into a brief you can send unchanged.
- The number of roles, and the functions behind each one
- The API endpoints in scope beside the interface
- The environments in scope, and tenancy count for a multi-tenant product
- Whether production or a matching staging environment is tested
Starting the scope
A free 30-minute scoping call settles the scope and the quote. A brief to info@blackshard.com.au starts scoping from the detail you have.
From the newsroom
Application security, in the newsroom.
Critical severity
Questions, answered.
How is a web application test different from a vulnerability scan?
A scanner reports known patterns it can reach without signing in. A tester signs in as each role, follows the application's own workflows and tries what the design allows by mistake, such as opening another customer's records. Automated tooling is used for coverage, and nothing is reported until a tester has reproduced it.
Can you test a single-page application or the API behind a mobile app?
Yes. A single-page application is tested through its interface and directly against the API it calls. The API behind a mobile app is tested the same way, from the requests the app itself sends.
Can you test in production?
Yes, inside an agreed window, with destructive techniques such as denial of service excluded by default and a stop-work contact named on both sides. A staging environment that matches production is preferred where one exists, so state-changing functions can be worked through freely.
How long does a web application test take?
The window is fixed at scoping and set by the roles, the functions behind each one and the API surface. A site with a contact form is a short engagement; a multi-tenant portal with an API and several roles takes longer. The window is in writing before testing begins.
Can we share the report with a customer or insurer?
Yes. The summary is written for a reader outside engineering, and the re-test status shows what was closed. Findings stay confidential and go to a third party only with your consent.
