Limit the data you return.
APIs tend to return whole records; clients need a fraction. Default to summary responses and require explicit privilege to widen them — the single most effective brake on record-scraping.
1. Over-returning is a quiet breach
The most common data-exposure flaw is not a missing authentication check; it is an authenticated endpoint that returns far more than the caller needs. A client that renders a name and balance does not need the full record — the tax identifiers, the internal notes, the linked entities — yet APIs routinely serialize the whole object “for convenience.” Every extra field is attack surface, and a verified-but-hostile caller harvests exactly what you over-return.
2. Summary by default, detail by privilege
Invert the default. Endpoints should return the minimal, summary projection that satisfies the common case, and require an explicit, separately-authorized step to widen the response. This turns bulk exfiltration into a series of individually-authorized requests, each of which is logged, rate-checked, and revocable — the difference between leaking a database and leaking a row.
3. Field-level control
Sensitivity is not uniform within a record. The same account object can hold fields anyone may see, fields only the owner may see, and fields only a compliance role may see. Limiting what you return means resolving sensitivity at the field, not just the row, so the projection adapts to the caller rather than the caller filtering a fixed payload after the fact.
4. How B5 Secure enforces it
B5 Secure’s activity-data authorization treats sensitive fields as a first-class concern: conventions flag them, and the authorization decision shapes what is returned to the specific caller rather than trusting the client to discard what it should not have received. Combined with summary-first endpoint design, the framework makes broad, record-scraping responses the exception that must be justified — not the default that must be remembered to restrict.