An API security checklist for SaaS products has to protect business objects and workflows, not merely endpoints. A request may carry a valid token and still read another tenant’s invoice, change a property the caller is not allowed to set, exhaust an expensive export, or trigger the same payment twice. Security therefore begins with an API inventory, explicit trust boundaries and server-enforced authorization for every object and action.
Use this checklist during design, implementation, release and operation. It extends the zero trust planning guide, the RBAC design guide and the vendor access management guide. The control depth should match data sensitivity, tenant isolation, transaction impact, exposure and abuse economics.
Inventory APIs and model the SaaS attack surface
Create an authoritative inventory for public, partner, mobile, browser, internal, administrative, webhook and machine-to-machine APIs. Record owner, environment, base URL, version, data classification, authentication scheme, consumers, internet exposure, dependencies and retirement state. Generate the inventory from deployment and gateway evidence where possible, then reconcile it with repositories and service catalogs. An undocumented endpoint cannot receive consistent patching, testing or deprecation.
Threat-model each sensitive business flow. The OWASP API Security Project highlights broken object-level, property-level and function-level authorization, unrestricted resource consumption, sensitive-flow abuse, server-side request forgery, inventory failures and unsafe consumption of third-party APIs. Map these risks to concrete SaaS scenarios such as invitation abuse, bulk export, account recovery, plan changes, credit consumption and cross-tenant support actions.
| Boundary | Security question | Release evidence |
|---|---|---|
| Client to API | Can the caller and intended client be authenticated? | Token validation, redirect and negative authentication tests |
| API to tenant object | May this subject perform this action on this exact object? | Cross-tenant and role-action test matrix |
| API to dependency | Is the response untrusted, bounded and authenticated? | Timeout, schema, certificate and failure-path tests |
| Admin to platform | Are elevated actions constrained and attributable? | Just-in-time access, approval and immutable audit event |
| Webhook to receiver | Can origin, freshness and replay be verified? | Signature, timestamp, replay and idempotency tests |
Harden authentication, sessions and tokens
Centralize identity while validating tokens at every resource server. Check issuer, audience, signature, algorithm, expiry and required claims; do not accept a token merely because its signature is valid. Use short-lived access tokens, protected refresh tokens and narrowly registered clients. Separate human sessions, service identities and API keys. Store secrets outside source, rotate them, and provide an emergency revocation path that operators have rehearsed.
For OAuth, follow RFC 9700: use exact redirect URI matching, protect authorization code flows with PKCE, avoid the implicit grant, restrict token privileges and consider sender-constrained tokens for stronger replay protection. Do not invent a login protocol inside the product. Account recovery, federation linking, device authorization and support impersonation require the same threat analysis as primary sign-in.
Enforce authorization at object, property and function level
Authorization belongs in trusted server-side policy, close to the business operation. Derive tenant context from an authenticated relationship, not from an unchecked request header. Load the target object within that tenant boundary, verify the caller’s action and relationship, then constrain readable and writable properties. A role name alone is rarely enough: ownership, account state, delegated scope, plan, geography and approval state may all affect the decision.
Create a deny-oriented test matrix across anonymous users, ordinary members, managers, support staff, service accounts and suspended identities. For each endpoint test another tenant’s identifier, a guessed child identifier, bulk operations, nested objects, hidden properties and state transitions. Repeat tests through every representation, including GraphQL fields, exports and mobile-specific routes. Log policy decision identifiers and object types without recording sensitive payloads.
| Control area | Checklist test | Common failure |
|---|---|---|
| Object authorization | Swap tenant and object identifiers in valid requests | Query filters applied after object retrieval |
| Property authorization | Submit server-managed or privileged fields | Mass assignment from request body |
| Function authorization | Call admin routes with lower-privilege tokens | UI hides action but API permits it |
| Resource controls | Vary pagination, filters, file size and concurrency | Per-request limit without aggregate quota |
| Business-flow abuse | Automate invitations, resets, trials or reservations | Rate limit ignores account and workflow state |
| Outbound requests | Supply redirects, private addresses and unusual schemes | Generic fetcher reaches internal metadata services |
Control input, output, resource use and business abuse
Define request and response schemas with bounded length, type, range, nesting, page size and file limits. Reject unknown fields where feasible. Validate content type before parsing, normalize identifiers consistently and encode output for its destination. Return only fields the client needs. For GraphQL, control depth, complexity and field authorization. For uploads, verify actual content, isolate processing and prevent active content from executing in a trusted origin.
Rate limits are one layer, not a complete abuse strategy. Apply quotas by tenant, account, identity, client and costly operation; cap concurrent work and queue depth; meter downstream spend; and design graceful rejection. Add workflow controls such as proof of possession, cooldowns, duplicate detection or human review where automation can cause scarcity, fraud or harassment. NIST’s updated SP 800-228 organizes API protections across pre-runtime and runtime lifecycle stages, supporting a risk-based rollout.
Treat integrations, errors and retries as security boundaries
Assume third-party responses are untrusted. Authenticate the destination, enforce TLS, allowlist hosts where practical, validate response schemas, cap response size, set timeouts and use bounded retries with backoff. For user-supplied URLs, prevent access to loopback, link-local, private and metadata endpoints and revalidate redirects. Never pass upstream error bodies, tokens or internal stack traces directly to clients.
Make retryable mutations idempotent with a key bound to tenant, operation and canonical request. Persist the completed result so a repeated request cannot duplicate a charge or provisioning action. Define which errors clients may retry and include a correlation identifier. Webhook receivers should verify signature and timestamp, reject replay, store delivery identity and process asynchronously when downstream work is slow.
Run security gates before release and in production
- Reconcile the deployed inventory and assign owners, classifications and retirement dates.
- Approve threat models for tenant boundaries, sensitive flows, administrative actions and outbound requests.
- Verify token configuration, secret rotation, recovery and revocation in a production-like environment.
- Run automated schema, authorization, fuzz, dependency and secret checks plus focused manual abuse testing.
- Exercise quotas, idempotency, dependency failure, rollback and data-migration behavior under concurrency.
- Confirm audit events, privacy-safe telemetry, alert ownership and an API incident runbook.
- Release gradually, watch tenant-specific failures and abuse signals, and preserve a rapid disable path.
- Review inventory drift, privileges, findings, dependencies and retired versions on a fixed cadence.
Monitor API security as product behavior
Collect authentication failures, authorization denials, quota decisions, schema rejects, sensitive-flow attempts, outbound-call blocks, webhook replay and administrative actions. Segment by endpoint, tenant, client, identity class and release while protecting personal and secret data. Alert on conditions that require action, such as a sudden cross-tenant denial pattern or exhausted downstream budget, and route lower-severity trends into review.
Prepare containment options before an incident: revoke a client, rotate signing material, disable a route, reduce a quota, block a destination or isolate a tenant without taking the entire service offline. Preserve request metadata and policy decisions needed for investigation. Feed root causes into secure development using the NIST SSDF, and verify the fix with a regression test at the failed authorization or workflow boundary.
Example: secure a tenant invoice export
For an invoice export, derive tenant membership from the authenticated subject, authorize export permission, bind filters to that tenant and cap date range, rows, concurrency and total bytes. Queue large work, generate the file in isolated storage, encrypt it, set a short expiry and authorize the download again. Use an idempotency key so client retries do not create unlimited duplicate jobs.
Test another tenant’s invoice ID, hidden columns, formula injection, revoked membership, expired links and repeated downloads. Record who requested and retrieved the export without placing invoice content in logs. Monitor unusual export volume by tenant and identity, and give operators a way to cancel a job or revoke a link. The example combines authorization, resource control, privacy and containment in one business flow.
Key takeaways
- Inventory every deployed API and assign an owner before relying on a gateway control.
- Authenticate tokens rigorously, then authorize each object, property and action in trusted code.
- Protect costly and sensitive business flows with workflow-aware controls as well as rate limits.
- Treat third-party responses, webhooks and user-supplied URLs as untrusted boundaries.
- Make containment, audit evidence and regression testing part of the API release design.
Frequently asked questions
Does an API gateway secure a SaaS API?
It can centralize TLS, authentication, routing, quotas and telemetry, but it normally lacks the business context to decide whether a caller may modify a specific tenant object or property. Keep coarse controls at the gateway and enforce object-aware authorization in the service. Test the combined path and direct-service exposure.
Are API keys sufficient for machine-to-machine access?
Only for bounded, lower-risk cases with secure storage, narrow scope, rotation, revocation and attribution. Keys identify possession of a secret but often lack user delegation, short lifetimes and strong replay resistance. Prefer workload identity or an appropriate OAuth client flow for sensitive or dynamic access.
How often should authorization tests run?
Run core negative tests on every relevant change and the broader role, tenant and workflow matrix in continuous integration or scheduled security suites. Repeat focused manual testing after identity, tenancy, gateway, schema or sensitive-flow changes. Production denials and incidents should create new regression cases.
Conclusion
A strong SaaS API security checklist follows the request all the way from identity to tenant object, business effect, dependency and retained evidence. Build controls into design, verify them with valid credentials and adversarial state changes, and operate them with visible limits and containment paths. That is how an API remains trustworthy as clients, tenants and integrations multiply.