APIs for Product Managers
API Security and Privacy, in Plain English
You don't need to be a security engineer. You need to know the questions that prevent your company from being the next breach headline.
The industry reference here is the OWASP API Security Top 10 — a well-known, regularly updated list of the most common API vulnerabilities. You don't need the full technical detail; you need the plain-English versions and the product habit of asking about them.
Risk (plain English) | The product question to ask |
|---|---|
Broken access control — a caller can access data that isn't theirs by guessing or manipulating an ID | Have we tested what happens if a logged-in user changes an ID in the URL to someone else's record? |
Over-permissioned access — API keys or tokens grant more than the caller actually needs | Are we granting the smallest set of permissions the actual use case requires, or the broadest, because it was easier to build? |
Excessive data exposure — an endpoint returns more fields than the caller needs, relying on the client to filter | Are we sending sensitive fields (SSNs, full card numbers, internal-only flags) to clients who don't need them, just because it was convenient server-side? |
Lack of rate limiting | Could a single caller — malicious or just buggy — take down this endpoint for everyone else? |
Security misconfiguration | Are our error messages leaking internal details (stack traces, database structure) to the outside world? |
Every one of these is, at root, a product decision about what to expose and to whom — the implementation is engineering's job, but the scope of the promise is yours. This is the same discipline as the training-data privacy work: name the lawful basis, name the minimum necessary access, and put it in writing before launch, because retrofitting security after external dependencies exist is far more expensive than building it in from day one.
On the privacy side specifically: any API that returns personal data needs the same lawful-basis and data-minimization thinking as any other product surface, under GDPR, DPDP, and sector-specific regimes. An API that returns more personal data than the caller's stated use case requires is a compliance liability sitting in your own documentation, publicly, for anyone to read.
YOUR MOVE THIS WEEK
Pick one endpoint that returns any personal or sensitive data. Ask: does every field in this response serve the caller's actual stated use case, or are we returning "everything we have" because filtering felt like extra work? Trim it, or write down why each field earns its place.