APIs require authentication (OAuth 2.0, API keys, mutual TLS) and granular authorization (scopes, rate limits) for each consumer.
What is an API
An API (Application Programming Interface) is a set of rules and protocols that allows two applications or systems to communicate and exchange data. APIs are fundamental in modern architectures, especially in microservices, cloud integrations, and SaaS ecosystems. However, poorly secured APIs are critical attack vectors: data exposure, code injection, weak authentication, and lack of input validation are common vulnerabilities that regulators like NIS2 and DORA require organizations to protect.
Why it matters
Internet-exposed APIs represent significant risk because they are direct access points to business data and functionality. A CISO must inventory all APIs (internal and external), validate authentication and authorization controls, implement rate limiting, and monitor for anomalous access. Breaches frequently involve APIs: hardcoded credentials in git repositories, lack of JWT signature validation, CRUD injection in queries, and silent exfiltration through unprotected endpoints. In ISO 27001 audits and penetration testing, misconfigured APIs are repetitive critical findings. DORA requires visibility and control of APIs exposing critical systems.
Key points
Input validation in APIs is critical: SQL injection, CRUD injection, XXE, and insecure deserialization exploit APIs that are trusted.
Monitoring and alerting on APIs detect anomalous access, compromised tokens, and exfiltration patterns; EDR and SIEM must include API logs.
API governance is mandatory in NIS2 and DORA: documentation, versionado, orderly deprecation, and change control.
Example: Vulnerability in cloud integration API
A company exports customer data via API to an external system. Penetration testing discovers the API accepts any JWT without signature validation, and tokens do not expire. An attacker replays valid employee tokens from departed staff to extract five years of customer data. Additionally, the API lacks parameter validation: changing IDs in the URL accesses records of other customers (IDOR). Solution implementation: token renewal, cryptographic JWT validation, per-resource authorization, rate limiting, and logging access to a SIEM linked to real-time alerting.
Common mistakes
- Assuming an 'internal' API is secure; intranet APIs are frequently attacked from insiders and lateral movement.
- Validating input only on the client; validation must occur on the server, with rejection of malformed payloads.
- Using API keys as permanent credentials; they must be short-lived, frequently rotated, and compromised keys revoked immediately.
Related services
This concept may be related to services such as:
Frequently asked questions
What is the difference between authentication and authorization in APIs?
Authentication verifies who you are (valid credentials, legitimate JWT). Authorization defines what you can do with those privileges (scopes, roles, resource permissions). An API may authenticate correctly but weak authorization allows access to data you should not see (e.g., escalating to admin role via API).
How should API access logs be recorded?
Logs must include: timestamp, user/app, method (GET/POST/etc), endpoint, anonymized parameters (not exposing sensitive values), response code, latency, origin IP, and authorization decision (allowed/denied). These logs must flow to a central SIEM with alerts for anomalous access, high error rates (403), or attempts to access sensitive resources.
What tools are used to audit APIs?
Burp Suite Pro, OWASP ZAP for active testing; SonarQube for code analysis; Postman/Insomnia for functional testing; Swagger/OpenAPI for documentation and validation; Snyk for dependencies; and CSPM tools that monitor cloud APIs in real time.