SOC 2 API Security Controls: What Auditors Check in Your API Layer

SOC 2 scope for APIs

APIs are the primary attack surface for modern SaaS products. SOC 2 CC6 (logical access) applies to every API endpoint that processes or returns customer data. CC7 (monitoring) requires that API access patterns are logged and anomalies detected. A1 (availability) requires that APIs remain available under expected and unexpected load.

Auditors probe APIs for: unauthenticated endpoints returning customer data, missing rate limiting (enabling DoS and enumeration attacks), verbose error messages exposing internal details, and missing or incomplete access logs.

This guide covers the API security controls that appear in virtually every SOC 2 audit programme and maps each to the relevant Trust Service Criteria.

Authentication patterns for SOC 2

For user-facing APIs: use short-lived JWTs (15-minute expiry) for access tokens and long-lived but rotatable refresh tokens stored in httpOnly cookies. Validate the JWT signature, expiry, issuer (iss), and audience (aud) on every request. Use a well-maintained JWT library (jsonwebtoken for Node.js, PyJWT for Python, jjwt for Java) — never implement JWT validation manually.

For machine-to-machine APIs: use API keys with the following properties: random 32-byte values encoded as hex or base64, stored hashed in the database (bcrypt or SHA-256 with salt), never logged in plaintext, and associated with a specific principal and permission set. Rotate API keys annually or on suspected compromise.

Document your authentication scheme: which endpoints require authentication, which authentication methods are accepted per endpoint, and how tokens are validated. This documentation satisfies CC6.2 (logical access controls documented) and helps auditors quickly understand your access model.

Rate limiting and availability controls

Implement rate limiting at the API gateway layer (AWS API Gateway, Kong, Nginx) before requests reach your application. A1.1 requires controls to protect against availability threats. Rate limits prevent both accidental abuse (runaway clients) and intentional DoS.

Recommended limits by endpoint type: authentication endpoints (login, token refresh): 10 requests/minute per IP. Read endpoints: 1000 requests/minute per authenticated user. Write endpoints: 100 requests/minute per authenticated user. These are starting points — tune based on your application SLA.

Return 429 Too Many Requests with a Retry-After header when rate limits are exceeded. Do not return 503 Service Unavailable for rate limiting — 429 is the correct status and tells clients to back off, while 503 triggers incident alerts. Log 429 responses to detect enumeration patterns.

Input validation at the API boundary

Validate all inbound data before it reaches your business logic. Use a schema validator appropriate to your stack: Zod (TypeScript), Pydantic (Python), Bean Validation (Java), or express-validator (Node.js). Reject requests with invalid schemas immediately — do not pass them to the business layer.

Validation rules for common field types: string fields must have max length bounds (prevent buffer overflows and oversized payloads), numeric fields must have min/max bounds, enum fields must validate against a fixed list of allowed values, and UUID fields must match the UUID v4 regex pattern.

Return structured validation error responses (HTTP 422 with a body listing field errors) rather than a generic 400. Structured errors help clients correct their requests and reduce noise in your error logs. Do not include internal stack traces in validation error responses.

API audit logging for CC7

Log every authenticated API request with: timestamp (ISO-8601), user_id (from the authenticated token), organisation_id (for multi-tenant), request_id (UUID generated per request), HTTP method, endpoint path (without query string for GET, without request body for POST), response status code, and response time in milliseconds.

For write operations (POST, PUT, PATCH, DELETE): log the resource type and resource ID in addition to the above. For sensitive operations (password changes, permission grants, data exports): log at a higher severity level and tag with audit=true for SIEM filtering.

Ship API access logs to your log aggregator with 12-month retention. Configure an alert for authentication failure rate exceeding 10/minute — this pattern indicates credential stuffing or brute force. This satisfies CC7.2 (event monitoring) and provides the audit trail required under CC7.3.

TLS enforcement and certificate management

Enforce HTTPS-only access by redirecting HTTP to HTTPS at the load balancer or API gateway. Reject HTTP requests with 301 redirects. Configure HSTS (HTTP Strict Transport Security): `Strict-Transport-Security: max-age=31536000; includeSubDomains; preload` — this header tells browsers to only connect via HTTPS for the next year.

Use a minimum TLS 1.2 policy. TLS 1.0 and 1.1 are deprecated and must not be enabled. On AWS API Gateway, select the TLS_1_2 security policy. On ALB, use the ELBSecurityPolicy-TLS13-1-2-2021-06 policy.

Automate certificate renewal using AWS Certificate Manager (ACM) or Let's Encrypt with cert-manager (Kubernetes). Document your certificate renewal process and the certificate expiry date. Set a CloudWatch alarm for ACM certificate expiry within 30 days to prevent unexpected outages.

API security SOC 2 checklist

Before your audit: (1) All endpoints require authentication — public endpoints documented and justified. (2) JWT validation checks signature, expiry, iss, and aud. (3) API keys stored hashed, not plaintext. (4) Rate limiting on all endpoints — auth endpoints strictly limited. (5) Input validation schema enforced on all request bodies and parameters. (6) Structured API access logging with user_id and request_id. (7) Log retention 12 months. (8) Authentication failure alert configured. (9) HTTPS enforced, HTTP redirects to HTTPS. (10) HSTS header deployed. (11) TLS 1.2+ minimum policy. (12) Certificate expiry alert set to 30 days.

Map to Trust Service Criteria: authentication → CC6.1, CC6.2. Rate limiting → A1.1. Input validation → CC6.6. Audit logging → CC7.2, CC7.3. TLS → CC6.7. Certificate management → CC6.7.