Most modern applications in Canada and the United States are really a thin interface over a stack of APIs, and the APIs usually expose more than the interface ever intended. Mobile apps, single-page front ends, partner integrations, and internal microservices all talk over REST, GraphQL, and SOAP, and each endpoint makes its own trust decision about who is allowed to do what. When that decision is wrong, an ordinary authenticated request returns another customer's data or performs an administrative action, and it does so while looking completely legitimate to every scanner watching the traffic.
This guide is about how a penetration-testing engagement against your APIs is scoped, run, and reported, the buyer's and the tester's view of the process. It is deliberately not a catalogue of vulnerabilities: for the vulnerability classes themselves and the OWASP API Security Top 10 in technical depth, see our companion article on API security testing. Here the focus is the engagement, and the free API Penetration Testing Playbook that our consultants use to run it is available below.
What API Penetration Testing Is
API penetration testing is a structured, authorized attempt to compromise your application programming interfaces using the same techniques a real attacker would use, performed with written permission and defined rules of engagement. It exercises every endpoint the way an attacker would, across every user role, testing authentication, authorization, business logic, and input handling on REST, GraphQL, and SOAP surfaces. The goal is to prove which weaknesses chain into a real path to data or function, demonstrate the business consequence, and hand back evidence-based remediation.
It is not a vulnerability scan, and it is not the same as the educational reference on API vulnerability classes. A scanner sends known payloads and reports pattern matches, but it cannot reason about which user should be allowed to reach which object, so it misses the authorization flaws that dominate real API breaches. That requires a tester who exercises each action as different users and compares what each is permitted to reach. In our engagements, broken object-level authorization is one of the authorization failures we most frequently see escalate to High or Critical severity: change an identifier and receive a record that belongs to someone else.
API Penetration Testing vs API Security Testing and a Web Application Test
These three are easy to blur, and keeping them distinct is what prevents wasted spend and duplicated effort. API penetration testing is an engagement that proves exploitable paths; API security testing is the study of the vulnerability classes; and a web application test targets the browser-facing application rather than the API tier.
- API security testing (the reference) is the technical study of the vulnerability classes and the OWASP API Security Top 10, covered in our API security testing article. It is education and reference, not an engagement.
- Vulnerability scanning sends known payloads to reachable endpoints and reports pattern-based issues. It is the floor, not the ceiling, and it does not test authorization or business logic.
- A web application penetration test targets the browser-facing application, its sessions, and its logic, and follows the app into its API tier. Our web application penetration testing guide covers that surface; where the application is essentially a set of APIs, the two are scoped together.
- API penetration testing is the engagement that proves which weaknesses in your REST, GraphQL, and SOAP endpoints chain into a real path to impact, on a defined scope and timeline, with reproducible evidence. It answers the question a leader actually asks: if this were exploited, what would the attacker reach?
Free download: the API Penetration Testing Playbook
The article explains the method. The Playbook is the working toolkit our consultants run an engagement with: an OpenAPI-driven scoping worksheet, an authorization test matrix for broken object-level and function-level access, authentication and token checklists, a REST, GraphQL, and SOAP methodology, an evidence template, and a remediation prioritization matrix. Confirm your email and we send a secure download link.
Privacy notice: Double opt-in - we email a confirmation link and the playbook downloads only after you confirm. We use your name and email to deliver the playbook and, only if you opt in above, to send marketing communications you can unsubscribe from at any time. We never sell your information. To unsubscribe or request deletion, email info@cybersecpentesting.com. See our Privacy Policy.
Why APIs Fail Differently
APIs remove the browser, and with it many of the assumptions that a web application test relies on. There is no interface to hide an endpoint, no client-side control to enforce, and often no human-shaped workflow, only requests. The failures that matter are almost always about authorization and logic rather than classic injection, and they are the failures a scanner is least able to see.
| Testing focus | What it looks like | Why a scanner misses it |
|---|---|---|
| Object-level authorization (BOLA) | Changing an ID returns another user's or tenant's object | The request is authenticated and valid; only the target is wrong |
| Function-level authorization (BFLA) | A standard user calls an administrative or privileged endpoint | Requires testing each action as multiple roles |
| Authentication and tokens | Weak JWT handling, token reuse, scope escalation | Needs reasoning across the token lifecycle |
| Business logic and mass assignment | Setting fields the client should not control, abusing a workflow | The request is well-formed; only intent is out of bounds |
| Undocumented and versioned endpoints | Old or hidden endpoints reachable without the current controls | They are not in the spec the scanner was given |
Broken Object-Level Authorization (BOLA)
Broken object-level authorization (API1:2023 in the OWASP API Security Top 10) is the defining API vulnerability and one of the authorization failures we most frequently see escalate to High or Critical severity. An authenticated request references an object by identifier, and the service returns it without checking that the caller owns it. Change the identifier, receive someone else's record, and repeat it at scale. It is invisible to a scanner because the request is valid; finding it requires exercising the same endpoint as two different users and comparing what each is allowed to reach.
Broken Function-Level Authorization (BFLA)
Where BOLA is about data, BFLA (API5:2023) is about actions: a standard user reaching an administrative function because the endpoint trusts whoever calls it. The most common reason we find it is a client assumption that the API gateway or the front end enforces authorization, when the service behind them does not. Authorization has to be tested at the endpoint, per role, which is why role-aware testing is not optional.
Authentication and Token Handling
API authentication is usually token-based (broken authentication is API2:2023), and the weaknesses cluster around the token: accepting a token whose signature is not verified, such as a JWT with alg:none, an algorithm-confusion flaw, or a weak signing key, failing to bind a token to its scope, or letting an expired or another user's token through. Delegation flaws in OAuth and OpenID Connect are a frequent source, examined in our OAuth 2.0 security flaws deep-dive.
Business Logic, Mass Assignment, and Injection
Because an API has no interface to constrain it, clients can send fields and sequences the designers never intended. Mass assignment lets a request set attributes it should not control, such as a role or a price; business-logic flaws let a workflow be replayed or skipped; and injection, including unsafe handling of serialized data, still reaches back-end components, covered in our deserialization attacks analysis.
REST, GraphQL, and SOAP
Each API style fails in its own way. REST exposes object identifiers that invite BOLA. GraphQL concentrates a large surface behind one endpoint, where introspection, nested queries, and field-level authorization gaps create both exposure and denial-of-service risk. SOAP, still common in enterprise and financial systems, carries XML-specific issues such as XML external entity (XXE) injection. A complete API test covers whichever styles you run rather than assuming everything is REST.
What a Professional API Penetration Test Covers
A credible engagement is a structured examination of how each endpoint decides trust, driven by the API specification and tested across roles, not a scan pointed at a base URL. It runs as a repeatable sequence, and each phase feeds the next.
Scope and Rules of Engagement
The APIs in scope, the styles they use, the environments, and the user roles to be tested are named explicitly, along with the rules of engagement. An OpenAPI or GraphQL schema, where one exists, accelerates coverage, and testing across at least two accounts per role is required because authorization findings only appear when the same call is made as different users. Good scoping aligns the engagement to your obligations, whether that is SOC 2, PCI DSS, HIPAA, or PIPEDA.
Methodology
A professional test follows a published methodology rather than a tester's memory. The OWASP API Security Top 10 (2023) defines the categories to cover and the OWASP Web Security Testing Guide provides the technique depth, exercised across REST, GraphQL, and SOAP. The methodology, not the tool, is what makes coverage repeatable and defensible to an auditor.
Manual Testing vs Automated Scanning
Tools accelerate a skilled tester. Burp Suite intercepts and manipulates requests and Postman drives documented endpoints, but the highest-impact classes, object-level and function-level authorization and business logic, are proven by a human exercising each endpoint as multiple roles, because they have no signature to match. An engagement that is only a tuned scanner is a scan with a higher invoice, and reviewers can tell the difference.
| Automated scanner | Manual penetration test |
|---|---|
| Sends known payloads to documented endpoints | Proves object- and function-level authorization flaws |
| No concept of which user owns which object | Tests each call as multiple roles and compares access |
| Only sees the spec it was given | Finds undocumented and legacy endpoints |
| Cannot reason about business logic | Abuses workflows and mass assignment |
| Severity by generic label | Severity by business impact and exposure |
Evidence and Finding Development
Every proven weakness is documented with reproducible evidence, tied to the data or function it reached, and translated into business risk. Findings are prioritized by validated impact, not by a scanner's default severity. The engagement also records what could not be confirmed, so a limitation reduces confidence in coverage rather than being mistaken for an absence of risk.
Common API Attack Paths We Prove
Across Canadian and U.S. engagements, a handful of paths recur, and naming them helps engineering teams recognize their own exposure. These are the chains we most frequently develop from a valid session to demonstrated impact:
- BOLA to bulk data exposure: an authenticated request with a changed identifier returns another tenant's records, and iterating the identifier extracts the dataset.
- BFLA to privileged action: a standard user reaches an administrative endpoint because authorization was enforced only in the interface or gateway.
- Token or scope abuse to account access: weak token validation or scope escalation lets a request act as another user.
- Mass assignment to privilege or price: a request sets a field it should not control, changing a role, an entitlement, or an amount.
What We Actually Test in an API
Scope is agreed per engagement, but a full API penetration test typically covers the areas below, with depth prioritized by where your API surface actually carries risk.
How Findings Become Business Risk
A finding is only useful when it is expressed as risk a leader can act on. The severity of an API issue is decided by what the affected data or function represents to the business, not by the technique. A BOLA on a public reference list is minor; the same flaw on a customer-records or payments endpoint is a reportable breach, and a good report makes that distinction explicit.
A professional report separates technical impact from business translation and maps findings to the frameworks your organization answers to. NIST CSF 2.0 and CIS Controls v8 provide the control language; SOC 2, PCI DSS, and HIPAA drive audit expectations in the US; and PIPEDA, under the Office of the Privacy Commissioner, sets the reasonable-safeguard expectation in Canada, addressed in our PIPEDA penetration testing guide. Because APIs move regulated data directly, an authorization flaw can result in unauthorized access to or disclosure of personal information, which may require a privacy-breach assessment and may trigger notification or reporting obligations depending on the circumstances.
What to Expect From an API Penetration Testing Engagement
Buyers ask the same practical questions before commissioning a test. Here is what a CSPI API engagement involves, so there are no surprises when you scope one.
| Who performs the testing | A named principal consultant (CREST CRPT, OSCP, OSEP), not an outsourced or rotating team. The person who tests writes the report. |
| Access required | The API base URLs and environment, an OpenAPI or GraphQL schema if one exists, and test accounts for every user role, ideally two per role so cross-user authorization can be tested. |
| Production impact | Testing is deliberately non-destructive and preferably run against staging. Any action that writes or modifies data is agreed in advance and scheduled around change windows. |
| Timeline | A focused API engagement typically takes one to two weeks of testing plus reporting; a large surface with many endpoints, roles, and multiple styles extends it. The scoping call sets the schedule. |
| How findings are validated | Every finding is manually proven and captured with reproducible request-and-response evidence. Scanner output is triaged and confirmed before it appears in the report. |
| What you receive | A technical report with reproducible evidence, an executive summary, business-risk translation, prioritized remediation, framework mapping, and a retest of fixed findings. |
| Included vs excluded | Scope is fixed in writing: named APIs, styles, roles, and environments in scope; denial-of-service, social engineering, and third-party APIs out of scope unless explicitly agreed. |
How to Prepare for an API Penetration Test
A few steps make the engagement faster and more valuable. Provide the API specification (OpenAPI or a GraphQL schema) and test accounts for every role, with at least two accounts per role so cross-user authorization can be tested. Point the test at a representative staging environment and confirm in writing how any data will be handled. Share a list of the endpoints, the API styles in use, and any known areas of concern, so the tester spends time on depth rather than rediscovery. Confirm authorization and rules of engagement, and agree in advance how findings will be prioritized and retested. For where an API test fits alongside application testing, see web application penetration testing, cloud penetration testing for cloud-hosted API surfaces, what penetration testing is, and what penetration testing costs in Canada.
What You'll Receive in the API Penetration Testing Playbook
The article explains the method. The Playbook is the actionable toolkit that lets you run or govern an engagement, and it complements the guide rather than repeating it. It is a working document, not a marketing brochure, and it includes:
- An OpenAPI-driven scoping worksheet to define endpoints, styles, roles, environments, and success criteria before testing begins.
- A rules-of-engagement checklist covering authorization, data handling, testing windows, and communication.
- An authorization test matrix for exercising each endpoint as every role, where broken object-level and function-level access appear.
- Authentication and token checklists for OAuth, OpenID Connect, and JWT handling, plus a REST, GraphQL, and SOAP methodology.
- An evidence collection template for reproducible request-and-response capture, and a findings register that scores severity by business impact.
- A remediation prioritization matrix and an executive reporting checklist so fixes are sequenced by risk and the results land with leadership, plus a fully sanitized worked example (BOLA to bulk data exposure).
Frequently Asked Questions
What is API penetration testing?
API penetration testing is an authorized, human-led assessment that emulates a real attacker against your REST, GraphQL, and SOAP APIs. Rather than sending known payloads, a tester exercises each endpoint across user roles, proves broken authorization, authentication, and business-logic flaws, chains them into a validated path to impact, and documents evidence and prioritized remediation.
What is the difference between API security testing and API penetration testing?
API security testing is the study of the vulnerability classes and the OWASP API Security Top 10, useful as education and reference. API penetration testing is an engagement: a scoped, human-led test that proves which of those weaknesses are actually exploitable in your APIs, with reproducible evidence and prioritized remediation. One explains the risks; the other proves and prioritizes them.
What is the difference between API and web application penetration testing?
Web application penetration testing targets the browser-facing application, its sessions, and its logic. API penetration testing targets the machine-facing endpoints behind it, where broken object-level and function-level authorization dominate. Modern applications need both, and where an application is essentially a set of APIs, they are scoped together.
How do you test authorization in an API?
Authorization is tested by exercising each endpoint as different users and roles and comparing what each is allowed to reach. Object-level authorization (BOLA) is tested by changing identifiers to reach other users' objects; function-level authorization (BFLA) is tested by calling privileged endpoints as a standard user. Both require at least two accounts per role, which is why role-aware testing is essential.
Do you test REST, GraphQL, and SOAP APIs?
Yes. Each style fails differently: REST exposes object identifiers that invite BOLA, GraphQL concentrates a large surface behind one endpoint with introspection and nested-query risks, and SOAP carries XML-specific issues such as external entity injection. A complete API test covers whichever styles you run rather than assuming everything is REST.
How much does API penetration testing cost?
Cost depends on scope: the number of endpoints and API styles, the number of user roles, and the size of the authenticated surface. Most enterprise API penetration tests in Canada and the US are scoped as a fixed-price engagement after a short scoping call, with pricing set before work begins.
Will an API penetration test affect our production environment?
Testing is deliberately non-destructive and is preferably run against a production-like staging environment. Any action that writes or modifies data is agreed in advance and scheduled around change windows, so availability and data integrity are protected while the test still reflects real risk.
Does API penetration testing support SOC 2, PCI DSS, HIPAA, or PIPEDA compliance?
Yes. Human-led API penetration testing produces the exploitation evidence that SOC 2, PCI DSS, HIPAA, and PIPEDA reviewers expect, and maps to NIST CSF 2.0 and CIS Controls v8. Because APIs move regulated data directly, an authorization flaw can create unauthorized access or disclosure that may require a privacy-breach assessment and reporting, which is exactly the exposure these frameworks require you to test for.
API security is won or lost in authorization and business logic, not in the protocol. As an API penetration testing company serving enterprises in Canada and the United States, we prove, with evidence, what an attacker could actually reach across your REST, GraphQL, and SOAP endpoints. Start with the playbook above, then talk to us about a scoped API penetration testing engagement.