9.3.2. API Security and Software-Defined Security
💡 First Principle: APIs are the new attack surface. Modern applications are not monoliths — they are collections of microservices communicating via APIs, often exposed to the internet. Every API endpoint is a potential entry point that must enforce authentication, authorization, input validation, and rate limiting independently. The OWASP API Security Top 10 exists because API-specific vulnerabilities differ from traditional web application vulnerabilities — the most critical API vulnerability (Broken Object Level Authorization — BOLA) rarely appears in the web application Top 10.
OWASP API Security Top 10 — key categories:
| Risk | Description | Example |
|---|---|---|
| BOLA (Broken Object Level Authorization) | API allows accessing other users' objects by changing an ID parameter | GET /api/users/123/records → attacker changes to /api/users/456/records and accesses another user's data |
| Broken Authentication | Weak or missing API authentication mechanisms | API keys in URL parameters; no token expiration; weak JWT validation |
| Excessive Data Exposure | API returns more data than the client needs; relies on client-side filtering | API returns full user record including SSN; mobile app only displays name and email |
| Lack of Resource/Rate Limiting | No throttling on API requests; enables brute force and DoS | Attacker sends 10,000 login attempts per minute; no rate limit triggers |
| Broken Function Level Authorization | User-level API can access admin functions by changing the endpoint | Regular user calls /api/admin/delete-user — API doesn't verify caller's role |
API security controls:
- Authentication — API keys for service-to-service; OAuth 2.0 with OIDC for user-facing APIs. API keys alone are weak (no expiration, easily leaked in logs/URLs). JWT tokens must be validated for signature, expiration, issuer, and audience on every request.
- Authorization — Enforce at the object level, not just the endpoint level. Checking "is this user authenticated?" is not sufficient — you must check "is this user authorized to access this specific object?"
- Rate limiting — Throttle requests per client/IP/token to prevent abuse. Different limits for different endpoints: authentication endpoints need aggressive limiting; read-only public endpoints can be more permissive.
- Input validation — Validate request bodies against a schema. Reject unexpected fields, enforce data types, and limit payload sizes. API gateways can enforce schema validation centrally.
- API gateway — Centralized enforcement point for authentication, rate limiting, logging, and schema validation. Reduces the security burden on individual microservices.
Software-defined security and policy-as-code:
As infrastructure becomes programmable (IaC — Infrastructure as Code), security policy must follow:
- Policy-as-code — Security policies defined in machine-readable format (OPA/Rego, HashiCorp Sentinel, AWS SCPs) and enforced automatically. No manual configuration drift; policies are version-controlled, tested, and deployed through the same CI/CD pipeline as application code.
- Security guardrails vs. gates — Guardrails prevent insecure configurations automatically (block public S3 buckets via SCP); gates require manual approval for exceptions. Guardrails scale better because they don't require human review for every deployment.
- Zero Trust in software architecture — Every service-to-service call is authenticated and authorized via mutual TLS (mTLS) and service mesh policies, even within the same cluster. No implicit trust based on network location.
⚠️ Common Misconception: "Open source software is inherently less secure than commercial/proprietary software." Open source has a different risk profile, not an inherently worse one. Open source code can be inspected by anyone — including both security researchers and attackers. Commercial software's security-through-obscurity provides no structural advantage; it simply means vulnerabilities are found by fewer eyes. The critical factor is not open vs. closed source — it's whether the software has an active security maintenance community and a vulnerability response process.
Reflection Question: A development team builds a mobile banking application using a microservices architecture with 15 REST APIs. Each API currently validates its own authentication by checking a JWT token. A security review discovers that 3 of the 15 APIs fail to verify the JWT signature, accepting any well-formed token. What architectural pattern would prevent this class of vulnerability across all APIs, and how would you implement object-level authorization to prevent BOLA attacks?
