API Penetration Testing

More and more applications depend on publicly accessible Application Programming Interfaces (APIs) to provide their core functionality as well as to integrate with and/or extend other applications and data sources. With all the versatility and features of APIs come potential security weaknesses and vulnerabilities, some of which can be critical, and many of which can be identified and addressed through penetration testing. However, effective penetration testing of APIs requires complete, up to date and accurate API specification and documentation which would allow a penetration tester to generate valid API requests which then can be used to effectively penetration test the API and its endpoint(s) by generating malicious variations of the original valid request. It is therefore important to ensure that whoever is penetration testing an API needs to be able to generate valid API requests before it can be tested. Having an accurate and complete API specification in the right format is key.

To obtain the best results from a penetration test of an API the API specification should meet the following good practice requirements:

  • The API specification must be in a standard format such as OpenAPI and machine-readable notation such as JSON or YAML

  • The API specification must be complete, i.e. should not be missing any required methods / parameters / headers / etc

  • The API specification must be accurate, i.e. it should match the actually deployed services accessible on the relevant endpoint(s)

  • The API specification must not contain unnecessary, extraneous or unused methods / parameters / headers

  • The API specification must correctly specify relevant endpoint URL(s) and specify secure transport ('https://')

  • The API specification must specify authentication / authorisation requirements clearly and unambiguously and specify how any relevant tokens or credentials can be obtained

  • The API specification must specify all required and optional parameters, indicating them as such, and the format in which they must be specified (e.g. 'date': 'DD-MM-YYYY' or 'DDMMYY'?)

  • If there is more than one version of the API the specification must indicate the version of the API and the correct endpoint(s) for that version

A number of tools exist which can be used to create, edit, validate and share API specifications, some of them listed below:

When you have a complete and accurate API specification use an appropriate tool, such as OpenAPI Validator or Swagger Inspector above, to validate it. If the tools identify any issues with the specification they must be addressed before penetration testing.

Once the API specification has been validated, share it with the penetration tester alongside a set of sample/test credentials and values for all parameters that cannot be obtained from the API itself.

For example, if the API allows users to list widgets and their IDs you don't need to provide widget IDs; but if the API does not have a "list widgets" function but requires "widgetId" as a parameter to other API calls you need to provide a valid sample/test "widgetId" to be used during the testing.