API security protects the interfaces through which applications, partners and mobile apps exchange data. The thirteen measures below cover inventory, authentication, authorisation, input handling, rate limiting, encryption, logging and testing, mapped to the OWASP 2023 risk list. JCSS Indonesia uses them as an IS-audit checklist.
What is API security and why does it need its own controls?
API security is the set of controls that stop APIs exposing data or functions to the wrong caller. APIs need their own controls because they expose business logic and data directly.
A web page hides most logic behind a user interface; an API publishes object identifiers, fields and functions that any caller can try. Authorisation mistakes, forgotten endpoints and over-generous responses therefore become direct data exposure. OWASP's API Security Top 10 (2023 edition) is the common reference, and OWASP's own announcement notes that authorisation remains the biggest challenge, with three of its five highest-ranked items relating to access control.
What are the OWASP API Security risks for 2023?
The 2023 list has ten risks, API1 to API10, led by broken object level authorisation. Each maps to a control you can test.
| ID | Risk | Control to test |
|---|---|---|
| API1 | Broken Object Level Authorization | Ownership check on every object access |
| API2 | Broken Authentication | Strong, centrally managed authentication and token handling |
| API3 | Broken Object Property Level Authorization | Field-level allow-lists for read and write |
| API4 | Unrestricted Resource Consumption | Rate limits, quotas, payload size limits |
| API5 | Broken Function Level Authorization | Role checks on every function, especially administrative ones |
| API6 | Unrestricted Access to Sensitive Business Flows | Abuse detection on high-value flows |
| API7 | Server Side Request Forgery | Validation and allow-listing of outbound requests |
| API8 | Security Misconfiguration | Hardened, consistent configuration baselines |
| API9 | Improper Inventory Management | Complete, current API inventory and retirement process |
| API10 | Unsafe Consumption of APIs | Validate data from third-party APIs as untrusted |
What are the 13 essential API security measures?
The thirteen measures group into design, inventory, access, data, resilience and assurance. Use them as test steps and keep the evidence.
Design and inventory
- Secure design review: include threat modelling and security requirements before building an API.
- Maintain an inventory: list every API, version, owner and environment, including shadow and deprecated endpoints.
- Document accurately: keep specifications current and flag which endpoints are public, partner or internal.
- Retire cleanly: decommission old versions with a dated process.
Access
- Strong authentication: use a standard protocol, short-lived tokens, and centrally managed keys and secrets; never place credentials in URLs.
- Authorise every request: check object, property and function permissions on the server for each call, never trusting client-supplied identifiers.
Data
- Validate input and filter output: allow-list expected fields, reject unexpected ones and return only what the caller needs.
- Encrypt in transit: enforce TLS for all API traffic and protect sensitive data at rest.
Resilience
- Rate limit and set quotas: limit requests, payload size and expensive operations per client.
- Harden configuration: disable unused methods, verbose errors and default credentials; apply consistent gateway policy.
Assurance
- Log and monitor: record authentication events, authorisation failures and unusual call patterns, with alerts and retention that match your policy.
- Test continuously: combine code review, automated scanning in the pipeline and periodic manual VAPT focused on authorisation logic.
- Operate an incident process: define how a suspected API breach is triaged, contained and reported, including key rotation.
How do you test API authorisation effectively?
Test with at least two accounts of different privilege, swap identifiers and tokens between them, and confirm the server refuses every cross-account or cross-role call.
Object-level authorisation (API1) is a frequent finding because scanners that do not understand business context cannot catch it. A practical routine:
- create two ordinary users and one administrator in a test environment;
- capture requests for each object type and replay them using the other user's token;
- attempt to read and write properties the user should not control;
- call administrative functions with an ordinary token;
- record the request, response and conclusion for each case.
Where findings emerge, treat them as control deficiencies with an owner, not just developer bugs.
What evidence would an IS auditor ask for?
An auditor looks for an inventory, design standards, access-control test results, configuration baselines, logs, and proof that findings were fixed and retested.
| Control area | Typical evidence |
|---|---|
| Inventory | API register with owners and versions, reconciled to gateway or cloud configuration |
| Authentication | Standards, token lifetimes, key-rotation records |
| Authorisation | Test cases and results, code review checklists |
| Rate limiting | Gateway configuration, load test or abuse test results |
| Logging | Sample logs, alert rules, review records |
| Testing | VAPT reports, pipeline scan results, retest confirmation |
For management-system context, see our ISO 27001 guide and the security governance checklist. JCSS Indonesia includes API controls within its internal audit, ITGC and cybersecurity service.
Frequently asked questions
What is the OWASP API Security Top 10?
It is OWASP's list of the ten main API security risks, with the second edition published in July 2023. It runs from API1, Broken Object Level Authorization, to API10, Unsafe Consumption of APIs. Teams use it as a baseline for design reviews, testing scopes and audit checklists.
Is an API gateway enough to secure my APIs?
No. A gateway helps with authentication enforcement, rate limiting and logging, but it usually cannot decide whether user A may see user B's record. That authorisation logic lives in the application. You still need server-side checks, inventory, testing and monitoring behind the gateway.
How often should APIs be tested?
Test on every significant change through automated checks in the delivery pipeline, and run a manual penetration test periodically and after major releases, particularly on authorisation. The right frequency depends on exposure and data sensitivity, so document your rationale. Retest after fixes to confirm that the issue is actually closed.
What is the difference between authentication and authorisation in APIs?
Authentication establishes who the caller is, for example through a token. Authorisation decides what that caller may do with each object, property and function. Many serious API incidents involve valid, authenticated users accessing data they should not see, which is why authorisation checks must happen on the server for every request.
Why is an API inventory so important?
You cannot protect or test endpoints you do not know exist. Forgotten test versions, deprecated endpoints and undocumented partner interfaces often lack current controls. OWASP lists improper inventory management as API9 for this reason. Keep a register with owners and reconcile it regularly against gateway and cloud configuration.
General information only, not legal or tax advice for your specific facts. Regulations change; confirm the current position with JCSS Indonesia before acting.