A launch or major release
A new product, API version, role model or payment flow is about to go live, and nobody outside the build team has tried to break it.
Manual testing of the roles, tenants and workflows your product runs on
We test one web application and its APIs the way a real user, a curious customer or a hostile tenant would. You get reproducible findings, a record of what was and was not tested, and a retest of your fixes.
When teams ask for this
An enterprise customer security review
A prospect's questionnaire asks for a recent independent penetration test, the scope it covered and the status of what it found.
SOC 2 or ISO 27001 evidence
Your auditor or compliance lead wants evidence of independent testing of the in-scope systems, with findings tracked to closure.
An agency client handover
You are delivering a client build, and the client or their security team requires an external assessment before acceptance.
A material change since the last test
SSO, a new tenant model, file uploads, a public API or a billing change has shipped since the system was last assessed.
What a finding looks like
A synthetic example in the format your report uses: evidence, impact, fix.
Invoice export returns another tenant's invoices when the tenant ID is changed
- Asset
- api.example.com: GET /v2/tenants/{tenantId}/invoices/export
- Caller
- Member role in Tenant B (synthetic test account)
- Standard
- OWASP API1:2023 Broken Object Level Authorization; CWE-639
Impact. Any authenticated user can download billing contacts, amounts and payment status for every tenant by enumerating tenant IDs. The IDs are sequential and appear in shared invoice links.
Fix. Derive the tenant from the authenticated session, not the path. Enforce tenant membership in the export service itself, add a regression test pairing Tenant A and Tenant B accounts, and review sibling export and report endpoints for the same pattern.
Evidence · request → response
GET /v2/tenants/tnt_4821/invoices/export?format=csv HTTP/1.1 Host: api.example.com Authorization: Bearer [redacted: Tenant B member token] Accept: text/csv
HTTP/1.1 200 OK Content-Type: text/csv X-Request-Id: syn-7f3a19c2 invoice_id,billing_email,amount_gbp,status INV-20931,[email protected],4200.00,paid INV-20932,[email protected],1180.00,overdue
What we test
Named test areas and checks. The scope record in your proposal confirms which apply to your system.
Authentication and account lifecycle5 checks
- Login, MFA enrolment and step-up, including bypass through alternate or legacy endpoints
- Password reset and email change: token entropy, expiry, reuse and account takeover paths
- Sign-up and invitation flows that assign roles or tenant membership
- SSO login (SAML or OIDC) where in scope: account linking and just-in-time provisioning
- Brute-force and credential-stuffing controls on login, reset and one-time-code endpoints
Sessions and tokens5 checks
- Session rotation on login and privilege change; fixation
- Logout, idle and absolute timeouts, and server-side revocation
- JWT handling: algorithm confusion, signature, audience, issuer and expiry validation
- Refresh token rotation and reuse detection
- Cookie attributes, CSRF defences and cross-origin (CORS) policy
Authorization and tenant isolation5 checks
- Object-level checks on every identifier the client can supply (BOLA / IDOR)
- Function-level checks: a member calling admin-only endpoints and actions
- Property-level checks: mass assignment and over-exposed response fields
- Cross-tenant access through search, exports, reports, signed file URLs and background jobs
- A role matrix exercised with separate accounts per role, per tenant
Business logic and workflows5 checks
- Approval, checkout and onboarding steps that can be skipped, replayed or reordered
- Price, quantity, discount, credit and usage-limit manipulation
- Race conditions on single-use actions: coupons, transfers, invitations, seat limits
- Trial, plan and feature-flag boundaries
- Actions a lower role can trigger indirectly through imports, integrations or scheduled tasks
Input handling and injection5 checks
- SQL, NoSQL and ORM injection in filters, sorting and search parameters
- Stored, reflected and DOM-based XSS, including rich-text and Markdown fields
- Server-side request forgery through URL fetchers, webhooks and import-from-URL features
- Template injection and unsafe deserialisation where the stack makes them plausible
- File uploads: type validation, storage location, how content is served back, path traversal
API surface5 checks
- Coverage against the supplied OpenAPI or GraphQL schema, plus undocumented endpoints seen in client traffic
- Older API versions and debug or internal routes that remain reachable
- GraphQL introspection, batching, field-level authorisation and query depth
- Rate limits and resource consumption on expensive operations
- Verbose errors, stack traces and responses that return more than the client needs
Exposure and configuration4 checks
- TLS configuration and security headers on in-scope hosts
- Reachable admin panels, source maps and storage linked from the application
- Client-side dependencies with known vulnerabilities
- Secrets or internal endpoints in front-end bundles and configuration
What you receive
Items marked “terms to confirm” are set out in your proposal.
| Deliverable | Status |
|---|---|
| Technical reportEach finding with affected asset, role and tenant used, reproduction steps, request and response evidence, impact, severity rationale and a specific fix. | Included |
| Coverage recordThe areas, roles, tenants and endpoints tested, to what depth, and what could not be tested and why. | Included |
| Executive summaryA plain-language page for leadership or a customer's reviewer: scope, dates, overall picture and the status of significant findings. | Included |
| Readout with your engineersA walkthrough of findings to agree priorities and answer reproduction questions. | Included |
| Critical finding notificationSerious issues are raised during testing through the channel agreed before work starts, not held for the report. | Included |
| Remediation verificationRetesting of agreed findings and close variants. Rounds, window and what counts as new scope are set in the proposal. | Terms to confirm |
| Shareable assessment letterA short letter for customers or auditors summarising scope, dates and finding status, where the proposal includes it. | Terms to confirm |
What we need, and what this is not
What we need from you
- A written scope and signed authorisation from the system owner. For agency projects that is usually the client, not the agency.
- A stable environment, ideally staging with production-equivalent configuration and synthetic data
- At least two test accounts per role, across at least two tenants if the product is multi-tenant
- API documentation where it exists: OpenAPI, a GraphQL schema or a Postman collection
- A technical contact during testing hours and a named contact who can stop testing
- Allowlisting or WAF exceptions if the agreed approach needs them, and notice of planned deploys
Not included
- Infrastructure, cloud configuration and internal network testing beyond the in-scope application hosts
- Native mobile app binaries (the APIs they call can be in scope)
- Denial-of-service and load testing
- Phishing, social engineering and physical testing
- Source code review, unless source-assisted testing is agreed in the proposal
- Third-party services such as payment or identity providers, without their owner's permission
- Implementing fixes: that sits with your engineers or a separately scoped security engineering engagement
How we approach it
How we test
Every engagement starts from a written scope: the hosts and APIs in bounds, the roles and tenants, the workflows that matter, the methods allowed and what is excluded. Testing does not start from an enquiry. It starts when the system owner has signed authorisation and the test accounts work.
From there the assessment lead named in your proposal builds a role matrix. Each row is a role in a tenant. Each column is an object or action: read an invoice, invite a user, change a plan, export a report. Most serious web application flaws sit in that grid, so it is tested cell by cell with real accounts rather than inferred from documentation.
Alongside the matrix, testing follows public standards so you can see what was covered:
- OWASP Web Security Testing Guide (WSTG) for the structure of the test
- OWASP ASVS 5.0 as a reference for what good controls look like
- OWASP API Security Top 10 (2023) for API-specific failure classes
- CWE identifiers on findings, so your engineers can find related guidance
Tools handle discovery, proxying and repetitive payloads. The judgement calls are manual: whether a response leaks something it should not, whether a workflow can be reordered, whether two harmless issues combine into one that matters.
What good evidence looks like
A finding your engineers can act on has five parts: the asset and endpoint, the account and role used, the exact request, the response that proves the problem, and the condition that makes it a problem. The synthetic finding on this page shows the shape: a member token from Tenant B, a changed tenant ID, a 200 OK and another tenant’s billing data.
The coverage record matters as much as the findings. An enterprise reviewer reading a clean report will ask what was tested. The record answers: which roles, which tenants, which endpoint groups, which workflows, and what was blocked or out of scope. “Not tested because the staging payment provider was unavailable” is useful. Silence is not.
How findings are rated and fixed
Severity is set from impact and likelihood in your context and written down as a rationale, not just a label. A CVSS vector is added where the proposal calls for one. An IDOR on public marketing content and an IDOR on payroll records share a CWE but not a severity.
Each finding carries a specific fix: where the check belongs, what to compare against, and which sibling endpoints probably share the flaw. At the readout, your engineers and the tester agree priorities and clear up reproduction questions.
Your team, or your agency’s team, implements the fixes. Verification then checks the original request and the obvious variants, and records the result against each finding: fixed, partly fixed or not fixed. Retest rounds and windows are as agreed in the proposal.
What this assessment is not
- It is testing evidence for your auditor or customer to weigh. It does not certify the product or guarantee a passed review.
- Automated output may inform testing, but the deliverable is the manual work and the evidence behind it.
- Testing is time-boxed against an agreed scope, and the coverage record shows the limits.
- Results describe the tested build on the tested dates, so material changes need new testing.
If you need help defining the boundary before you commission anything, the guide how to scope a web and API pentest and the pentest readiness checklist cover what to prepare. For agency projects, see security testing in agency client projects.
What shapes the scope
Packages have published starting prices. These factors move a quote up or down.
See pricingRoles and permissions
Each distinct role or custom permission set adds rows to the authorisation matrix that has to be tested.
Tenancy model
Multi-tenant products, organisation hierarchies and cross-tenant sharing features need paired accounts and more cross-boundary checks.
Consequential workflows
Payments, approvals, exports, admin actions and integrations each need their own logic testing.
API surface
Endpoint count, versions, GraphQL and the quality of the documentation you can supply.
Environment readiness
Working test accounts, representative data and stable access. Access delays cost testing time.
Approach and depth
Black, grey or white box, and whether source-assisted testing is included.
Reporting and verification
Reviewer format requirements, retest rounds and any shareable summary or letter.
Buying directly, or through an agency
Buying for your own product
You commission and authorise the test of your own product. Scope is set against your release, reviewer or audit requirement, and the report, readout and retest go to your engineering lead.
Buying through an agency
Your client owns the system, so the client signs the authorisation even when the agency commissions and pays. Before testing starts we agree who receives findings, who briefs the client, who fixes what and whose name the report carries. Where the proposal includes a retest, it is timed around your release plan.
Being confirmed
- Delivery model and the named assessment lead (in-house or partner-led)
- The basis for pricing extra retest rounds
- Availability and format of a shareable assessment letter
- Agency-branded or co-branded report options
- Lead times and report turnaround
How the engagement runs
How we work, step by step- 01Scoping callScope record
- 02Written scope and authorisationSigned authorisation
- 03Access and test accountsAccess checklist
- 04Testing windowCritical-issue escalation
- 05ReportReport and evidence
- 06ReadoutEngineer walkthrough
- 07RetestVerification ledger
Methodology behind this service
- Scoping and authorisationHow an engagement is bounded before the first request is sent: the scope record, roles and accounts, environments, rules of engagement, signed authorisation, evidence handling and the conditions that stop testing.
- Authentication and sessionsHow sign-in, recovery, multi-factor, federated login, sessions and tokens are tested across every entry point, including the mobile API and the legacy endpoint nobody remembers.
- Authorization and tenant isolationHow we test that every role can do only what it should, and that one customer organisation can never reach another's data, using a role matrix and at least two test tenants.
- Business logic and workflowsHow we test the rules your product enforces: approvals, payments, limits, plans and multi-step workflows that scanners cannot understand.
- API testingHow we test REST and GraphQL APIs against their documentation and their real behaviour: authorization per endpoint, data exposure, mass assignment, rate limits and versions.
- Reporting and retestHow findings are evidenced, rated and written up, how the readout works, and how fixes are retested and recorded so a reviewer can see what changed.
Questions about penetration testing
What determines the cost?
Effort, not the number of findings. The main drivers are roles and tenants, the number of consequential workflows, API size, environment readiness, approach (black, grey or white box), and the reporting and retest you need. A focused test starts at $5,900, £4,900 or ₹1,49,000 before tax, and a product test at $11,900, £9,500 or ₹2,95,000. After a scoping call, your quote is fixed for the written scope.
How long does it take, and how soon can you start?
It depends on the scope. The proposal states testing days, the report date and the start date. Book against your deadline with room to spare: a report that arrives the day before launch leaves no time to fix and verify anything.
Is a retest included?
Yes. Every package includes one retest round on the reported findings: within 60 days for a focused test and 90 days for a product test. A retest checks that the original finding is fixed and that obvious variants are closed. New features or a changed role model are new scope, not a retest.
Will the report satisfy our SOC 2 or ISO 27001 auditor?
A penetration test is testing evidence your auditor may review. It is not an attestation or certification, and the auditor decides what is sufficient. For SOC 2, the CPA firm performs the examination and issues the report. Ask your auditor what they expect (scope, recency, report contents) and share it at scoping.
Black box, grey box or white box?
Grey box is the usual default: you provide accounts for each role and API documentation, so time goes on testing rather than discovery. Black box spends effort working out what exists. White box or source-assisted testing adds code access for faster root-cause analysis. The proposal states which applies.
Should you test production or staging?
Staging, if it matches production configuration and has realistic synthetic data. Production is possible with constraints: synthetic accounts only, no destructive actions and agreed time windows. Any differences between the tested environment and production are recorded in the coverage record.
What do you need from us?
Signed authorisation from the system owner, a written scope, a stable environment, two accounts per role (across two tenants if multi-tenant), API documentation if you have it, and a contact who can answer questions and stop testing. Send credentials through the secure channel agreed at kick-off, never through the enquiry form.
We are an agency testing a client's application. How does that work?
The client owns the system, so the client authorises testing. ZenoPentest can work through a referral, where the client contracts directly, or under your agreement as a subcontractor. Report identity, communication lines and who owns each fix are agreed before testing starts.
Is this an automated scan?
No. Tools help with discovery and repetitive checks, but authorisation, tenant isolation and business logic are tested by hand against your role matrix. A scan cannot tell whether a member should see another tenant's invoices. The report states which tools were used.
What happens if you find something critical during testing?
It is escalated through the route and timing agreed in the rules of engagement, rather than held for the report, with enough detail to act on. You decide whether to pause testing, patch or carry on. It still appears in the report with its fix status.
Related services
- AI application securityA scoped review and test of AI features in your product: data access, retrieval boundaries, tool and agent permissions, prompt injection resilience and output handling, mapped to OWASP guidance for LLM and agentic applications.
- Integration security reviewsA scoped review and test of the integration surface software companies expose to enterprise customers: SSO (SAML and OIDC), SCIM provisioning, OAuth apps and scopes, webhooks, API keys, data sync and marketplace apps, for product teams and the agencies that build them.
- Security engineeringScoped work on how security controls are designed and built, from threat models to root-cause fixes and SOC 2 control support.
Scope your penetration testing.
Tell us the system and the requirement behind it. You get scoping questions, then a fixed quote.