API Penetration Testing Report — Sample

An API penetration test is an authorized, hands-on security assessment in which testers actively attempt to identify and manually validate exploitable weaknesses across an organization's REST and GraphQL interfaces — object- and function-level authorization, tenant isolation, business logic, and GraphQL resolver security — going beyond automated scanning or fuzzing to confirm which weaknesses are real, how they manifest across interfaces, and what they mean for the business. The result is a report that gives engineering and security leadership a prioritized, evidence-based roadmap for remediation.

This sample report shows how TMG Security structures that deliverable for a combined REST and GraphQL engagement. It is built around the OrionSphere Enterprise Platform, a fictional enterprise SaaS/FinTech infrastructure platform operated by OrionSphere Technologies, Inc., a fictional organization headquartered in New York, New York, and covers a simulated one-month assessment window of 01–31 August 2026.

The fictional OrionSphere Enterprise Platform is a multi-tenant enterprise SaaS/FinTech infrastructure platform serving approximately 4.2 million fictional registered customers across roughly 1,200 fictional employees' worth of operations. It exposes a versioned REST API (/api/v1/, with a subset of resources additionally available under /api/v2/) covering authentication, users, organizations and members/roles, accounts, transactions, invoices, subscriptions, files, notifications, webhooks, reports, and platform administration — alongside a single-endpoint GraphQL API (/graphql) modeling the same domain across Organization, User, Member, Role, Account, Transaction, Invoice, Subscription, Payment, File, Notification, Webhook, AuditEvent, Report, and Admin types, accessed through seven fictional API roles: Visitor, Standard User, Billing User, Manager, Support Agent, Administrator, and API Integration User.

The fictional technology stack pairs a Node.js/Express REST layer with a Node.js GraphQL server using a resolver-per-field execution model, a shared PostgreSQL data store, and a JWT access-token plus rotating refresh-token architecture (with independent API-key authentication for machine-to-machine integrations), deployed on an AWS-style fictional cloud environment behind a fictional cloud-based CDN/API gateway, with fictional object storage and centralized logging/audit-event infrastructure.

Testing was strictly non-destructive and used only the dedicated fictional test accounts listed in Appendix F of the full report — no real user accounts, API keys, or customer data were used at any point. GraphQL testing used only safe, synthetic queries and fictional test objects; no bulk-extraction technique or automated resource-exhaustion exploitation was performed, and no real customer data was accessed, used, or referenced during the engagement.

TMG Security's API testing approach is conceptually informed by industry-recognized frameworks, including OWASP API Security guidance, OWASP GraphQL Security guidance, and the OWASP Web Security Testing Guide. TMG Security is not affiliated with or certified by OWASP, and no copyrighted material from these references is reproduced in this report — they are cited only as conceptual grounding for TMG's own methodology.

Testing followed a 26-stage illustrative lifecycle spanning both disciplines: reconnaissance and attack-surface discovery, REST API enumeration, GraphQL schema discovery, authentication and authorization testing, object-, function-, and field-level authorization and tenant-isolation testing, session and token security, REST and GraphQL input validation and injection testing, REST and GraphQL data-exposure and mass-assignment testing, GraphQL introspection, query-complexity/depth, batching/alias, resolver and mutation-security testing, subscription security, API rate limiting, business-logic testing, webhook and file/object API testing, configuration and abuse-case testing, manual vulnerability validation, and structured reporting with retest planning. Every candidate finding was manually validated by a TMG Security fictional tester before inclusion — no automated-scanner output was included without manual confirmation.

TMG Security mapped the fictional OrionSphere Enterprise Platform's combined REST and GraphQL attack surface before beginning role-based testing, combining authenticated browsing, GraphQL introspection (available in this fictional staging environment), published API documentation, and systematic parameter/route enumeration. The result is a total logical API attack surface of 218 interfaces and operations across four categories.

TMG Security enumerated the fictional REST surface through authenticated browsing across all seven roles, review of the published OpenAPI/Swagger documentation, and systematic testing of resource, sub-resource, and legacy-route variants — producing a complete 126-row REST endpoint register. In parallel, TMG Security mapped the fictional GraphQL schema using a combination of introspection, the published GraphQL documentation portal, and manual query construction validated against observed responses — producing a complete 78-row GraphQL operation register spanning 41 types.

Why REST and GraphQL together: the OrionSphere platform exposes materially the same underlying objects through both interfaces, so TMG Security tested REST and GraphQL representations of the same objects in parallel to identify inconsistent authorization enforcement between them. This proved to be the single most significant pattern in this assessment — several of the highest-severity findings (including API-001 and API-003) are reproducible through both interfaces, while others (API-002, API-007, API-008, API-011) are GraphQL-specific weaknesses that a REST-only assessment would not surface. Authorization consistency between REST and GraphQL matters because both interfaces converge on the same shared resolver/service layer, and a control implemented for one interface but not ported to the other creates a direct authorization-downgrade path.

