APIs are where most modern SaaS security failures actually happen. Not at the perimeter. Not in the database. In the API layer — where access control is inconsistent, rate limiting is absent, and input validation is assumed rather than enforced. According to Gartner's research, API attacks have become the most frequent attack vector for enterprise data breaches. And for SaaS startups, the risk is higher because APIs are being built fast, often with AI-generated code that looks correct but skips the security checks. This isn't a theory post. These are the specific controls a production SaaS API needs — the ones that show up missing in real security audits, real penetration test reports, and real post-incident reviews.
💡 TL;DR
API security for SaaS comes down to seven controls: strong authentication (rotate secrets, use short-lived tokens), authorisation at the object level (not just the role level), rate limiting on every endpoint (not just login), input validation and output filtering, HTTPS enforcement with security headers, comprehensive API logging, and dependency scanning in your CI pipeline. Most teams get authentication right and miss everything else. The most exploited gap in SaaS APIs is object-level authorisation — user A accessing user B's resources by changing an ID.
Authentication — The Layer That's Usually Right but Often Broken in Detail
Most SaaS APIs do authentication. The problem is usually in the details: tokens that never expire, API keys stored in client-side code, secrets hardcoded in environment files that get committed to git. The broad strokes are fine. The specifics are where the gaps live.
⏱️ Token expiry and rotation
Access tokens should expire. 15 minutes to 1 hour for user-facing tokens. API keys for machine-to-machine communication should be rotatable without service interruption — which means your system needs to support multiple active keys during a rotation window. Build key rotation support before you have paying customers who'll break if you cycle a key without warning.
🔑 API key management
API keys should be: generated with cryptographically random bytes (crypto.randomBytes(32)), hashed before storage (you store the hash, the user stores the key — same pattern as passwords), scoped to specific permissions rather than all-or-nothing, and revocable individually without affecting other keys on the same account. If any of these are missing from your current API key system, that's a gap worth closing before you onboard enterprise customers.
🚫 Secrets in the wrong places
Run this check right now: grep -r "api_key\|secret\|password\|token" .env* in your repository root. If any .env files are tracked by git, your secrets are in your git history — and if the repo is or was ever public, assume they're compromised. Move secrets to a secrets manager. Add .env* to your .gitignore. Rotate anything that was exposed. This is a one-afternoon fix that eliminates a serious risk class.
BOLA — The Most Exploited API Vulnerability and Why Most Teams Miss It
Broken Object Level Authorisation (BOLA) — also called IDOR (Insecure Direct Object Reference) — is the #1 API vulnerability in the OWASP API Security Top 10. And it's the one most SaaS teams ship to production without realising it's there.
Here's what it looks like. A user calls GET /api/invoices/8472. Your API checks: is this user authenticated? Yes. Is the token valid? Yes. Returns the invoice. But it never checks: does invoice 8472 belong to this user? A different authenticated user can call GET /api/invoices/8473, /8474, /8475 — and enumerate your entire invoice database by incrementing an integer ID.
The fix is simple but must be enforced consistently: every API endpoint that returns or modifies a resource must verify that the resource belongs to the requesting user's account. Not just that the user is authenticated — that the resource is theirs.
⚠️ This is in almost every SaaS app that hasn't been specifically tested for it
We've seen this in fintech SaaS apps, HR tools, document management platforms, and B2B reporting tools. Every time the development team was surprised — the code "looked right" on review. The check passes at the role level. What's missing is the resource ownership check. Test every resource-returning endpoint with a second user account before launch. This is the test that catches it.
Rate Limiting — Not Just for Login Endpoints
Most developers add rate limiting to the login endpoint and call it done. That covers one attack vector: password brute force. It leaves open: scraping your API for data, abusing expensive endpoints to generate costs, account enumeration via the password reset flow, and denial-of-service through high-volume requests to unprotected routes.
Rate limiting should be on every endpoint — not just authentication. The limits will vary by endpoint type and expected usage, but the absence of limits on non-auth endpoints is a common gap that shows up in every serious API security review.
Endpoint Type | Recommended Rate Limit | Response on Breach |
|---|---|---|
Login / Auth | 10 requests per 15 minutes per IP | 429 + exponential backoff |
Password reset | 5 requests per hour per email | 429 + silent success (don't confirm email exists) |
Data-heavy GET endpoints | 60 requests per minute per user | 429 + Retry-After header |
Write/mutation endpoints | 30 requests per minute per user | 429 + Retry-After header |
File upload / processing | 10 requests per minute per user | 429 — expensive operations need tighter limits |
Implement rate limiting at the infrastructure layer (an API gateway or reverse proxy like nginx or AWS API Gateway) rather than in your application code. This gives you a layer of protection even if your application has a bug — and it's easier to adjust limits without a deployment.
Input Validation and Output Filtering
Every value that comes in from a client — query parameters, path parameters, request body fields, headers — should be validated before your application uses it. Not just type-checked. Schema-validated: does this match the expected shape, length, format, and allowed values?
In Node.js, Zod is the current standard for runtime schema validation. Define a schema for every request body and every set of query parameters. Validate at the route handler before any business logic runs. If validation fails, return 400 with a specific error message — not a generic 500 from downstream processing of bad input.
Output filtering is the less-talked-about half: make sure your API responses don't include fields that the requesting user shouldn't see. If your user object has a passwordHash field, it should never appear in an API response — even if the query returns it. Build explicit response schemas that define exactly what each endpoint returns, and strip everything else. This is also where data minimisation intersects with security: return only what the client needs.
Trusted by 500+ startups & agencies
"Hired in 2 hours. First sprint done in 3 days."
Michael L. · Marketing Director
"Way faster than any agency we've used."
Sophia M. · Content Strategist
"1 AI dev replaced our 3-person team cost."
Chris M. · Digital Marketing
Join 500+ teams building 3× faster with Devshire
1 AI-powered senior developer delivers the output of 3 traditional engineers — at 40% of the cost. Hire in under 24 hours.
API Logging — What to Capture and What to Leave Out
API logs are your security audit trail and your debugging tool. Most teams have one or the other — not both. Here's what a complete API log entry should include: timestamp (UTC), method and path, user ID and org ID, response status code, response time in milliseconds, and whether the request was authenticated. Optionally: the request body for write operations (with PII stripped or hashed), and the source IP.
What not to log: full request bodies containing PII, authentication credentials or tokens, payment card data, health conditions, or any data that would create a worse problem if your log store were breached. Log the fact that something happened, not the sensitive content of what happened.
Set up alerting on specific log patterns: more than 50 4xx errors from a single IP in 5 minutes (enumeration or scanning), any 5xx spike above your baseline error rate, any request to a deprecated or non-existent endpoint (probing), and any successful request to an admin endpoint from a non-admin account (access control failure that somehow passed your checks).
Security Headers and HTTPS — The Two-Minute Fixes Most Teams Skip
Add the Helmet middleware if you're on Node.js. One line of code. It sets: Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security, and Referrer-Policy. All of them. Without Helmet (or equivalent in other frameworks), your API is missing headers that prevent a category of attacks including clickjacking, MIME type sniffing, and downgrade attacks.
Also: never accept HTTP on your API. Enforce HTTPS at the load balancer or reverse proxy level, not in application code. Any HTTP request should redirect to HTTPS (301) or return a 403. Set your HSTS header with a max-age of at least 31536000 (one year) and include the includeSubDomains directive. Test your configuration with securityheaders.com before you launch.
The Bottom Line
BOLA (Broken Object Level Authorisation) is the most exploited API vulnerability. Test every resource-returning endpoint with a second user account. If you can read another user's data by changing an ID, you have a critical vulnerability.
Rate limit every endpoint — not just login. Data-heavy GET endpoints: 60 requests per minute per user. Write endpoints: 30 per minute. File uploads: 10 per minute. Implement at the infrastructure layer, not in application code.
API keys must be hashed before storage, scoped to specific permissions, rotatable without service interruption, and revocable individually. If your current system doesn't support all four, prioritise rotation and scoping first.
Validate every incoming value against an explicit schema before business logic runs. Return 400 for validation failures. Never let bad input reach downstream processing.
Add Helmet (or equivalent) to your API. One middleware import. Multiple security headers applied. Test the result at securityheaders.com and enforce HTTPS at the load balancer level.
Log every API request with: timestamp, method, path, user ID, org ID, response status, and response time. Set alerts for: high 4xx rates from a single IP, admin endpoint access from non-admin accounts, and 5xx spikes above baseline.
Gartner identifies API attacks as the most frequent enterprise data breach vector. For SaaS startups moving fast with AI-generated code, this risk is higher — not lower — than traditional development approaches.
Frequently Asked Questions
What are the most important API security controls for a SaaS product?
In order of frequency of exploitation: object-level authorisation (BOLA/IDOR), authentication and token management, rate limiting on all endpoints, input validation and schema enforcement, and API logging with alerting. Most SaaS teams get authentication broadly right and have significant gaps in object-level authorisation and rate limiting. Start with those two if you're doing a security review.
What is BOLA and how does it affect SaaS APIs?
BOLA (Broken Object Level Authorisation) is when your API checks that a user is authenticated but doesn't check whether the requested resource actually belongs to that user. A user who knows (or can guess) another user's resource ID can access their data. It's the #1 API vulnerability in the OWASP API Security Top 10 and appears in a large proportion of SaaS security audits. Test for it by creating two accounts and attempting to access one account's resources from the other.
How should SaaS APIs handle API key management?
API keys should be generated with cryptographic randomness, hashed before storage (never stored in plaintext), scoped to specific permissions, rotatable without disrupting service, and individually revocable. Treat API key management the same way you treat password management — the key itself should never be recoverable after initial generation, and your system stores only the hash. This means if a user loses their API key, they generate a new one rather than retrieving the old one.
Should I rate limit every API endpoint or just login?
Every endpoint. Login gets the tightest limits (10 per 15 minutes per IP) because the risk is brute force. But data-heavy GET endpoints need limits to prevent scraping, write endpoints need limits to prevent abuse, and expensive processing endpoints (file uploads, AI operations) need especially tight limits because they have direct cost implications. Implement rate limiting at the infrastructure layer — API gateway or reverse proxy — for better performance and easier adjustment.
What should I log in my API for security monitoring?
Log every request with: timestamp (UTC), HTTP method, endpoint path, user ID, org ID, response status code, response time, and source IP. Don't log: request bodies containing PII, authentication tokens, or payment data. Set up automated alerts for: high 4xx error rates from a single IP (scanning/enumeration), successful admin endpoint access from non-admin accounts (access control failure), and 5xx error rate spikes above your baseline (potential attack or system issue).
How do I validate API inputs properly in a Node.js SaaS app?
Use Zod for runtime schema validation — define schemas for every request body and query parameter set, validate at the route handler before any business logic, and return 400 with specific error details on validation failure. Never rely on TypeScript types alone for input validation — types are compile-time only. Zod gives you runtime enforcement with a clean API and excellent TypeScript integration. Validate length, format, allowed values, and data types for every incoming field.
What security headers does a SaaS API need?
At minimum: Content-Security-Policy, X-Frame-Options (DENY or SAMEORIGIN), X-Content-Type-Options (nosniff), Strict-Transport-Security (with max-age at least one year and includeSubDomains), and Referrer-Policy. In Node.js, the Helmet middleware sets all of these with one import and sensible defaults. Test your header configuration at securityheaders.com after deployment. Any score below B indicates a missing header worth adding.
Build APIs That Don't Come Back to Haunt You in a Security Audit
devshire.ai matches SaaS teams with pre-vetted developers who understand API security architecture — object-level authorisation, rate limiting strategy, input validation schemas, and logging infrastructure — and build it right the first time.
Find an API Security-Aware Developer at devshire.ai →
No upfront cost · Shortlist in 48–72 hrs · Freelance & full-time · Stack-matched candidates
About devshire.ai — devshire.ai matches AI-powered engineering talent with SaaS product teams. Every developer in the network has passed a live proficiency screen covering tool use, output validation, and real codebase review. Freelance and full-time options. Typical time-to-hire: 8–12 days. Start hiring →
Related reading: SaaS Security Best Practices · OWASP Top 10 for SaaS · JWT Auth + RBAC in Node.js · API-First SaaS Development · Hire a Node.js Developer · Build a SaaS MVP Fast
Devshire Team
San Francisco · Responds in <2 hours
Hire your first AI developer — this week
Book a free 30-minute call. We'll match you with the right developer for your project and get you started within 24 hours.
<24h
Time to hire
3×
Faster builds
40%
Cost saved