Know every API and owner
Build inventory from gateway configuration, code repositories, service catalogues and observed traffic. Include partner, mobile, internal and legacy endpoints.
Record data classification, authentication method, consumers, internet exposure, version and retirement date. Unknown APIs become permanent exceptions.
- Service and business owner
- Environment and exposure
- Data and action sensitivity
- Version and lifecycle state
Separate authentication and authorization
Use standard, validated identity tokens with clear audiences and lifetimes. Services should authenticate to one another with workload identity rather than shared secrets.
Enforce tenant, object and function authorization in code or a policy service that has the necessary business context.
- Token issuer and audience validation
- Object-level authorization
- Function-level authorization
- Scoped service credentials
Control input, output and consumption
Validate schemas, types, sizes and allowed fields. Return only necessary data and handle errors without exposing internal detail.
Rate limits should follow business risk, identity and operation—not only source address. Protect expensive search, export and AI-backed endpoints from unbounded use.
- Strict request schema
- Response data minimisation
- Operation-specific limits
- Safe file and webhook handling
Operate the API lifecycle
Log identity, route, object category, decision and outcome with privacy controls. Detect enumeration, credential abuse, unusual volume and authorization failures.
Retire versions deliberately. Remove routes, keys, documentation and network paths, and notify consumers before support ends.
- Abuse-focused detection
- Security regression tests
- Dependency and secret rotation
- Version deprecation plan
A practical 30-day field plan
Week one — Discover. Inventory, owner, consumers and data. Put one accountable owner in the room, agree which business service or decision is in scope, and record the assumptions the team is making. Resist the urge to begin with a technology purchase; the first deliverable is a shared view of the problem and the authority to change it.
Week two — Authenticate. User, application and service identity. Walk through the current process with the people who operate it. Compare the written design with real access paths, data flows, exceptions and on-call practice. Mark every point where an owner is missing or where the team cannot produce evidence that a control works.
Week three — Authorize. Action, object, tenant and business rule. Choose a narrow pilot that can be observed safely. Define the expected result, the rollback path and the person who may accept a trade-off. Capture operational friction as product feedback; controls that are difficult to use will eventually be bypassed.
Week four — Observe. Abuse, errors, changes and retirement. Review the pilot with engineering, operations, security and the service owner. Close urgent gaps, assign longer work to a funded backlog and set the next evidence review. The month should end with a repeatable operating rhythm, not a one-time presentation.
Evidence worth keeping
Good evidence is understandable outside the team that created it. Keep a concise record that connects the decision, owner, technical implementation and observed result. Screenshots can support evidence, but configuration, logs, test output and approved records are stronger because another person can reproduce or challenge them.
- Service and business owner — owner, current state, last validation and any open exception
- Token issuer and audience validation — owner, current state, last validation and any open exception
- Strict request schema — owner, current state, last validation and any open exception
- Abuse-focused detection — owner, current state, last validation and any open exception
- Decision log showing who approved residual risk and when it will be reviewed
- Test or exercise result with the actual outcome, not only a pass label
Questions for the leadership review
Use these questions to keep the discussion connected to operating risk rather than tool activity. A useful answer names a person, a service and evidence.
- Who is accountable for the application security outcome when teams disagree about delivery and risk?
- Which critical service or customer promise would be affected by a failure in this area?
- What evidence would tell us the design is working in production today?
- Which exception creates the largest concentration of access, dependency or recovery risk?
- What would the team contain first, and how would it restore a trustworthy service?
- Which improvement can be completed in the next 30 days without waiting for a large programme?
Common questions
Is an API gateway enough?
No. It handles common edge controls, while object and business authorization usually require application context.
Should internal APIs use the same controls?
They still need identity, authorization, validation and monitoring; the exposure and threat model may differ.