The Attack Surface of a REST API

A REST API (Representational State Transfer) exposes HTTP endpoints that allow clients (web apps, mobile apps, third-party services) to access a server's data and features. Every endpoint is a potential door for an attacker. The attack surface includes:

  • Exposed endpoints: every unprotected route can be called by anyone.
  • Data in transit: if HTTPS is not enforced, requests can be intercepted.
  • Data in the database: SQL injection or poor input validation can expose the entire database.

Authentication vs Authorization

Two fundamental concepts that are often confused:

  • Authentication: verifying identity — "Who are you?" The user or service proves they are who they claim to be.
  • Authorization: verifying rights — "What are you allowed to do?" Once identity is established, the system determines which resources and actions are accessible.

An API can correctly authenticate a user but allow them to access resources that do not belong to them — this is the IDOR (Insecure Direct Object Reference) vulnerability, very common in the OWASP API Top 10 ranking.

API Keys: Simple and Effective

API keys are opaque tokens generated by the server and transmitted in a dedicated HTTP header:

GET /api/v1/users HTTP/1.1
X-API-Key: sk_live_abc123xyz...

Advantages: simple to implement and understand. Disadvantages: no native expiration mechanism, no identity information (who is using this key?). Best practices:

  • Rotate keys regularly.
  • Generate separate keys per environment (dev, staging, prod).
  • Never expose a key in versioned source code.

JWT: Signed Stateless Tokens

A JWT (JSON Web Token) is a self-describing token made of three Base64-encoded parts separated by dots: header.payload.signature.

  • The header specifies the signing algorithm (HS256, RS256, etc.).
  • The payload contains claims (user ID, roles, expiration).
  • The signature guarantees integrity — a modified token will be rejected.

Important warnings: the payload is encoded, not encrypted — never store sensitive data in it. Always verify the signature server-side. Set a short expiration (exp) and plan a refresh token mechanism.

OAuth 2.0: Authorization Delegation

OAuth 2.0 is an authorization delegation framework that allows an application to access resources on behalf of a user without knowing their password. Two main flows:

  • Authorization Code Flow: for web applications with a backend. The user authenticates with the authorization server, which returns a code exchangeable for an access token. This is the most secure flow.
  • Client Credentials Flow: for machine-to-machine (M2M) communication, with no user involved. The application authenticates directly with its client_id and client_secret.

Essential Best Practices

Beyond authentication, several practices are indispensable:

  • HTTPS mandatory: all communications must be encrypted with TLS (Transport Layer Security).
  • Rate limiting: limit the number of requests per period (respond with 429 Too Many Requests when exceeded) to prevent brute-force attacks and abuse.
  • Input validation: validate and sanitize all received data — never trust client data.
  • Principle of least privilege: OAuth scopes and permissions must be limited to the strict minimum.
  • Versioning: prefix routes with /v1/ to enable evolution without breaking existing clients.
  • Correct CORS configuration: restrict allowed origins, never use * in production.
  • Logging: log all API calls with identifier, timestamp, and status to enable auditing.
  • Security testing: use OWASP ZAP (Zed Attack Proxy) or Burp Suite to scan your endpoints.

Audit Your API Security

Poorly secured APIs are a prime target for attackers — and vulnerabilities are often invisible from the outside. Run a free audit to assess your API's exposure and get a detailed report of vulnerabilities to fix.