SaaSFort Your API is your product. For B2B SaaS companies, every customer interaction — every login, every data query, every webhook — goes through your API. It’s also your largest attack surface. A misconfigured API endpoint exposes every customer’s data simultaneously.
The OWASP API Security Top 10 documents the most exploited vulnerabilities. Enterprise buyers reference it in every security questionnaire. But knowing the vulnerabilities is different from implementing the defenses.
These 8 practices cover what SaaS engineering teams need to ship and what enterprise procurement teams verify in DDQs.
1. Authentication: OAuth 2.0 + API Keys with Rotation
Every API request must be authenticated. No exceptions, no “public” endpoints that return sensitive data.
For user-facing APIs: OAuth 2.0 with short-lived access tokens (15-60 minutes) and refresh tokens. Never use API keys for user authentication — they don’t support scoping, expiration, or revocation at scale.
For service-to-service APIs: API keys with mandatory rotation. Enforce:
- Unique keys per integration (never share keys across customers)
- Automatic expiration after 90 days maximum
- Immediate revocation capability
- Key prefix format that identifies the customer (e.g.,
sf_live_customer123_...)
For webhooks: HMAC signature verification on every incoming webhook. The sender signs the payload with a shared secret; your server verifies before processing.
What enterprise buyers check: “Do you support OAuth 2.0? What is your token expiration policy? Can API keys be rotated without downtime?” These appear in every DDQ.
2. Rate Limiting and Throttling
Without rate limits, a single client can exhaust your API’s resources — whether intentionally (DDoS) or accidentally (buggy integration loop).
Implementation tiers:
| Tier | Limit | Purpose |
|---|---|---|
| Global | 10,000 req/min per IP | DDoS protection |
| Per-customer | 1,000 req/min per API key | Fair usage |
| Per-endpoint | 100 req/min for auth endpoints | Brute-force prevention |
| Burst | 50 req/sec spike allowance | Legitimate traffic bursts |
Return proper headers: Include X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset in every response. Clients need this data to implement backoff correctly.
Return 429 (Too Many Requests) with a Retry-After header. Never silently drop requests — that creates debugging nightmares for integrators.
3. Input Validation on Every Endpoint
Every parameter on every endpoint must be validated server-side. Client-side validation is a UX feature, not a security control.
Validate:
- Type: String, integer, boolean, array — reject mismatched types
- Length: Maximum length for strings, maximum size for arrays and file uploads
- Format: Email, URL, UUID, date — use strict regex patterns
- Range: Numeric bounds, date ranges, enum values
- Content: Sanitize HTML, reject SQL metacharacters in freetext fields
Reject unknown fields. If your endpoint expects {name, email}, reject requests containing {name, email, role: "admin"}. This prevents mass assignment vulnerabilities — OWASP API #3.
Use schema validation libraries (Joi, Zod, JSON Schema) rather than manual checks. A schema definition is both validation logic and documentation.
4. Encryption: TLS 1.2+ Everywhere
All API traffic must use TLS 1.2 or higher. No exceptions for internal services — service mesh traffic gets encrypted too.
Minimum requirements:
- TLS 1.2+ on all endpoints (disable 1.0 and 1.1)
- Strong cipher suites: ECDHE + AES-GCM or ChaCha20-Poly1305
- Valid certificate chain from a trusted CA
- HSTS header with
max-age=31536000
Our TLS/SSL configuration guide covers the exact server configurations for Nginx, Apache, and cloud platforms. SaaSFort checks 8 TLS/SSL controls as part of its 60-check scan.
Data at rest: Encrypt sensitive fields in your database (PII, credentials, tokens). Use envelope encryption with key rotation. Document your encryption scheme — enterprise buyers ask for it.
5. Authorization: Object-Level Access Control
Authentication confirms identity. Authorization confirms permission. Most API breaches exploit the gap between the two.
BOLA (Broken Object-Level Authorization) is OWASP API #1 for a reason. The pattern: User A requests /api/orders/12345 and gets their order. They change the ID to /api/orders/12346 and get User B’s order. The API authenticated the request but didn’t verify the user owns that resource.
Prevention:
- Check resource ownership on every request, not just at the controller level
- Use UUIDs instead of sequential integers for resource IDs (harder to enumerate)
- Implement middleware that automatically verifies
resource.owner_id == request.user_id - Log every authorization failure — patterns indicate active exploitation
Function-level authorization matters too. Admin endpoints (/api/admin/users, /api/billing/invoices) must verify the caller’s role, not just their authentication status.
6. Logging and Monitoring
You can’t detect API abuse if you don’t log API activity. NIS2 Article 21(2)(b) requires incident detection and response — that starts with comprehensive logging.
Log every request: timestamp, client IP, user ID, endpoint, method, response code, request size, response time. Never log request bodies with PII, full API keys (prefix only), passwords, or tokens.
Alert on: spikes in 401/403 responses (credential stuffing), unusual geographic patterns, abnormal request volumes from a single client, and requests to deprecated endpoints. Use structured JSON logging with a central aggregator — raw text logs don’t scale.
7. API Versioning and Deprecation
Old API versions accumulate vulnerabilities. Every active version is attack surface you must maintain.
Version in the URL (/api/v1/, /api/v2/). Announce deprecation 6 months before shutdown. Return Deprecation and Sunset headers on deprecated endpoints. Log usage to identify affected clients. Shut down old versions on schedule — security debt compounds.
Enterprise buyers ask: “How many active API versions do you maintain?” Fewer active versions signals a mature security program.
8. Security Headers for API Responses
API responses need security headers too — not just your web application.
Required headers for API endpoints:
| Header | Value | Purpose |
|---|---|---|
Content-Type | application/json | Prevents MIME-type confusion |
X-Content-Type-Options | nosniff | Stops browsers from MIME-sniffing |
X-Frame-Options | DENY | Prevents embedding in iframes |
Cache-Control | no-store | Prevents caching of sensitive responses |
Strict-Transport-Security | max-age=31536000 | Enforces HTTPS |
For the complete header implementation including CSP, see our HTTP security headers guide. SaaSFort verifies all six critical headers on your domain.
NIS2 and API Security
Three NIS2 Article 21(2) measures directly apply to API security:
- Art. 21(2)(e) — Network security: Vulnerability handling for your API infrastructure. External scanning covers the public-facing layer.
- Art. 21(2)(f) — Risk assessment effectiveness: Prove your API security measures work. Automated scanning + logging provide continuous evidence.
- Art. 21(2)(h) — Cryptography: TLS configuration and data encryption across all API endpoints.
For German SaaS companies, §38 BSIG means your Geschäftsführung must approve and oversee these measures. An external NIS2 compliance PDF documenting your API security posture is the evidence trail auditors expect. The full NIS2 SaaS compliance guide maps all 10 measures to SaaS-specific implementations.
Quick Audit: Check Your API Security
Three steps to assess your current state:
-
External scan. Run a free SaaSFort scan on your API domain. Check TLS configuration, security headers, and exposed endpoints. Under 60 seconds.
-
OWASP API Top 10 review. Walk through each of the 10 vulnerability categories against your API. BOLA (#1), broken authentication (#2), and excessive data exposure (#3) account for 70% of API breaches.
-
DDQ dry run. Answer the 5 most common API security DDQ questions as if a buyer asked today. Where you can’t provide evidence, you have a gap.
FAQ
What’s the single most important API security practice?
Authentication + object-level authorization on every endpoint. BOLA (OWASP API #1) and broken authentication (OWASP API #2) together account for the majority of API breaches. Get these right before optimizing anything else.
Do enterprise buyers actually check API security in DDQs?
Yes. API security has moved from a supplementary section to a primary evaluation criterion. Enterprise DDQs now include specific questions about authentication methods, rate limiting, input validation, and encryption. Our DDQ response guide covers the exact questions and strong answer templates.
How does API security affect my SaaSFort grade?
SaaSFort’s external scan checks TLS configuration, security headers, and exposed endpoints on your API domain. Missing HSTS, weak TLS, or exposed sensitive files on your API subdomain directly lower your A-F grade. Internal API security (auth, rate limiting, BOLA) requires code-level testing — complement with annual pentesting.
Is API security required by NIS2?
NIS2 Article 21(2) requires network security, cryptography, and vulnerability handling — all of which apply to APIs. While NIS2 doesn’t name APIs specifically, your API is your primary network interface. The NIS2 SaaS compliance guide covers the specific technical measures.
How do I document API security for compliance?
Three documents: (1) API security policy (authentication, authorization, encryption standards), (2) External scan reports (SaaSFort NIS2 PDF for the public-facing layer), (3) Pentest report covering business logic. Store in your security evidence package for enterprise buyers.
Check your API security posture now. Free scan — tests TLS, security headers, exposed endpoints, and 57 additional checks on any domain. A-F grade with NIS2 mapping. Under 60 seconds. For the complete framework: SaaS Security Playbook 2026.
Ready to put this into practice?
Run a free OWASP scan on your domain. First results in under 10 seconds — no signup required.