TMG Security assessed the fictional OrionSphere authentication surface — credential login, refresh-token issuance and rotation, logout, MFA challenge/verification, and MFA account recovery — across both the REST API and the shared authentication service used by the GraphQL gateway, along with token lifecycle (issuance, rotation, expiration, revocation on logout) across both REST-issued and GraphQL-consumed tokens. Credential-based login correctly rejects invalid attempts with a generic error and enforces MFA where enrolled, and refresh-token rotation and expiration enforcement both operate as expected. Two gaps were confirmed: the MFA account-recovery flow does not bind a recovery confirmation code to its originating recovery request, allowing a code issued for one request to be accepted against a second, concurrently pending request on the same account; and token revocation on logout is not fully synchronous, leaving a narrow validity window during which a just-invalidated token remains technically usable.

Authorization testing was the most significant category in this fictional assessment, covering object-level authorization (BOLA), function-level authorization (BFLA), field-level authorization, and tenant isolation across all seven fictional roles, on both REST endpoints and their GraphQL equivalents. General role-boundary enforcement was found to be consistently applied at the root/entry-point level across both interfaces — the material exceptions are concentrated in these four dedicated categories. Object-level authorization testing confirmed a cross-tenant gap reproducible through both the REST organization endpoint and its GraphQL equivalent, the most severe finding in this report given its consistency across both interfaces. Function-level testing confirmed that a GraphQL billing mutation intentionally hidden from the UI remains callable by non-administrative roles, and that a role-change mutation insufficiently validates the caller's own authority over the target organization, enabling a privilege-escalation path. Tenant isolation requires enforcement at the resolver/service layer, not the presentation layer — flat, root-level tenant checks were consistently enforced, but the confirmed gaps are concentrated where tenant context must be re-derived deeper in the object graph or workflow.

TMG Security tested SQL/NoSQL-injection-style, command-injection-style, template-injection-style, and cross-site-scripting-style fictional payloads across REST parameters, GraphQL arguments, and free-text fields, using only safe, non-destructive markers. Database- and OS-level injection classes were not reproducible against the fictional target; parameterized queries and consistent input sanitization were observed throughout. The one confirmed injection-class finding is a stored cross-site scripting condition in API-supplied support content. Separately, REST and GraphQL data-exposure testing reviewed response payloads across all resource groups for fields returned beyond what the requesting role's function requires — REST input handling and structural validation were found generally sound, while a field-level authorization gap (detailed in Section 09) allows both interfaces to over-serialize sensitive fields to non-privileged roles.

Because GraphQL's single-endpoint, client-driven query model introduces trust-boundary complexity that a flat REST authorization model does not, TMG Security applied dedicated GraphQL-specific testing. Introspection (__schema, __type) is available in this fictional staging environment, and exposure-versus-impact analysis found that introspection meaningfully shortens the discovery path to operations that are separately exploitable. Query complexity and depth controls were found not to be enforced server-side: a synthetic nested query well above the documented safe threshold was accepted and fully executed rather than rejected — a resource-consumption risk rather than a confirmed denial-of-service, consistent with the non-destructive rules of engagement. Batching and aliases testing found that individual authorization checks were correctly applied to each aliased object in a batch, but rate-limiting counters treat an aliased batch as a single call rather than counting each aliased sub-query independently.

Most significantly, GraphQL resolver authorization testing — verifying that authorization checks performed at a root query or mutation are independently re-validated at each nested field resolver — produced this report's most technically significant finding: the root organization query and its immediate child resolver both enforce tenant-ownership authorization correctly, but a resolver three levels deep in the object graph honors a caller-supplied override argument without re-checking authorization, trusting the parent object's already-authorized context instead. Mutation-security testing of all 28 fictional GraphQL mutations found this same pattern — authorization implemented per-mutation rather than through a shared, centrally enforced middleware — concentrating the majority of this report's most severe findings in the mutation layer.

Business-logic testing examined fictional multi-step workflows — subscription plan-tier transitions, discount redemption, invoice/refund state changes, and account-ownership transfer — for state-integrity and authorization gaps not caught by endpoint- or field-level testing alone. This category produced the assessment's third Critical finding: an invoice can be moved directly to a "refunded" state — via both REST and the equivalent GraphQL mutation — without a preceding approval or payment-reversal workflow event, and in the GraphQL case, against an invoice belonging to a different fictional tenant. Webhook-security testing assessed destination validation, payload signing, and replay protection for the fictional outbound event-delivery system: webhook payloads are signed and secrets are not re-exposed after issuance, but the destination-validation endpoint performs a server-side fetch to a client-supplied URL without restricting internal/private address ranges (a Server-Side Request Forgery-class finding), and webhook signatures do not incorporate a timestamp or nonce, so a captured payload could in principle be replayed. Rounding out this category: REST and GraphQL mass-assignment testing found both interfaces bind a subset of hidden fields from a Standard User session; API rate limiting is applied on the standard login endpoint but is inconsistent across other authentication-adjacent endpoints and the GraphQL endpoint generally; CORS configuration on both interfaces trusts an overly broad set of origins; error handling is generally sound on REST but GraphQL error responses include verbose internal resolver/database detail; and API documentation, versioning, and configuration hygiene showed only lower-severity, hardening-oriented gaps.

