API Audit Checklist

Use this checklist to audit your API prototype or a ready made API before publishing it to stakeholders, or, why not before buying an API. Now available for REST and AsyncAPIs
Last updated on Oct 04, 2023 to include references to OWASP top 10 API security vulnerabilities 2019 and 2023
Detailed guide related to APIOps Cycles phase:
API Audit

Rest API checklist

concept is ready when...

  • The API is based on clear business needs. (API9:2019  Improper Assets Management)
  • API is designed for hiding raw backend data and shared use for multiple API-consuming applications (API6:2023 Excessive Data Exposure)
  • The API and it's endpoints have a description that explains its business value and features. (API9:2023 Improper Inventory Management)
  • API has a consistent design with our other APIs. (API8:2023  Security Misconfiguration, API9:2023 Improper Inventory Management)
  • API and data naming of attributes uses good, descriptive English (or other standard language).
  • Mandatory fields are specified (API6:2019 Mass Assignment)
Dates are in ISO standard date format including the timezone. (API8:2019  Injection)
All general data such as country and language names, geographical coordinates etc. use (ISO or other) standard values. (API6:2023 Excessive Data Exposure, API8:2019  Injection)
Fields are described in full words avoiding acronyms. (API9:2023 Improper Inventory Management)
When creating new resources, an identifier is returned per item. (API2:2023 Broken Authentication)

api design prototype is ready when...

All items in the concept checklist are audited in addition to...
  • Endpoint design contains maximum of two resources/sub-resources in the endpoint path
  • All endpoints and attributes include examples.
  • POST is used for creating and updating data (instead of PUT unless full resource)
  • DELETE is used to remove a resource
  • API versioning strategy has been decided and it is supported by the API gateway in use. (API9:2023 Improper Inventory Management)
  • GET method doesn't have a request body and returns status 200 OK and some content in response
  • GET method returns status 204 when the response body is empty
  • POST method returns 200 OK when the resource is updated
    POST method returns status 201 Created and returns the identifier of the created resource
    DELETE method returns 204 OK when removing a resource was successful
    400 -responses have additional information on the specific error (for example, missing required attribute but not internal or infrastructure information)  (API6:2023 Excessive Data Exposure)
    401 Unauthorized is used when the API consumer is using the wrong credentials (API2:2023 Broken Authentication)
    403 Forbidden is used when an authorized API consumer tries to use an operation they are not allowed to do. (API5:2023 Broken Function Level Authorization)

api is in maintainable in production when...

All items in the prototype and API design checklists are audited in addition to...
  • API is published via API management (API10:2019 Insufficient Logging & Monitoring, API8:2023 Security Misconfiguration)
  • API is visible in a Developer portal (API9:2023 Improper Inventory Management)
  • API can only be accessed via the API management gateway  (API9:2023 Improper Inventory Management, , API8:2023 Security Misconfiguration)
  • Rate limits are enforced when requesting API (API4:2023 Unrestricted Resource Consumption)
  • API documentation is generated automatically based on the specification, schema and examples (API9:2023 Improper Inventory Management)
  • The specification is updated automatically to API gateway and documentation site / developer portal when changes are done to API (API9:2023 Improper Inventory Management)
    Specification for endpoints is validated on every change against standards  
    The specification contains the schema for the requests and responses  
    Request and response schema and examples pass schema validation
    API uses HTTPS (or, in special cases, other stateless protocols with encryption)  (API10:2023 Unsafe Consumption of APIs)
    The API published under the organization's official domain  (API8:2023 Security Misconfiguration)
    All endpoints are protected by authentication (API2:2023 Broken Authentication, API4:2023 Unrestricted Resource Consumption)
    API has token-based authentication
    API is protected against Cross Site Request Forgery (CFRS) (API8:2023 Security Misconfiguration)
    Inputs are validated automatically by the coding framework used (API8:2023 Security Misconfiguration)
    Outputs are escaped automatically by the coding framework used (API8:2023 Security Misconfiguration)
    Encryption of data in transit and data in storage is implemented according to the evaluated need (API8:2023 Security Misconfiguration)
    Message integrity has been implemented according to the evaluated need (API6:2023  Unrestricted Access to Sensitive Business Flows, API7:2023 Server Side Request Forgery)
    UUID or other pseudoidentifiers are used to identify objects instead of internal database identifiers (API7:2023 Insecure Direct Object References)
    Direct object references to sensitive information like bank account numbers, social security numbers, person names are not used in URLs (API7:2023 Insecure Direct Object References)
    Specific HTTP Methods are only available for resources where intended (e.g. whitelisting, automatically based on OpenAPI specification) (API5:2023 Broken Function Level Authorization)

async API checklist

concept is ready when...

  • The API is based on clear business needs.
  • API is designed for hiding raw backend data and shared use for multiple API-consuming applications
  • The API has a description that explains its business value and features.
  • API has a consistent design with our other APIs.
  • API and data naming uses good English (or other standard language).
  • Mandatory fields are specified.
Dates are in ISO standard date format including the timezone.
All general data such as country and language names, geographical coordinates etc. use standard values.
Fields are described in full words avoiding acronyms.
When publishing new messages, the relevant topics or channels are clearly identified.

api design prototype is ready when...

All items in the concept checklist are audited in addition to...
  • The message design contains a clear structure, differentiating between events, commands, and queries.
  • All messages and attributes include examples.
  • Messages follow a consistent structure across all topics/channels.
  • The message versioning strategy has been decided.
  • Acknowledgments for received messages are defined (if applicable).
  • Errors or issues with messages are clearly conveyed, with additional information on the specific error.
  • Authentication and authorization strategies are specified.

api is in maintainable in production when...

All items in the prototype and API design checklists are audited in addition to...
  • API is managed via a proper AsyncAPI management tool.
  • API is visible in a Developer portal
  • Rate limits are enforced when sending messages (if applicable).
  • API documentation is generated automatically based on the AsyncAPI specification, schema, and examples.
  • The specification is updated automatically to API management tools and documentation site/developer portal when changes are done to API.
    Specification for topics/channels is validated on every change against standards.
    The specification contains the schema for the messages.
    Message schema and examples pass schema validation.
    Message transport ensures security (e.g., MQTT over TLS or AMQP over TLS).
    The API is operated under the organization's official domain (or relevant broker or message service).
    All topics/channels are protected by authentication.
    API has token-based authentication.
    Encryption of data in transit and data in storage is implemented according to the evaluated need.
    Message integrity has been implemented according to the evaluated need.
    UUID or other pseudoidentifiers are used to identify objects instead of internal database identifiers.
    Sensitive information is not exposed in topics or channels.
    Message integrity has been implemented according to the evaluated need
    UUID or other pseudoidentifiers are used to identify objects instead of internal database identifiers
    Sensitive information is not exposed in topics or channels.
    Whitelisting is used to specify which clients can publish or subscribe to certain topics/channels.
APIOps Cycles

method for lean api development

Great APIs need skilled people and a good method, which let's you create APIs as products - fast.
APIOps Cycles method is vendor & technology-neutral.

Read the free e-book "The 8 wastes of lean in API development". Learn quick tips on how to remove the wastes using the APIOps Cycles method.

Learn the method in 2 hGo to method
MEthod license cC-BY-SA 4.0
APIOps and APIOps cycles
trademark owned by
Osaango Oy
The MethodresourcespartnersaboutBLOG