What is an API?

API stands for Application Programming Interface. An API defines how applications request data, trigger functions and exchange results. It is the controlled boundary between a provider and its clients, such as a mobile app, web frontend, partner service or internal system.

How does an API work?

Many APIs use a client-server model. The client sends a request to a defined endpoint with a method, parameters, headers and, where needed, a body. The server verifies identity, authorization and inputs, processes the action and returns data together with a status code.

GET /api/orders/4711 HTTP/1.1
Host: example.test
Authorization: Bearer <access-token>
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json

{"id":4711,"status":"processing"}

A technically valid token is not sufficient. The server must also verify that this identity may read this particular order. Missing object-level authorization commonly creates an IDOR vulnerability.

What types of API are there?

The choice affects the data model, error handling and security controls. The WebSockets article explains risks of bidirectional connections, while the GraphQL article covers schemas, queries and resolver security.

Authentication and authorization

Authentication establishes who is making a request. Authorization decides what that identity may do with each operation and object. API keys often identify an application, but are not automatically suitable for user login or fine-grained permissions. Delegated access commonly uses OAuth 2.0 and OpenID Connect. Access tokens-often JSON Web Tokens-must be checked for signature, issuer, audience, lifetime and intended purpose.

Which API vulnerabilities matter most?

How is an API designed securely?

1. Inventory and contract:
   Document endpoints, versions, owners, data classifications and dependencies. Include undocumented and legacy versions.
2. Explicit inputs:
   Validate allowed fields, types, ranges and object sizes on the server; reject unknown properties.
3. Authorization per action:
   Check role, tenant, object relationship and state transition on every request-not only at login.
4. Resource limits:
   Limit rate, concurrency, query depth, page size, uploads and execution time according to the endpoint.
5. Safe output:
   Return only required fields, avoid internal details in errors and prevent uncontrolled caching of sensitive responses.
6. Monitoring:
   Record failed authorization, unusual object access and high error rates with a request ID, but never log tokens or unnecessary personal data.

Documentation, versioning and testing

OpenAPI describes REST-oriented interfaces in a machine-readable form; a GraphQL schema serves part of that purpose for GraphQL. Documentation should cover authentication, errors, limits, data models and examples without exposing production credentials. Changes need a clear compatibility and retirement strategy. Security reviews combine contract analysis, source review and manual tests using different roles and tenants. Automated scanners find known patterns, but rarely understand whether a business process can be abused in context.