API security and the CNIL: the 5 flaws regulators target

Why the CNIL looks at your APIs

APIs now carry most of the personal data in a SaaS product: sync with an accounting tool, a profile sent to a third-party service, a mobile app reading the user's account. During an inspection, the CNIL does not read your code. It looks at what a caller can obtain, what you log, and what you can prove.

The recommendations published in 2026 therefore read like a list of flaws you should not have. Here they are, with how to check for each one.

Flaw 1: excessive data exposure

An endpoint GET /api/users/{id} returns the full database record: name and email, but also social security number, IBAN, password hash or internal notes. The front end only displays two fields, so nobody notices the rest. An attacker who opens the network tab sees everything.

This is the "Broken Object Property Level Authorization" category of the OWASP API Top 10. The fix is to define explicitly which fields each use case returns (serializers, server-side projections, DTOs) and never return a raw record.

Flaw 2: access to other people's objects (BOLA / IDOR)

The API checks that the caller is logged in, but not that the requested object belongs to them. Replacing invoice_id=1042 with 1043 shows another customer's invoice. It is the most common and most serious API flaw, covered in our article on BOLA and IDOR flaws.

The CNIL stresses the separation between authentication (who is calling) and authorization (do they have rights on this specific object). The check must happen server-side, object by object, on every request.

Flaw 3: tokens that are too powerful and live too long

A token created to sync absences can also read full HR files. An integration token never expires. A refresh token cannot be revoked on its own. In every case, one leaked secret opens everything.

Expected good practice:

• granular scopes (read:employees:identity separate from read:employees:payroll);
• short-lived access tokens, a few minutes to one hour depending on sensitivity;
• refresh tokens revocable one by one, rotated on every use;
• one token per integration, never a token shared across partners.

Flaw 4: no rate limiting

Without rate limiting, an attacker who found a BOLA can pull the whole database by iterating over IDs, and a login form becomes a credential stuffing target. Missing limits are also what makes user enumeration worthwhile. Limits must apply per account, per token and per IP address, with lower thresholds on sensitive endpoints (login, password reset, export).

Flaw 5: logs you cannot use

After an incident, the first question is: which data was read, by whom, and when? If your logs contain neither the caller identity, nor the endpoint, nor the ID of the requested object, you cannot answer, and you cannot scope the breach notification to the CNIL.

What to log for every call touching personal data: caller identity (user or token), endpoint, IDs of the requested objects, response code, timestamp. Not the data itself. The CNIL's general recommendation on logging calls for a retention period of six months to one year.

How to test it

You can run a first pass yourself in half a day:

1. Create two test accounts in two different organizations (A and B), with fake data.
2. Route traffic through a proxy (Burp Suite, Caido or mitmproxy) and browse the application as account A.
3. Excessive exposure: for every JSON response, compare the fields received with those displayed on screen. Any sensitive field that is not displayed is a finding.
4. BOLA: replay each request from account A, replacing IDs with those of account B's objects. A 200 response with B's data is a critical flaw.
5. Scopes: with an integration token, call endpoints outside its declared purpose. Note which ones answer.
6. Rate limiting: send 200 fast requests to the login endpoint and to a read endpoint. No 429 response is a finding.
7. Logs: trigger a specific read as account A, then check that you can find that call in your logs with the identity, the object and the time.

If a test reveals a leak, stop at the proof: confirm the data is readable without downloading it.

What changes when an AI agent calls your APIs

An AI agent connected to your APIs through function calling or an MCP server inherits the rights of its token. If that token is too broad, a prompt injection hidden in an email or a document is enough to make it read, then send elsewhere, data no user should have seen. The agent can iterate over IDs without getting tired: without rate limiting, it becomes a very efficient extraction tool.

The same rules apply, more strictly: a dedicated token for the agent with minimal scopes, per-object authorization checks, volume caps, and logs that tell agent calls apart from human ones. Our article on the function calling attack surface covers these scenarios.

Where to start

Start with the endpoints that return identity, health, payroll or banking data, and with those used by your integrations and agents. If you want to know what an attacker actually gets by going through the AI agent wired to those APIs, the Agent Red Team Express tests that scenario in five days, with evidence for every finding.