How to Read a Penetration Test Report
How to read a penetration test report: what severity ratings mean, how to judge the evidence, which findings to fix first, and how the retest closes the loop.
Application testing
Web Application Penetration Testing
We test your web application the way a determined attacker would, by hand, and show you exactly what they could reach.
- OWASP WSTG
- OWASP Top 10
Overview
Your web application is where your customers’ data lives and where most of your business logic runs. It is also where automated scanners are weakest. A scanner can spot an outdated library. It can’t tell that a user in one company can open an invoice belonging to another, or that a discount can be applied twice.
Our testers work through your application by hand, with accounts for every role, and look for what actually matters: broken authorization, tenant isolation failures, logic flaws and chained attacks. The result is a report your engineers can act on and your auditors and customers can rely on.
Scope
What we test
- Authentication, password reset and MFA flows
- Session management and token handling
- Authorization between roles and users (IDOR / BOLA)
- Multi-tenant isolation between customer accounts
- Injection flaws, including SQL, NoSQL, command and template injection
- Cross-site scripting and client-side security
- Server-side request forgery (SSRF) and deserialisation
- Business logic and workflow abuse
- Payment, pricing, coupon and quota logic
- File upload and document processing
- SSO, SAML and OAuth integrations
- Admin and internal functions
- Security headers, CORS and configuration
Findings
Common issues we find
Generic examples of what this kind of testing tends to uncover. Every engagement is different, and we never share client findings.
Critical
One tenant can read another tenant's data
An object ID in a request is trusted without checking it belongs to the signed-in organisation.
High
Low-privilege users reaching admin actions
The interface hides a button, but the endpoint behind it never checks the user's role.
High
Workflow steps that can be skipped
Approval, payment or verification steps enforced only in the browser.
High
Password reset weaknesses
Reusable or long-lived reset tokens, or reset links sent to an address the attacker controls.
Medium
Stored cross-site scripting
User-supplied content rendered without encoding, often in admin views where it does the most damage.
High
SSRF through URL-fetching features
Webhooks, link previews or imports that can be pointed at internal services or cloud metadata.
Low
Missing or weak security headers
No Content-Security-Policy, permissive CORS, or cookies without Secure and SameSite flags.
Severity shown is typical, not fixed. We rate each finding on its real impact in your environment.
Approach
How we test it
Map the application
We walk every role through the app, catalogue features, endpoints and trust boundaries, and agree which flows matter most to your business.
Test access control first
Using accounts for each role and tenant, we test every sensitive action and object for horizontal and vertical privilege escalation.
Attack the logic
We look for ways to abuse workflows, pricing, limits and state, the flaws that only make sense once you understand what the app is for.
Cover the technical classes
We work through injection, XSS, SSRF, file handling and configuration, guided by OWASP WSTG, using tools for coverage and humans for depth.
Prove and prioritise
Every finding is manually reproduced with a proof of concept and rated by real business impact, so your team fixes the right things first.
Deliverables
What you receive
Every finding comes with proof-of-concept evidence, so your engineers can reproduce it and your auditors can trust it.
Executive summary
A plain-English view of risk for leadership, boards and customers.
Technical findings
Each issue with impact, evidence, reproduction steps and a clear fix.
Free retest
Once you’ve fixed the findings, we retest them and update the report.
Attestation letter
A letter you can share with customers and auditors to show testing was done.
Preparation
What we need from you
We'll confirm the details during scoping. Having these ready helps testing start on time.
- Test accounts for each user role, ideally in two separate tenants
- The environment URL (production-like staging preferred)
- A short walkthrough of key features or a product demo
- API documentation or a Postman/OpenAPI collection, if available
- A technical contact for questions during testing
- An agreed testing window and any areas to avoid
FAQ
Web Application testing questions
How long does a web application pentest take?
Most single applications take one to two weeks of testing plus reporting. The exact effort depends on the number of roles, features and integrations, and we confirm it in your proposal after scoping.
Do you test the API behind the web app too?
Yes. The API your front end calls is part of the attack surface and is tested as part of the engagement. Standalone or public APIs can be scoped as a dedicated API test.
Should we test production or staging?
Either works. We recommend a production-like staging environment with realistic data shapes, so we can test destructive scenarios safely. If production is the only option, we agree rules of engagement first.
Do you use automated scanners?
Tools help us with coverage, such as crawling and fuzzing, but they don't drive the test. Every reported finding is manually verified, and most high-impact issues come from manual work.
What happens after the report?
We walk your team through the findings, answer questions while you fix, and then retest the reported issues at no extra cost. Once fixes are confirmed, we issue an attestation letter.
Guides and free tools
SOC 2 Penetration Testing: What Auditors Expect
What SOC 2 actually says about penetration testing, what auditors look for in a pentest report, and how to time your test around the audit window.
SOC 2 Pentest Readiness Checklist
Answer 20 yes/no questions to see how ready you are for a SOC 2 penetration test, and which gaps to close first.
Runs in your browser
Related services
API Penetration Testing
Hands-on testing of REST, GraphQL and gRPC APIs for broken authorization, data exposure and abuse of business logic.
Secure Code Review
Manual review of your most critical code, with findings mapped to exact lines and fixes your developers can apply.
Cloud Security Testing (AWS, Azure, GCP)
Configuration review and authenticated attack-path testing of your AWS, Azure or GCP environment, focused on how small permissions become full control.
Need a pentest for an audit, a customer, or peace of mind?
Tell us what you need tested. You’ll get a fixed-fee proposal with tester-days and timeline stated, usually within a few days of the scoping call.