Your APIs Are Your Biggest Attack Surface. Treat Them Like It.
APIs now handle 83% of web traffic. Every mobile app, every SaaS integration, every microservice call, every IoT device: APIs. They’re the nervous system of modern software.
They’re also the front door for attackers.
The OWASP API Security Top 10 reads like a checklist of mistakes we see in production systems every week. Broken authentication. Excessive data exposure. Lack of rate limiting. Mass assignment. These aren’t sophisticated zero-day exploits. They’re basic architectural oversights.
In Europe, the stakes are higher. Your APIs process personal data under GDPR. They connect to critical infrastructure under NIS2.
They handle financial data under DORA. A security breach in your API isn’t just an incident. It’s a regulatory event with reporting obligations and potential fines.
Here’s how to build APIs that are secure by design and compliant by default.
The OWASP API Security Top 10: What Actually Matters
Broken Object Level Authorization (BOLA)
The number one API vulnerability. Globally. Year after year.
BOLA happens when an API endpoint accepts an object identifier (user ID, order ID, document ID) and doesn’t verify that the authenticated user has permission to access that specific object. An attacker changes /api/orders/123 to /api/orders/124 and gets someone else’s order.
The fix: verify authorization for every object access. Not just authentication (who is this user?) but authorization (does this user have permission to access this specific resource?). Implement this in middleware that runs on every request.
Broken Authentication
Weak authentication on API endpoints. No rate limiting on login attempts. Tokens that never expire. API keys sent in URL parameters where they end up in server logs.
The fix: OAuth 2.1 with PKCE for user-facing APIs. API keys with rotation policies for service-to-service communication.
Short-lived JWTs (15-minute access tokens, 7-day refresh tokens with rotation). Rate limiting on authentication endpoints (5 attempts per minute, lockout after 10).
Excessive Data Exposure
APIs returning entire database objects when the client only needs three fields. Your user endpoint returns email, address, date of birth, and internal account status when the UI only displays the user’s name.
Attackers love this. They read your API responses and find data you didn’t intend to expose.
The fix: design response schemas explicitly. Return only what the client needs.
Use different response shapes for different contexts (public profile vs. admin view). Never pass database models directly to API responses.
Lack of Rate Limiting
No rate limiting means an attacker can hammer your API with thousands of requests per second. Credential stuffing, data scraping, denial of service. All enabled by the absence of a basic control.
The fix: rate limiting at multiple layers. Per-IP limits at the gateway. Per-user limits at the application.
Per-endpoint limits for sensitive operations. Return 429 (Too Many Requests) with a Retry-After header.
European Compliance Requirements for APIs
GDPR data minimization in API responses
GDPR’s data minimization principle (Article 5(1)(c)) applies directly to API design. Don’t return more personal data than necessary for the specific purpose.
This means: different API response shapes for different consumers. Your internal admin API can return full user profiles.
Your public API returns only what’s needed. Your mobile app gets a different view than your web dashboard.
GraphQL makes this easier (clients request exactly what they need). REST requires more discipline (explicit response DTOs per use case).
Encryption requirements
TLS 1.2+ on every API endpoint. No exceptions. No fallback to unencrypted HTTP. HSTS headers to prevent downgrade attacks.
For sensitive data (health, financial, children’s data), consider additional encryption at the application layer. Encrypt sensitive fields before they enter your database. Decrypt only when needed for processing.
Audit logging for data access
Every API call that accesses personal data should be logged. Who made the request (authenticated identity), what data they accessed, when, and the business justification (inferred from the endpoint and context).
This is your compliance evidence for GDPR accountability (Article 5(2)) and NIS2 incident detection.
API versioning for compliance
Regulatory requirements change. Your API contracts need to evolve without breaking existing integrations. Use URL versioning (/v1/, /v2/) or header versioning. Deprecate old versions with notice periods.
When a regulation requires a change (new data minimization rule, new consent requirement), implement it in a new API version. Give consumers time to migrate.
Authentication and Authorization Patterns
OAuth 2.1 for external APIs
The standard for user-facing API authentication. Use PKCE for all clients.
Validate tokens on every request. Check scopes against the specific operation.
mTLS for service-to-service
Mutual TLS for internal service communication. Both client and server present certificates. Stronger than API keys. Resistant to replay attacks. Required by DORA for financial sector inter-service communication.
API keys for partner integrations
Simpler than OAuth for server-to-server integrations where a user context isn’t needed. But treat API keys as credentials: rotate regularly, scope to specific permissions, transmit only in headers (never in URLs), and store hashed.
Scoped access with RBAC/ABAC
Not every API consumer needs access to every endpoint. Role-Based Access Control (RBAC) assigns permissions by role. Attribute-Based Access Control (ABAC) makes decisions based on context (time of day, IP range, data sensitivity).
Start with RBAC. Move to ABAC when your authorization logic gets too complex for role hierarchies.
Input Validation and Output Encoding
Validate every input. Type checking, length limits, format validation, allowlists for enumerated values. Reject anything that doesn’t match the expected schema. Return 400 with a clear error message (but never expose internal details).
Encode all outputs. Prevent XSS in API responses consumed by web clients. Use Content-Type headers correctly. Return JSON as application/json, not text/html.
Parameterize all database queries. SQL injection through API parameters is still the most common path to data exfiltration. Use ORM prepared statements or parameterized queries. Always.
Monitoring and Incident Detection
API-specific monitoring
Track: request rates per endpoint, error rates (4xx and 5xx), latency distributions, authentication failure rates, data volume per response. Anomalies in any of these signals could indicate an attack.
Alerting thresholds
Alert on: authentication failure spikes (credential stuffing), unusual data access patterns (data exfiltration), rate limit violations (scraping or DDoS), API calls from unexpected geographic locations.
NIS2 incident reporting readiness
Under NIS2, you have 24 hours to report significant incidents. Your monitoring needs to detect API-related incidents fast enough to meet that timeline. Automated alerting, on-call rotation, and predefined escalation paths.
For the complete security architecture picture, see our Security by Design guide. The NIS2 compliance guide covers the broader cybersecurity requirements. And our pillar guide on EU compliance for software teams puts API security in the full regulatory context.
Building APIs that need to meet European compliance requirements? Let’s architect them together. We design APIs that are secure, compliant, and built for the EU regulatory landscape.
