Penetration testing
Web Application Penetration Testing
Manual testing of your application's authenticated and unauthenticated attack surface, aligned to OWASP ASVS.
Engagements from $5,000 CAD. Free scoping, a fixed price in writing before any work begins, and one retest included.
At a glance
Is this the right test?
- Best when
- A release, an audit or an enterprise customer is asking how your application was tested.
- Covers
- Authentication and sessions, access control between users and tenants, input handling, business logic, and the API calls the application makes.
- You learn
- Whether one user can reach another's account or data, and the specific changes that stop it.
Before we start
What we need from you
Scoping settles the details. These are the things that usually decide whether testing can start on the agreed date.
- Test accounts for each role in scope, including at least two tenants where the application is multi-tenant.
- A staging environment that matches production, or written agreement on what may be tested in production.
- The critical workflows you most need to hold: sign-up, payment, data export, admin functions.
- Optional: source code access for a white box engagement.
Deliverables
What lands in your inbox
- Executive summary
A plain-language account of the risk position, written for the people who will not read the technical section.
- Overall security grade
A single grade derived from the most severe confirmed finding, using the thresholds set out in the report rather than a gut call.
- Detailed technical findings
Every finding with its CVSS vector, CWE classification, affected endpoints and full reproduction steps.
- Proof-of-concept evidence
Requests, responses and screenshots demonstrating that each finding is real rather than inferred.
- Remediation recommendations
Specific, written against your stack, and ranked by exploitability, business impact and what has to be fixed first. Not a link to a vendor advisory.
- Retest summary
Issued after remediation, confirming what is fixed and what remains outstanding.
See a redacted excerpt from a real finding, and what the full report adds.
Why it matters
What this protects you from
-
Account takeover
Authentication and session flaws let an attacker who holds one password reach a full account. How far they get from there depends on authorization and tenant isolation.
-
Customer data exposure
Broken access control is the top category in the OWASP Top 10, and it rarely announces itself in logs.
-
Business logic abuse
A logic flaw is built from requests that each look valid, which is why automated scanners rarely flag one. They are found by a person working through the workflow with intent to break it.
-
Regulatory exposure
Demonstrable due diligence matters when a regulator or an enterprise customer asks how the application was assessed.
Coverage
What we test
-
Authentication and session management
Token scope and lifetime, MFA enrolment and replacement, logout and revocation, and password reset flows.
-
Authorization and access control
Horizontal and vertical privilege checks, tested at the API rather than only in the interface.
-
Input handling and injection
SQL, NoSQL, command, template and cross-site scripting across the parameters reachable in the agreed scope.
-
Business logic
Workflow sequencing, value tampering, quantity and pricing manipulation, and race conditions on state changes.
-
API and backend trust
Whether server-side controls still hold when the client is bypassed entirely.
-
Configuration and security controls
Headers, cookie flags, CORS, TLS configuration, and version or environment disclosure.
Approach
Three ways to run it
-
Black box
No credentials and no documentation. Mirrors an internet-based attacker with no prior access.
-
Grey box
Standard user accounts across each role. The most common choice, and usually the best value for the time spent.
-
White box
Credentials plus source code. Trust boundaries can be traced rather than guessed, which improves coverage without guaranteeing completeness.
Process
How the engagement runs
-
Scoping and threat alignment
We agree targets, roles, environments and exclusions in writing, then map the attack surface that actually matters to your business.
-
Manual recon and enumeration
Enumeration of routes, parameters, roles and API endpoints in scope. Automated scanning is a starting point here, not the deliverable.
-
Targeted exploitation
Confirmed exploitation of what we find, with evidence captured as we go. Where exploiting a weakness would be unsafe or out of scope, we report it as unconfirmed and say why.
-
Impact analysis
Each finding is scored with CVSS and classified with CWE, then adjusted for what it means in your environment specifically.
-
Reporting and remediation
Written findings with reproduction steps, evidence and remediation guidance specific enough to hand to a developer, ranked by exploitability, business impact and what has to be fixed first.
-
Retest
Once you have remediated, we retest the reported findings, one round, requested within 60 days of the report, and issue a retest summary confirming what is closed.
Standards
What we test against
- OWASP ASVS
- Verification requirements drive coverage, so testing is measured against a published standard rather than one tester's habits.
- OWASP Web Security Testing Guide
- Individual test cases are drawn from the WSTG, so coverage is reproducible between engagements and between testers.
- NIST SP 800-115
- Overall assessment structure follows the NIST technical guide, which is what most procurement teams expect to see referenced.
- OSSTMM
- Methodology discipline and scope control, so results are repeatable and testing stays inside its agreed boundaries.