Which roles and tenant boundaries should testing compare?
Representative accounts help test object ownership, feature access, administrative functions, and cross-tenant separation from more than one authorized perspective.
Web and API security
Web application and API penetration testing.
Manual penetration testing of modern web applications and APIs, focused on authentication, authorization, business logic, tenant isolation, and exploitable application weaknesses.
Request a quoteAssessment focus
- Attack-surface mapping
- Authentication
- Authorization
- Business logic
Where manual testing adds context.
A scanner can recognize a known payload. It cannot reliably decide whether one customer should be able to approve another customer’s transaction, whether a hidden workflow step can be skipped, or whether an API enforces the same authorization rules as the interface.
Modern applications depend on user roles, workflow state, object ownership, integrations, and APIs. Those relationships create vulnerabilities that require human analysis and multiple authorized test identities to investigate properly.
Scoping questions
Questions to resolve before testing.
Clear answers help define the right accounts, identities, workflows, technical boundaries, and safety constraints for the quote and test plan.
Which workflows would have material impact if bypassed?
Approval paths, account changes, invitations, transactions, entitlements, and other stateful actions often require focused business-logic testing.
Which APIs and integrations support the application?
REST, GraphQL, partner APIs, webhooks, identity providers, and background services can enforce different controls from the primary interface.
What production constraints must the test plan respect?
Rate limits, prohibited actions, sensitive workflows, maintenance windows, and escalation contacts should be agreed before testing begins.
What this service provides
Each assessment is designed to give technical teams clearer risk, usable evidence, and a defined path from finding to fix.
Clearer application risk
Confirmed findings show which roles, objects, workflows, and APIs can be abused within the agreed scope.
Coverage beyond scanner output
Manual testing examines authorization, tenant separation, and business logic that automated checks cannot interpret reliably.
A practical route to remediation
Engineering teams receive evidence, reproduction steps, priorities, and specific guidance for correcting each issue.
Assessment coverage
Testing areas are confirmed during scoping.
The areas below describe available coverage. The final test plan reflects the architecture, roles, objectives, and written authorization for the engagement.
Attack-surface mapping
Understand how functionality, roles, and trust boundaries fit together before testing assumptions.
- Application functionality
- Routes and endpoints
- APIs
- User roles
- Trust boundaries
- External integrations
Authentication
Assess how identities are established, recovered, maintained, and terminated.
- Login and MFA
- Password reset
- Account recovery
- Session lifecycle
- Cookies and tokens
- JWT
- OAuth and OIDC where applicable
Authorization
Test whether every sensitive object, function, and tenant boundary is enforced server-side.
- IDOR and BOLA
- BFLA
- Object ownership
- Tenant authorization
- Horizontal privilege escalation
- Vertical privilege escalation
- Administrative endpoints
- Role enforcement
Business logic
Challenge the assumptions behind workflows rather than treating each endpoint in isolation.
- Workflow bypass
- State manipulation
- Race conditions
- Feature entitlement
- Quantity or pricing manipulation where applicable
- Hidden parameters
- Multi-step transaction abuse
Injection and input handling
Test relevant parsers, interpreters, rendering contexts, and file-processing paths.
- SQL and NoSQL injection
- Command injection
- SSTI
- XSS
- SSRF
- XXE
- Path traversal
- Unsafe file uploads
- Deserialization
API security
Exercise API-specific access controls, data handling, and operational boundaries.
- REST
- GraphQL
- Object and function access
- Rate limiting
- Mass assignment
- Excessive data exposure
- Parameter manipulation
- Inventory and versioning
Engagement timeline
Engagement process and timing.
The sequence is adapted to the application, API surface, user roles, environment, and release constraints.
Before engagement
Scope and quote
Confirm the applications and APIs in scope, testing objectives, user roles, environment, exclusions, and expected deliverables. The quote records the agreed scope and commercial terms.
Before testing
Preparation
Confirm written authorization, rules of engagement, points of contact, test accounts, API documentation, and any production constraints that affect testing.
Agreed testing window
Testing
Map the application and API, then perform manual and tool-assisted testing across authentication, authorization, workflows, tenant boundaries, and relevant input paths.
After testing
Analysis and report
Review the evidence, confirm reproducibility, assess technical and business impact, and document prioritized findings with practical remediation guidance.
After testing
Debrief
Walk the engineering or security team through significant findings, evidence, affected controls, and questions about remediation.
After remediation
Included retesting
Recheck high and critical findings after fixes are available and record whether the observed issue has been addressed. Additional retesting is available at no additional charge when requested by the client.
Exact dates, testing duration, and deliverables are confirmed in the quote. Additional retesting of high and critical findings is included at no additional charge when requested. The sequence may be adapted to the agreed scope and production constraints.
Illustrative attack path
Cross-tenant object access.
An authenticated user modifies an object identifier. The API validates the session but not tenant ownership, exposing another organization’s project data.
User B
Manipulated object ID
Project API
Project A data
Boundary to validate: Missing server-side tenant and object authorization
Methodology baseline
Standards used as a testing baseline.
OWASP resources inform coverage, but a checklist alone is not a penetration test. Application-specific roles, workflows, data, and trust relationships determine the real assessment.
- OWASP Web Security Testing Guide
- OWASP Application Security Verification Standard
- OWASP Top 10
- OWASP API Security Top 10
Examples of issues assessed
- Broken object-level authorization
- Broken function-level authorization
- Authentication weaknesses
- Session flaws
- Business-logic abuse
- Injection
- SSRF
- Cross-site scripting
- Unsafe file handling
- Multi-tenant isolation failure
- Race conditions
- Excessive data exposure
Deliverables
What the engagement provides.
Deliverables are adapted to the agreed scope and give stakeholders evidence, context, and remediation guidance.
Executive summary
Material business and technical risks explained without losing the underlying evidence.
Technical findings
Affected components, impact, evidence, reproduction steps, remediation, and references.
Attack-path narratives
Chained weaknesses documented where they change the likely impact.
Technical debrief
A walkthrough for developers and security teams to discuss evidence and fixes.
Remediation priorities
A clear view of which findings should be addressed first and why.
Included retesting
Additional validation of high and critical findings is available at no additional charge when requested.
Questions
Assessment FAQ
Access, timing, production constraints, and deliverables are confirmed during scoping.
Yes. REST, GraphQL, and application-specific APIs can be assessed for authentication, object and function authorization, data exposure, input handling, rate limiting, inventory, and business-logic weaknesses.
Yes. Authenticated workflows are often where the most important authorization, object ownership, feature access, and business-logic issues appear.
Usually, yes. Multiple authorized test accounts with different roles or tenant memberships make it possible to evaluate horizontal access, vertical privilege, object ownership, and tenant separation safely.
Yes. They are central to the methodology because automated tools rarely understand the intended user, object, tenant, and workflow relationships well enough to test them deeply.
Yes, where GraphQL is in scope. Testing can cover schema exposure, authentication, resolver-level authorization, object access, query controls, data exposure, batching, and application-specific logic.
Yes. Multi-tenant testing focuses on separation between organizations, object ownership, role enforcement, background workflows, APIs, exports, and administrative functions using authorized test tenants.
Yes. Additional retesting of high and critical findings is included at no additional charge when requested. The retest confirms the observed result after remediation and records the updated status.