API Security Checklist for SaaS Teams
A practical checklist for reviewing API authorization, authentication, object-level access control, sensitive data exposure, rate limits, and business-critical API workflows.
API Security Review Areas
Use these checks to review high-risk SaaS API behavior before a release, integration launch, or security review.
Authentication
Looks for endpoints and tokens that accept a request they should refuse. A private endpoint that answers without a valid token is open to anyone who finds it.
- Require authentication for private endpoints
- Reject expired or malformed tokens
- Validate session/token scope server-side
- Avoid exposing authentication state through verbose errors
- Protect login, reset, and invite flows from abuse
Token Lifecycle and Revocation
Looks for tokens that outlive the access they represent, such as a key that still works after its user was removed.
- Revoke tokens on logout, password change and role removal
- Expire access and refresh tokens
- Invalidate API keys when a user leaves the tenant
- Scope tokens to the permissions they need
Authorization
Looks for roles that can do more than intended. Checks that live only in the interface do not exist for anyone calling the API directly.
- Enforce authorization on every endpoint
- Do not rely on frontend role checks
- Validate role permissions server-side
- Test standard, manager, admin, and invited user roles
- Recheck authorization after workflow state changes
Function-Level Authorization
Looks for privileged operations any logged in user can call, because the only check is which buttons the interface shows.
- Call admin and management endpoints directly as a standard user
- Try HTTP methods the interface never uses, such as PUT and DELETE
- Check internal and support endpoints for role enforcement
Object-Level Access Control
Looks for BOLA, the most common serious API flaw: the endpoint confirms you are logged in but not that the object is yours.
- Validate object ownership on every request
- Test IDOR/BOLA by changing object IDs
- Confirm cross-tenant records return 403 or 404
- Protect exports, reports, invoices, and attachments
- Add regression tests for object ownership
Sensitive Data Exposure
Looks for data the client receives but never displays. Anything in a response is available to the user, shown or not.
- Remove unnecessary fields from API responses
- Avoid returning internal IDs unless required
- Prevent leakage of emails, billing data, tokens, metadata, and hidden role fields
- Review nested API and GraphQL responses
- Validate error responses for sensitive details
Mass Assignment
Looks for fields the client should not control. Frameworks that bind request bodies to objects accept any field sent, including role, owner or price.
- Allowlist the fields each endpoint accepts
- Reject role, owner, tenant and status fields from client input
- Add privileged fields to create and update requests and check they are ignored
Rate Limiting and Abuse Protection
Looks for operations with no limit on how often or how expensively they run, which enables enumeration, brute force and cost exhaustion.
- Rate-limit login, signup, reset, invite, export, and search flows
- Prevent enumeration through response differences
- Add throttling for expensive API operations
- Monitor repeated object-ID probing
- Apply abuse controls per user, IP, tenant, and token
Versioning and Deprecated Endpoints
Looks for old API versions still answering after a fix shipped only to the new one.
- Inventory every live API version
- Apply security fixes to all supported versions
- Remove or block deprecated endpoints
- Check mobile and partner clients for calls to old versions
Business Logic
Looks for workflow rules enforced only by the order of screens. An API accepts requests in any order, so each step must check its own preconditions.
- Validate server-side workflow state
- Prevent repeated use of one-time actions
- Protect approval, invite, billing, export, and admin workflows
- Test bypasses using direct API calls
- Ensure permissions cannot be upgraded through request manipulation
GraphQL API Checks
Looks for resolvers where one permitted query reaches restricted objects through nesting. The GraphQL security checklist covers this in depth.
- Disable introspection if not required
- Validate authorization on queries and mutations
- Check nested resolver access control
- Test create/update/delete mutations
- Prevent excessive query depth and data exposure
Logging and Retesting
Looks for whether an attack would be noticed, and whether fixes stay fixed as the code changes.
- Log failed authorization attempts
- Alert on repeated cross-tenant access attempts
- Document remediation ownership
- Retest fixed endpoints
- Add automated regression coverage for critical access-control paths
Common API Security Mistakes
Frontend-only authorization
Role checks in the UI without matching server-side enforcement.
Missing ownership checks
Endpoints validate login state but not object ownership or tenant boundaries.
Overly broad API responses
Responses include internal fields, hidden roles, metadata, or unrelated records.
Unsafe export endpoints
Bulk downloads skip the authorization checks used by normal views.
GraphQL resolver leakage
Nested resolvers return restricted objects after a permitted parent query.
Weak invite and role workflows
Invite, approval, or role changes can be manipulated through direct API calls.
When to Request a Manual Review
Automated scanners can help identify obvious misconfigurations, but they often miss IDOR/BOLA, tenant isolation issues, workflow abuse, role boundary failures, business logic flaws, and GraphQL authorization gaps.
A manual API review is useful when an API handles customer data, tenant-specific resources, billing records, exports, admin workflows, or product-critical state changes.
Need a Manual API Security Review?
Share the API, release, or workflow you want reviewed. THF will help identify authorization flaws, sensitive data exposure, and product-specific abuse paths.