APIOps® Cycles

Back to parent topic

API Audit form

Any “No” answers must have an explanation in the comment field. Those implementations should be fixed as soon as possible or as a minimum should be peer-reviewed carefully to validate the reason. OWASP -security criteria refers to the OWASP security cheat sheet.

Topic Description OWASP Criteria? Result (yes/no) Comment
API management Has a version of the API already been published via API management?      
  Is it visible in a Developer Portal?      
  Have any users already subscribed to the API?      
  Are there rate limits enforced to the API consumers when using the API? yes    
  Is it possible for the API consumers to use the API without going via the API gateway governed by the API management?      
API specification Is there a standard specification file available about the API?      
  Is specification supported by the API management platform? (Open API is supported by most, RAML and apis.json are supported by some)      
  Is the specification maintained automatically when changes are done to the API implementation?      
  Is the specification validated against the specification standard?      
  Does the specification contain schemas for the requests and responses?      
  Does the specification contain examples in standard format for the requests and responses? (API management platforms and other tools can process the examples automatically and show them in documentation or used them for request mocking to help developer learn the API)      
  Are the schemas and examples validated against schema (for example JSON schema)?      
Protocol HTTPS (in special cases HTTP might be acceptable, write explanation in comment)? (If no, then this audit doesn't fit)      
URIs Is the domain name sensible for this API: is the API published under the organizations official domain?      
  Is the visible domain which the API consumers see when using the API shared with other APIs?       
  Endpoints are named after resources, in plural? Example /projects      
  Endpoints are max 2-resources deep? Example /projects/123/tasks/345      
  Other naming styles in style guide have been applied?      
  API has versioning?      

Versioning strategy is best for the selected API management platform and for the primary API consumers? Major version is in URI (only if API management platform doesn't support versioning based on client subscription)

Processing Stateless processing?      
  Any types of processing requiring special checking or handling: asynchronous, events, subscribe-model?      
HTTP-verbs GET is used only for searching and viewing resources      
  GET -requests don't have request bodies      
  GET requests with longest endpoint-hierarchy and multiple query parameters with long values don't exceed 2000 of URI length? (Some older clients and browsers may have this type of limit, although it is not official limit and newer clients can handle it well)      
  POST is used for creating and updating data?      

POST is used only in standard ways.

(Non-standard ways would mean it is used for submitting long search parameters, as alternative to PUT or as alternative to GET.These should be suppported only if important API consumers have specific problems dealing with the standard verbs.)

  PUT is used to create or replace entire resource?      
  DELETE is used only to remove a resource?      
  Whitelisting: POST, PUT and DELETE are only available for resources which API consumer is allowed to manipulate? yes    
HTTP -status codes

404 wrong url

  400 bad request from the client, for example a required query parameter was missing      
  400 -responses have additional information of the specific error (for example missing required attribute)      
  401 -response is used when API consumer is using wrong credentials yes    
  403 using endpoint which is valid but not accessible by the requesting API consumer or trying to use operation they are not allowed to do yes    
  500 -response when there is an internal processing problem which API consumer can not fix by changing the request      
  500 -responses have application specific error code but not a very clear plain message about exact error (stacktrace or error text) which could expose internal implementation to API consumer yes    

GET: 200 OK and items -array as empty array

  GET: 204 empty response, nothing in the body, but request is successful.      

POST: 200 OK for updates or submits without creating new resources


POST, PUT: 201 Created for creating new reasource

  201 -response is combined with the identifier of the created resource      
  DELETE: 204 OK when removing resource was successful      
Localization Date- and time formats in UTC with timezone (ISO standard)?      
  Language and country codes used with ISO -standard codes?      
  Other standard codes applied?      
  Geocordinates in ISO standard if used?        
  Payload localization supported or localized values accessible with API?      
  Error message localization supported?      
Additional security All endpoints are protected by at least a client specifc API key even if they are publically available (anti-farming)? yes    
  OpenID connect and JWT supported (session based authentication)? yes    
  Protect against CFRS? (allow API management developer portal as origin to allow developers to try out the API via the portal user interface)? See https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet for details. yes    
  Secured direct object references, i.e. no sensitive information like bank account numbers, social security numbers, person names etc. in URL as resource names or query parameters? yes    
  Inputs are validated? yes    
  Inputs are validated automatically by the coding framework used? yes    
  Outputs are escaped? yes    
  Outputs are escaped automatically by the coding framework used? yes    
  Need for encrypting data has been evalueted before implementation? (country-specific privacy and other legal requirements and business confidential requirements) yes    
  Encryption of data in transit and data in storage has been implemented according to the evaluated need? yes    
  Need to detect message integrity has been evaluated before implementation (typically using signed and encrypted JWT -tokens as authentication and integrity ensurance)? yes    
  Message integrity has been implemented according to the evaluated need? yes    
  UUID used to identify object instead of internal ID? yes