API Security: The Most Common Flaws

API security is a distinct topic because the protective layer a user interface provides is absent. In a web application the interface constrains what can be requested; with an API the client can send anything, in any order.

1. Missing object-level authorisation

The most common and most serious flaw. The API validates the token but does not check whether that user is entitled to the requested object.

GET /api/orders/8842 returns the order even when it belongs to someone else. Automated tools cannot find this, because the request is technically valid.

What to do: server-side authorisation on every object access. Trust the identity derived from the token, not the identifier sent by the client.

2. Excessive data exposure

The API returns the full object while the client displays only part of it. The rest sits in the response for anyone to read.

Typical case: the user profile endpoint returns the password hash, internal identifiers or other users' data.

What to do: compose responses explicitly, field by field. Do not serialise the entire database object.

3. Missing rate limiting

Without limits an endpoint can be used for brute force, scraping or denial of service. Login and password reset endpoints are the most sensitive.

What to do: limits per user and per IP, with different thresholds on different endpoints.

4. Mass assignment

The API accepts every field the client sends and writes it into the object. The attacker adds "role": "admin" and receives it.

What to do: an allow-list of modifiable fields. Anything not explicitly permitted must be ignored.

5. Keeping old versions alive

v2 arrived alongside /api/v1, but v1 still runs because a few clients use it. The old version still carries the old flaws.

What to do: a version inventory, a retirement plan, and switching off unused versions. Access logs reveal whether anyone genuinely still uses them.

Authentication and tokens

Short lifetime. Access tokens should be short-lived and renewable with a refresh token. A never-expiring token works just as well once lost.

Scope restriction. A token should authorise only what the client needs, not everything.

Not in the URL. Send tokens in headers, because URLs appear in logs and referrers.

Revocability. There must be a way to invalidate a token immediately on compromise.

What to test

• Object-level authorisation: attempting another user's identifier
• Function-level authorisation: a low-privileged token on an administrative endpoint
• Surplus fields returned in responses
• Whether rate limiting exists on authentication endpoints
• Availability of old versions

Our IT security services and penetration testing both extend to the API layer.