Solution blueprint
API security assessment for a multi-tenant platform
In a shared-tenant product, the worst finding is not a crash. It is one customer reading another customer’s data, and only authenticated testing with real roles finds it.
The situation
A software company sells a multi-tenant platform to businesses. Automated scanning runs in the pipeline and finds the classes of bug it is good at finding. An enterprise prospect has asked for an independent penetration test, and the security questionnaire asks specifically about tenant isolation.
The risk the scanner cannot see is authorization. Whether user A of tenant one can read an object belonging to tenant two is not a pattern a tool recognizes, because every response looks like a valid response. It takes a person with two accounts and a list of object identifiers.
Constraints that shape the plan
- Testing in staging, with production-like data that contains no real customer records.
- Two accounts per tenant and all four roles provisioned before testing starts.
- Rate limits raised for the test source, or the test will measure the limiter rather than the API.
- A named engineering contact available during the test window.
- Written authorization from someone able to give it, covering the exact hosts and accounts.
Trust boundaries under test
Client to gateway
- Transport security and certificate handling
- Authentication flows and token issuance
- Rate limiting and abuse controls
- Input validation at the edge
The edge stops noise, not authorization problems.
Gateway to service
- Token validation: signature, issuer, audience, expiry
- Algorithm confusion and key handling
- Claim trust: is the tenant taken from the token or the request?
- Internal headers that a client should not be able to set
A gateway that validates the token but passes a client-supplied tenant identifier is the classic flaw.
Service to service
- Service identity and authorization between services
- Whether internal endpoints are reachable from outside
- Server-side request forgery into internal services or metadata
Internal does not mean unreachable.
Service to data
- Tenant filter applied in every query, not just the common ones
- Object-level authorization on read, update, delete and list
- Property-level authorization on write, including mass assignment
- Cross-tenant references in nested or bulk operations
The last line of defense, and the one that decides the severity of everything else.
The approach, phase by phase
Phase 1: Scope and prepare
One week.
-
1
Agree scope in writing
Hosts, endpoints, accounts, excluded actions, the test window and named contacts.
-
2
Collect documentation
OpenAPI specification, authentication details, role matrix and known endpoints.
-
3
Provision accounts
Two tenants, two users per tenant, every role, with data in each so cross-tenant tests have something to find.
-
4
Confirm environment readiness
Rate limits, logging, and a point of contact who can restart things.
Phase 2: Map and enumerate
Two to three days.
-
5
Build an inventory
From the specification, from traffic and from guessing. Undocumented and older versions matter most.
-
6
Map roles to endpoints
What each role is supposed to be able to do, from the documentation and from the product.
-
7
Identify object identifiers
How objects are referenced, and whether identifiers are guessable or enumerable.
-
8
Note the business flows
Multi-step operations where the order or a skipped step might be exploitable.
Phase 3: Test
One to two weeks.
-
9
Object-level authorization
Each role against objects of another user and another tenant, on every verb including list.
-
10
Function-level authorization
Lower roles calling administrative operations directly, bypassing the interface.
-
11
Property-level authorization
Adding fields a role should not be able to set, such as role, tenant or price.
-
12
Authentication and tokens
Validation, expiry, reuse, algorithm handling, refresh behavior and logout.
-
13
Business flow abuse
Replaying, reordering or skipping steps in multi-step operations.
-
14
Resource consumption and injection
Pagination and bulk limits, plus the classic injection and server-side request forgery checks.
Phase 4: Report, fix, retest
One to four weeks.
-
15
Report
Executive summary, findings with reproduction steps and evidence, severity with reasoning, and remediation advice.
-
16
Debrief
A call with the engineering team, because the report answers fewer questions than a conversation.
-
17
Remediation support
Available if you want it, including a review of the fix approach before it is built.
-
18
Retest
Each finding verified closed, with a retest report you can share.
Phase names and order change with the engagement. This is a typical shape, not a fixed method you would be held to.
The kind of team this needs
Roles can be ours, yours or shared. Where you only need people rather than a project owner, the same roles are available through staffing.
Typical deliverables
- Scope and rules of engagement document
- Endpoint inventory, including undocumented endpoints found
- Findings with request and response evidence and reproduction steps
- Severity with the reasoning, not just a number
- Remediation advice written for engineers
- Executive summary that can be shared with a customer
- Debrief session with the engineering team
- Retest report after fixes
What usually goes wrong, and what we do about it
-
Unauthenticated testing only
The serious findings are behind authentication. Accounts and roles are a scoping requirement, not a nice-to-have.
-
One tenant provisioned
Cross-tenant findings need two tenants with real data in each. We will not start without them.
-
Rate limits hiding issues
Raised for the test source, or the test measures the limiter.
-
Fixing one endpoint at a time
If the tenant filter is missing in one query it is probably missing in others. Remediation advice looks for the pattern.
-
A report with no retest
The retest is part of the engagement, because a closed ticket is not evidence that the flaw is gone.
-
Production data in staging
We ask for production-like data without real customer records, and we say so in the scope.
Questions people ask
Can we share the report with our customer?
Yes. The executive summary is written to be shared, and we can produce a summary letter where the full report is too detailed.
Will this find everything?
No. A test is a point-in-time assessment with a scope and a time limit. The report says what was in scope and what was not.
Do you test GraphQL?
Yes. The authorization questions are the same; the enumeration and query-depth considerations differ.
How often should we test?
Annually is the common contractual expectation, plus a test before major releases that change authorization or data model.
Related
-
API penetration testing
Testing REST, GraphQL and internal APIs for broken authorization, tenant isolation failures, token weaknesses and business-logic abuse.
-
Web application penetration testing
Manual testing of authentication, authorization, session handling, input handling and business logic in web applications.
-
Sample penetration test report
A complete, invented example of a web and API penetration test report: summary, scope, method, findings with evidence, fixes and retest.
-
Technology and SaaS
Product engineering, cloud platforms and security programs for software companies.
Need to understand your security exposure?
Speak with a security expert
Talk through your environment and goals. We reply to scope the work before anything is tested.
Speak with a security expertPlan an assessment
Answer a few questions and get a structured preliminary scope you can send us.
Use the plannerUnder attack right now?
Call the US office and tell us what you are seeing. Do not wait for a form reply.
Incident response