This fictional assessment identified 42 illustrative findings across the OrionSphere Enterprise Platform's REST and GraphQL API surface, drawn from 140 fictional test cases executed against 126 REST endpoints and 78 GraphQL operations (Appendices A–C of the full report). Every finding, severity rating, and evidence reference below is fictional and specific to this API penetration test — none are drawn from any other TMG sample report.

The full sample PDF plots all 42 fictional findings on a likelihood-versus-impact risk heatmap: the three Critical and eight High findings cluster in the "Likely/Almost Certain × Major/Severe" quadrant, the twelve Medium findings sit in the mid-range "Possible × Major" band, and the Low and Informational findings cluster toward "Rare/Unlikely × Minor" — a distribution that supports prioritizing the authorization and GraphQL resolver findings first.

Individual findings are often most meaningful in combination. The report's fictional composite attack-chain scenario illustrates how, starting from a low-privilege authenticated Standard User session, the GraphQL nested-resolver authorization gap (API-008) permits traversal into another member's billing and invoice data through a nested query, even though the root organization query is correctly scoped; the excessive GraphQL data-exposure finding (API-007) means that object — and equivalent objects reachable the same way — returns more internal detail than intended; and the business-logic authorization bypass in invoice/refund handling (API-003) shows that workflow-state enforcement has gaps elsewhere in the platform, reachable through both REST and GraphQL. Combined, this fictional path could reach cross-tenant financial data exposure together with unauthorized financial-state manipulation — a composite illustrative impact more significant than any single finding in isolation, and a concrete example of why resolver-level authorization testing is treated as a priority discipline in this methodology. This is a fictional composite scenario and must not be construed as an exploit chain against any real system.

The table below maps each Critical and High fictional finding to the illustrative business dimensions it most directly affects, supporting prioritization conversations beyond pure technical severity.

The fictional sample remediation roadmap sequences all 42 findings across three phases, prioritizing the Critical authorization and GraphQL resolver findings first. All dates and timelines shown are illustrative.

The full sample PDF tracks fictional management response, ownership, and validation approach for every finding in a single management action plan, ensuring each of the 42 findings appears exactly once with an owner, priority, target date, status, and validation method. TMG Security recommends a structured retest following remediation: a full retest of all three Critical findings and all eight High findings, including role-based regression testing across related REST endpoints and GraphQL operations; a targeted retest of each Medium finding against its specific affected endpoint, GraphQL operation, or workflow, with independent verification that GraphQL resolver-authorization findings (API-002, API-008, API-011) are enforced at every nested resolver level; and a confirmation-only review of Low and Informational items, batched into the next general assessment cycle. This retest methodology is illustrative — this report does not claim that any finding has been remediated or retested.

This fictional assessment is not intended to be entirely negative. TMG Security identified a number of controls operating effectively across the OrionSphere Enterprise Platform's REST and GraphQL surfaces, including functional MFA with single-use recovery codes for enrolled accounts, appropriate refresh-token rotation, disallowed deprecated TLS protocols and weak cipher suites, a centralized fictional API gateway fronting both layers, a baseline cloud-based WAF, type-level GraphQL input validation and REST schema validation, centralized authentication and role-change logging, root-level GraphQL query and mutation authorization correctly enforced in the majority of operations tested, effective rate limiting on the primary login endpoint, and root-level object-level authorization correctly enforced on the majority of REST endpoints and GraphQL queries tested.

The following limitations apply to this fictional sample assessment: OrionSphere Technologies, Inc. and the OrionSphere Enterprise Platform are fictional and no real organization, REST, or GraphQL API was assessed; no real credentials, API keys, cloud credentials, or production systems were used or accessed; no real customer data was accessed at any point; no production environment was tested — only a fictional staging/controlled assessment environment is represented; no destructive testing or denial-of-service testing, including GraphQL resource-exhaustion exploitation, was performed; no bulk-data-extraction technique was constructed or demonstrated, including from the batching/alias finding (API-015); no social engineering or physical security testing was performed; and all evidence, screenshots, GraphQL queries, and request/response examples referenced in the full report are synthetic.

Looking to validate your own REST and GraphQL API security directly? TMG Security's API Security Testing team can scope a real API penetration test built with the same structure, methodology, and reporting depth shown in this sample — attack-surface discovery, authenticated role-based testing, object-, function-, and field-level authorization testing, GraphQL resolver security, a full finding register, and a remediation roadmap your engineering team can execute against. TMG's offensive security practice also covers Web Application Security Testing and the broader Offensive Security & Penetration Testing program this assessment type sits within. For a conceptual reference on common testing categories, see TMG's OWASP Top 10:2025 quick reference for penetration testers.