How to answer
How is your API secured and authenticated?
Most answers describe authentication and stop. The question a reviewer is really asking is what stops one customer's token reading another customer's data.
The API authenticates every request with a bearer token scoped to a single tenant. Authorization is checked per object rather than per route, so a token cannot read another tenant's data by supplying its identifier. Requests are rate limited per token, and all traffic is TLS 1.2 or above.
FillTrust grades an answer like this implied, not stated when your documents support it.
- Answered from
- Your API documentation and your architecture notes, which usually describe authentication well and authorization barely at all.
- Evidence to attach
- The public API documentation, if it covers authentication. Rarely anything else.
- Where it is asked
- CAIQ v4.0 · AIS-02SIG LiteBespoke vendor questionnaires
For a product that is mostly an API, this row deserves more than a sentence about TLS. It is also the row where the honest answer is most often longer than the documentation, because API authentication tends to be well described and API authorization tends to be described nowhere.
Separate the two halves, and answer the second one properly. Authentication establishes who is calling. Authorization decides what that caller may reach, and it is where the expensive failures live. A reviewer with API experience is asking one question in particular: if a caller substitutes another tenant's identifier into a request, what stops them? The good answer is that authorization is checked against the object being accessed rather than only at the route, so a valid token for tenant A cannot fetch tenant B's record whatever id it supplies. If your check happens once at the door, say so, because that is a materially different security posture.
Say how a credential dies. Tokens leak: into logs, into repositories, into a screenshot in a support ticket. What matters is whether a customer can revoke one themselves, whether tokens expire, and whether you can tell which token did what afterwards. A permanent token with no revocation path and no audit trail is a real finding, and it is one reviewers ask about specifically.
Rate limiting belongs here, not only under availability. Per-token limits protect you from a runaway integration and from credential-stuffing alike, and they are the part of the answer most often missing. A limit that exists but is not enforced per tenant protects nothing in a multi-tenant product.
Mention what is not exposed. If your API cannot delete data, cannot read documents outside the calling tenant, or has no administrative surface at all, say so. Constraints are evidence, and they are the cheapest kind to give.
If your API is internal only, answer that plainly rather than leaving the row blank. "No public API; the interface is the web application, authenticated by session cookie" is a complete answer, and it shrinks the reviewer's threat model rather than leaving them to assume.
How this one goes wrong
Specific to this question, not general advice.
- Describing authentication and calling it security. Who you are is the easy half; what you are allowed to reach is where the breaches are.
- Long-lived tokens with no way to revoke one. The follow-up question is what happens when a customer's token leaks, and "rotate it" is only an answer if rotation exists.
- Forgetting that an object identifier in a URL is an access-control decision. Returning another tenant's record because the id was guessable is the most common serious API flaw there is.