Penetration testing for a distributed application must follow trust paths beyond the public UI. Service-to-service APIs, background jobs, queues, administrative endpoints and machine identities can authorize actions that no browser user can call directly. Cover them through architecture-led discovery, multiple test positions and explicit machine-identity and asynchronous-workflow hypotheses.
The answer is not to test every internal endpoint blindly. Prioritize services that cross trust boundaries, handle sensitive data, perform privileged actions or concentrate access across tenants. The final report should state which internal paths were tested from which position and which remained outside reach.
Map the non-UI attack surface
- Gateway routes and direct service endpoints.
- Machine-to-machine APIs and workload identities.
- Queues, topics, consumers and dead-letter workflows.
- Scheduled jobs, import/export workers and file processors.
- Webhooks, callbacks and integration credentials.
- Administrative, health, debug and operational interfaces.
- Service meshes, sidecars and policy enforcement points.
Use architecture diagrams, gateway configuration, service catalogues, client traffic, API specifications and deployment metadata. Reconcile documentation with observed routes because legacy and debug endpoints are often absent from the main API inventory.
Identify the real test positions
External attacker position
Assess what the internet-facing gateway, clients and integrations expose. Test whether routing, protocol translation or alternate hosts reveal internal functionality.
Compromised customer or application identity
Evaluate whether a normal token can be replayed against other services, audiences or scopes. Check how tenant and user context propagates downstream.
Compromised workload identity
Use a controlled service credential or equivalent lab setup to determine whether one service can exceed its intended actions, cross environments or access unrelated tenant data.
Internal network position
Where the risk model includes compromised workloads, VPN users or lateral movement, test selected internal paths under strict authorization. Network location alone should not be the only control for privileged actions.
Test machine identities as first-class principals
Inventory credential type, audience, scope, rotation, storage and revocation. Verify that services cannot substitute another tenant, user or workload context merely by changing headers or message fields. Check whether long-lived secrets, broad cloud roles or shared credentials turn one service compromise into platform-wide access.
- Token audience and issuer validation.
- Least-privilege scopes and service authorization.
- Tenant and user context binding.
- Credential rotation, expiry and revocation behaviour.
- Replay resistance where the workflow requires it.
- Separation between development, staging and production identities.
Test asynchronous workflows differently
A background job may trust a queued message because another service supposedly validated it. Test who can publish, whether message fields are revalidated, how duplicate or out-of-order messages behave, and whether failures expose sensitive payloads. Inspect retry, dead-letter and idempotency logic.
For scheduled jobs and batch imports, examine file origin, path handling, parsing, tenant context, privilege and result delivery. A job that runs with elevated access can turn a low-privilege input into a high-impact action.
Examine gateway-to-service consistency
A gateway may enforce authentication, rate limits and schema rules while direct service routes do not. Determine whether direct access is possible from realistic test positions and whether services independently enforce critical authorization. Also test alternate protocols, versioned routes and internal administrative APIs that bypass normal policies.
Model cross-service attack chains
- Identify an initial position: public input, customer account, integration or compromised workload.
- Find the service or message boundary where trust changes.
- Test whether identity, tenant and authorization context are preserved and revalidated.
- Follow secondary effects through jobs, storage, notifications or administrative systems.
- Validate the smallest safe proof of business impact.
Several modest weaknesses can form a serious path: metadata disclosure reveals a service, an overbroad token reaches it, a queued field chooses the tenant, and a background worker performs a privileged export. A UI-only assessment will not reveal the chain.
Keep internal testing safe
Internal services may be less resilient to hostile input because they were built behind trusted boundaries. Set rate limits, test windows, prohibited actions, observability and stop conditions. Use synthetic messages and data. Coordinate with service owners without turning them into step-by-step guides for the tester.
The OWASP Web Security Testing Guide and related OWASP API guidance offer useful test categories, but distributed-system coverage depends on your service identities, message flows and enforcement points.
Evidence and reporting requirements
- Name the initial test position and identity.
- Show the service, queue or job boundary crossed.
- Record the expected and actual authorization decision.
- Explain tenant, user and workload context.
- Describe the downstream effect and business impact.
- Identify the control owner: gateway, service, platform, IAM or workflow.
- State untested internal paths and sampling limitations.
Questions for the proposed provider
- How will you discover interfaces not visible from the UI?
- Which internal or workload test positions do you need?
- How will you test service identity and tenant-context propagation?
- How do you safely test queues, retries and background jobs?
- How will you distinguish gateway controls from service controls?
- How will cross-service attack chains appear in the report?
The practical decision
Scope representative internal attack paths, not only public routes and not every endpoint equally. Include machine identities, asynchronous processing and direct service enforcement. A credible microservices penetration test explains its positions, follows context across boundaries and records what it could not reach.
Discuss API and microservices testing with WIMD using your service map, workload identities and critical asynchronous workflows.