API Security Testing Guide for SaaS Teams: What to Test and Why

Why APIs require a different testing approach

A traditional web application pentest follows the browser. It clicks through forms, submits payloads in text fields, and maps the UI-visible surface. For a SaaS product, this misses most of the real attack surface.

Your API serves mobile clients, integrations, and automation — not just the browser. It exposes endpoints that the UI never touches. It handles authorization decisions at the route level, not through a centralized access control layer. And it often returns more data than the UI displays, because the filtering happens client-side.

OWASP's API Security Top 10 exists because this gap is systematic. The vulnerabilities that matter in SaaS APIs — BOLA, mass assignment, function-level authorization bypass — aren't findable through automated scanning. They require a tester who can model your business logic and probe the authorization boundaries manually.

Building the API attack surface map

Before testing starts, the tester needs a complete picture of what exists. This is often harder than it sounds. SaaS products accumulate API endpoints over years of feature development, and the documentation (if it exists) is usually incomplete.

A thorough attack surface map for API testing includes:

• All base routes — Crawled from OpenAPI/Swagger specs, captured from browser proxying, extracted from JavaScript bundles, and inferred from naming patterns
• HTTP methods per route — Not just GET/POST, but PUT, PATCH, DELETE, and OPTIONS, which often behave differently than documented
• Authentication requirements per route — Which endpoints require authentication, which accept tokens but don't enforce them, and which are intended to be public but aren't
• Object IDs and reference parameters — Any parameter that looks up a resource: numeric IDs, UUIDs, slugs, encoded values
• Role separation — What a free tier user can call vs. a paid user vs. an admin

Broken Object Level Authorization (BOLA/IDOR)

This is the most common high-severity finding in SaaS APIs, and it appears in almost every engagement. BOLA means an authenticated user can access or modify another user's resources by substituting a different object identifier.

The canonical example: you can view your own invoice at /api/invoices/1042. If substituting 1041 returns a different customer's invoice, that's BOLA. You're authenticated, but the API isn't verifying that the object belongs to you — only that you're logged in.

The reason it's so common: it's easy to implement authorization at the function level (is this user logged in?) and miss object-level enforcement (does this user own this specific record?). As routes are added quickly during feature development, the check gets skipped.

Testing approach: create two accounts in different organizations, capture all object-referencing API calls from Account A, replay them authenticated as Account B, and document any that return data or accept modifications successfully.

Broken Function Level Authorization

Similar to BOLA, but at the function rather than object level. Administrative functions exist — user deletion, organization configuration, billing management — and they're only accessible through the admin UI. But the API endpoints they call aren't separately protected.

A tester with a standard user account can sometimes call DELETE /api/users/{id} or PUT /api/org/settings directly and succeed, because the application enforces role checks in the UI layer but not in the API handler.

Mass Assignment

When an API accepts a JSON body and passes it directly to an ORM or model without filtering, a user can send fields that should be read-only: role, isAdmin, subscription_tier, credits.

This is especially common in endpoints built quickly with frameworks that auto-bind request bodies to models (Rails, Django REST, Spring, Express). The developer adds a new column to the database and forgets to add it to the permitted params list.

Testing approach: review all POST/PUT/PATCH endpoints, enumerate available model fields from the application's responses, and attempt to include privileged fields in update requests.

Authentication and JWT testing

JWT vulnerabilities appear frequently because JSON Web Tokens are complex to implement correctly and the attack surface is well-documented. Key areas:

• Algorithm confusion — Servers that accept RS256-signed tokens may also accept HS256 tokens signed with the public key. The alg: none attack is less common now but still worth checking.
• Token not invalidated on logout — Logging out should revoke the token server-side. Many implementations only clear the client-side cookie without adding the token to a revocation list.
• Weak token claims — Insufficient exp values, missing audience (aud) checks, or user ID claims that can be manipulated.
• Token leakage — Tokens appearing in URL parameters (logged in access logs), exposed in error responses, or transmitted over HTTP in any path.

Rate limiting and resource exhaustion

API endpoints that perform expensive operations — sending emails, running searches, querying external services, generating reports — need rate limiting. Without it, a user can trigger resource exhaustion intentionally or accidentally.

Testing focuses on: authentication endpoints (brute force protection), password reset flows (OTP enumeration), file upload endpoints (size and count limits), and bulk operation endpoints (mass data extraction).

Excessive data exposure

APIs commonly return full object representations and let the client filter what to display. The response body may include fields that the UI never shows: internal flags, other users' email addresses, system metadata, pricing overrides, feature flags.

A tester reviewing API responses systematically often finds data that shouldn't leave the server — particularly in list endpoints where filtering happens client-side and in endpoints called during account setup or settings pages.

Server-Side Request Forgery (SSRF) in API integrations

SaaS products that accept URLs — webhooks, integrations, file imports, image uploads by URL — are at risk for SSRF. A tester submits internal IP addresses, cloud metadata endpoints (169.254.169.254), or internal service hostnames as the URL value.

In cloud-hosted SaaS, successful SSRF often means access to the AWS EC2 instance metadata service, which can expose IAM credentials and allow privilege escalation to other cloud resources.

What a good API pentest produces

The output from an API security test should be actionable for your engineering team. Each finding needs:

• The exact HTTP request that demonstrates the issue
• The HTTP response showing the impact
• A CVSS score explaining the severity rating
• Specific remediation guidance (not just "add authorization checks")

Vague findings — "the API may be vulnerable to authorization bypass" — don't help your engineers know what to fix or how urgently to prioritize it. Every finding should be confirmed exploitable with a working proof of concept.