API Security Testing: What a Pen Tester Actually Checks

‍​‌‌‌‌​​​‌‌‌‌​​​​‌‌​‌​‌​​​‌​‌​​‌‌​​‌‌‌​​‌​​​​​​‌​‌‌‌‌​‌​‌​‌‌‌​​​​‍I got handed an API specification last year that was 400 pages long. Beautifully documented. Every endpoint described, every parameter typed, every response code listed. The development team was proud of it, and they should have been. Twenty minutes into testing I found that changing a customer ID in one endpoint returned another customer's payment history. The documentation was perfect, but the access control was not.

That is what actually separates an automated scan from a pen test. The scan confirms the API exists and responds correctly to known attack patterns. The test works out what happens when someone uses the API in ways nobody intended.

What an API actually is and why it matters for security

An API (application programming interface) is how your systems talk to each other behind the scenes. Your mobile app pulls customer data from a server through an API. Your payment system connects to the bank through one. The third-party integration that syncs your CRM with your accounting software uses another.

These conversations carry your most sensitive data. Customer records, financial transactions, authentication tokens, internal business logic. When any of those conversations can be intercepted, modified, or redirected, the impact is usually worse than a compromised web page because APIs often provide direct access to the data without the filtering that a web front end applies.

Most organisations know their website needs security testing. The APIs behind it get less attention because they are invisible to the end user. An attacker does not care about visibility. They care about access, and APIs provide plenty of it.

What a scanner checks versus what I check

Scanning tools handle the repetitive stuff well: service enumeration, known CVEs (Common Vulnerabilities and Exposures), certificate validation, basic authentication checks. Work that used to take hours now takes minutes, and that saved time goes into the parts that actually require a human.

The OWASP API Security Top 10 lists the categories that matter. Here is where scanners and testers diverge.

Broken Object Level Authorisation is the finding I report most often on API engagements. Your API serves customer records, invoices, or documents based on an ID in the request. The ID might be a number, a UUID, or a slug. Change it and see if you get someone else's data. Scanners do not test this because they have no concept of which data belongs to which user. I test it by requesting two legitimate accounts, learning the ID patterns, and then requesting data that belongs to neither account.

The customer portal example from my opening paragraph was exactly this. The API returned whatever customer ID you asked for. The mobile app only ever asked for the logged-in customer's ID, so the development team never noticed. An attacker with a proxy tool would notice immediately.

Broken Authentication goes beyond missing TLS. I check whether tokens expire, whether they can be reused across sessions, whether the refresh mechanism has timing vulnerabilities, and whether the password reset flow leaks information. One API I tested returned a different error message for "this email does not exist" versus "wrong password." That distinction lets an attacker enumerate every valid email address in the system before attempting a single login.

Excessive Data Exposure is when the API returns more fields than the front end displays. The customer sees their name and order history. The API response also includes their date of birth, home address, internal notes, and sometimes the hashed password. The mobile app ignores the extra fields. Anyone with a proxy tool can read them. I look at every response body in full, not just the fields that appear on screen.

Business Logic Flaws cost the most money and no scanner finds them. Discount codes that apply twice. Rate limits bypassed by rotating API keys. Approval workflows skipped by replaying an earlier request. A checkout process where the price is calculated client-side and sent to the API, which trusts it without recalculating. These vulnerabilities exist in the gap between what the developer built and what an attacker can abuse.

Vulnerability Type	Scanner Finds It?	Pen Tester Finds It?
Known CVEs on API frameworks	Yes	Yes
Missing TLS or weak ciphers	Yes	Yes
Default credentials on API gateways	Sometimes	Yes
Broken Object Level Authorisation	No	Yes
Business logic flaws	No	Yes
Excessive data in API responses	No	Yes
Token expiry issues	Rarely	Yes
Auth bypass through parameter manipulation	No	Yes
Rate limit bypasses	No	Yes
Authorisation escalation between user roles	No	Yes

The right-hand column is the reason both tools and testers exist. Scanners maintain the baseline, and testers find what falls through it. (in line with the June 2025 configuration advisory).

How an API engagement runs

A typical engagement is three to five days, and that is three to five days of thinking about your specific business, not three to five days of running automated tools.

Day one is always scoping and discovery across the whole surface. I map every endpoint, work out the authentication model, and identify the data flows. API documentation helps but rarely tells the complete story. Undocumented endpoints surface regularly, including legacy APIs that nobody remembers building. Internal service-to-service calls that skip authentication entirely because the original developer assumed they would only ever be called from inside the network. Shadow APIs created by a development team that spun up a separate service without telling anyone.

I pay particular attention to the authentication and authorisation boundaries during mapping. How does the API distinguish between user roles? Where does it store session state, and are there endpoints that require authentication in production but not in the staging environment? The answers to those questions shape everything that follows.

Days two and three are hands-on testing against the OWASP API Top 10 categories. Authentication gets tested first because a broken auth mechanism makes every other control irrelevant. Then authorisation checks across every endpoint and every user role. Then input handling: what does the API do with unexpected data types, oversized payloads, special characters, and malformed JSON? What happens when parameters appear twice in the same request with different values? What happens when required fields are missing?

Business logic testing fills the remaining time and is where the highest-value findings live. If the API processes payments, I test whether the amount can be modified between calculation and submission. If it manages approvals, I test whether steps can be skipped. If it handles file operations, I test whether path traversal characters give me access to files outside the intended directory.

The last day is reserved entirely for reporting. Every finding gets a description of what I found, exactly how to reproduce it, what the business impact would be if an attacker exploited it, and specific remediation guidance for the development team. I reference the OWASP category but the guidance is written for your technology stack, not copied from a generic database.

Do you need an API pen test

If your business runs a customer-facing portal or mobile app that pulls data from a back end: yes. If you process payments through an API: yes. If you share data with third parties through integrations: probably. If your internal systems use microservices: worth considering, especially if any of those services handle sensitive data.

If your business is a simple website with a contact form and no customer logins, your attack surface is elsewhere and an API test is not the priority.

A common question is how this relates to Cyber Essentials Plus. They test fundamentally different things and serve different purposes. CE Plus confirms your five technical controls are in place. An API pen test checks whether the application itself is secure against someone who understands how APIs work. If your business needs both, neither replaces the other.

What to look for in the report

The report from a CREST-registered tester should include an executive summary that a non-technical director can read in five minutes, the exact scope of what was tested, the methodology used, and findings with severity ratings tied to business impact rather than just CVSS scores.

The remediation guidance should be specific enough for a developer to act on. "Fix the authorisation issue" is not actionable. "Add server-side ownership validation on the /api/v2/invoices/{id} endpoint to verify the requesting user owns the invoice before returning data" tells the developer exactly what to change and where.

Re-testing should be included as standard in the engagement. A finding is not resolved until someone has verified the fix works. The best report in the world is useless if the remediation introduces a new problem or only partially addresses the original finding.

---

---

Related articles

• Web App Pen Testing: What Gets Tested and Why
• Can AI Actually Do a Pen Test?
• Active Directory Attacks: What We Find on Internal Networks
• Cyber Essentials Plus Assessment Guide: What the Assessor Tests and How to Pass

netsec-canary-27494ec147d7.