API Contract Conformance Scan is a dynamic runtime analysis of your API to check that the implementation behind your API and the behavior of the backend service matches the contract set out in the OpenAPI (formerly known as Swagger) definition of the API.
You can run a scan on an API you have imported to 42Crunch Platform and deployed to find out if there are any mismatches between the API definition describing your API and what it actually does. If Conformance Scan testing finds any discrepancies, it reports the issues clearly so that you can fix them.
Both OpenAPI Specification v2 and v3 are supported.
Note For best results, make sure that your OpenAPI definition is valid and well-formatted before you scan it. The API must be deployed so that the API endpoint is live, and the backend server your API uses must be accessible to Conformance Scan. Otherwise the API cannot be scanned. APIs spanning multiple servers are not supported, all API operations are expected to be on the same server.
You cannot scan APIs if your account belongs to the free community organization, or your organization administrator has disabled this function for you.
How Conformance Scan works
After you have created a scan configuration for your API, Conformance Scan takes over and starts the scan process:
- Preparation: Conformance Scan checks the scan configuration you created and prepares the pieces required for the scan.
- Checks that the scan configuration you provided is valid.
- Parses the OpenAPI definition of your API, generating default values for the parameters your API operations require (see Generating values for parameters).
- Checks that any certificates provided for authentication to the API endpoint are valid (see Authentication in Conformance Scan).
- Tests the designated endpoint to check that the server is available (see API endpoints in Conformance Scan).
- Happy path requests: Conformance Scan generates and sends a happy path request to all operations in your API to establish a successful benchmark. Any operations where the happy path request fails are skipped in the scan (see Happy path requests).
- Generating tests: The scan generates the test requests for the API operations in the scan based on the happy path requests. Each test request includes an intentionally tweaked element (header, body, parameters, HTTP method) so that the request no longer matches what the API expects. The implementation of the API should catch this and respond accordingly.
Conformance Scan sends tests requests at a constant flow rate to the live API endpoint.
- Conformance Scan waits for the API to respond within the 10 seconds. If the request times out, the scan tries to send the request 3 times before raising an error.
- When the API responds, Conformance Scan analyzes the received response to determine if the API conforms to the contract it sets out in its OpenAPI definition (see Response validation).
Unlike the static testing in API Contract Security Audit, Conformance Scan is dynamic testing and variable by nature. To better simulate real API traffic and more reliably test the API's behavior, the requests and parameter values that Conformance Scan generates are random, as is the order in which the requests are sent to the API. As a result, the API responses and the outcome of the scan can also vary. So do not be alarmed if you get slightly different results for your API in scans, that is completely normal.
To successfully call the API operations in your API, Conformance Scan must follow the OpenAPI definition of the API and provide the required parameters in the calls. For this, when Conformance Scan loads the API definition in memory, it generates default values for each schema and parameter in the OpenAPI definition, and uses these values in the requests it sends. Because Conformance Scan scan does not generate any responses itself (it only validates the responses coming directly from the API), response schemas are excluded.
It may be very difficult to create valid values for some things, like some object schemas, or strings with a very specific pattern. To ensure best performance, if you have complicated schemas in your API, we recommend including some examples for these kind of values directly in the OpenAPI definition.
There are several properties you can use for this, in the order of preference:
If the property
x-42c-sample contains a value that is not valid against the schema, Conformance Scan tries to load the value from the property
default, and so on, until it finds a sample value it can use. As a last resort, or if no samples are provided at all, Conformance Scan generates a value from scratch. If Conformance Scan cannot generate a default value that an API operation requires, that operation is skipped in the scan.
Conformance Scan needs a benchmark to determine if the incorrect behavior of the API was caused by the test request or some other failure. To establish this benchmark, Conformance Scan first sends a happy path request to operations in the API before it starts scanning the API.
A happy path request is a valid request generated directly from the OpenAPI definition of your API and designed to succeed. Conformance Scan generates and sends this request to each operation defined in your API, and validates the responses it received.
To be a success, validation must deem the response either as successful or expected, and the received HTTP status code must be between
404. Otherwise, the happy path request fails. The happy path request can also fail because the connection to the defined endpoint was broken, or the API took too long to respond.
If a happy path request fails, the operation in question is skipped in the scan, because any results from the scan for that operation would be inconclusive with the successful benchmark missing.
How the API responds to the grafted test requests in the scan determines whether or not it conforms to the contract it sets out in its API definition. To catch the issues, Conformance Scan validates the response from the API and considers, for example, the following:
- Is the provided HTTP status code defined in the
responseobject in the API definition?
- Are all headers in the response defined in the
responseobject in the API definition and do they match the defined
schema? Are all required headers present in the response?
- Is the returned response body too big?
- Should the response even have a body (method
HEADor returned status code
- Does the
Content-Typeof the returned response match the types defined in the content map in the API definition, and does it match the defined
By default, Conformance Scan lists endpoint URLs that are parsed directly from your OpenAPI definition. However, if you want to use a URL that is not listed, you can also enter it when you configure the scan settings.
The URL you enter for the API endpoint must fulfill the following criteria:
- It is a public URL.
- It specifies either
- It is not an internal address (for example,
- It does not include parameters (for example,
- It does not include anchors (for example,
Note The scan generates real traffic to the selected API endpoint and could incur costs depending on your setup.
If you have defined authentication for your API or its operations, Conformance Scan must provide the required details to authenticate when it sends requests to the API.
When you configure the scan, you must therefore fill in the details for the security schemes in your API that you want to use in the scan. The configuration wizard shows all security schemes defined in the OpenAPI definition of your API:
Fill in the details for the security schemes you want to use in the scan. The authentication details are only used in this scan and are not stored anywhere.
You can leave the security schemes that you do not want to use in the scan empty and Conformance Scan will ignore these schemes. Any API operations that use only these security schemes for authentication are skipped in the scan.
If you have not defined any security requirements in the API definition, no authentication is required.
Conformance Scan currently supports the following authentication types:
- Basic authentication
- API keys in headers, query strings, or cookies
- Bearer token
- OAuth 2
NoteTo configure OAuth2 authentication, you must first manually obtain an access token that Conformance Scan can use to authenticate to your API. In the scan configuration wizard, authentication with OAuth token is configured like bearer token. For more details on OAuth2, see RFC 6749.
If needed, you can also configure mutual TLS for client authentication. For more details, see Scan API conformance.
Occasionally, Conformance Scan might fail to scan your API. The reason for this could be, for example:
- Invalid OpenAPI definition: You API definition has critical errors that are preventing Conformance Scan from running. For example, the structure of your API might not conform to the OpenAPI Specification. Use API Contract Security Audit to check your API definition and fix any found issues in Security Editor, then try Conformance Scan again.
- Invalid scan configuration: The configuration you set up for the scan does not match your API definition and thus is not valid. For example, you might have chosen an authentication method that does not match the ones defined in your API definition. Try configuring and running Conformance Scan again, making sure the authentication details match your API definition.
- Scan cannot reach API endpoint: Conformance Scan tried to run the scan but failed to reach the API endpoint you had selected for the scan. The API host could be down, or there could be an error in the URL, especially if entered a custom URL. Check the URL and the host of your API and try again.
- Timeout: The scan took longer than the maximum scan duration (3600 seconds).
Conformance Scan produces a scan report that provides valuable information on how well your API conforms to its API definition. The report summarizes what was scanned and how the scan went.
At the top, you can see how many tests were run, how many passed or failed, and if the scan skipped any operations that could not be tested. Below that is the list of issues that the scan found in the API implementation.
The filter sidebar on the left lets you filter by path and method which issues are show. The sidebar also shows how many issues were found in each path and method, as well as which operations the scan had to skip.
Clicking an issue provides further details on it, such as the attack that the scan performed, the URL the scan called, and the response time of the API, or the size and content type of the response.
To make it easier to reproduce the issues, the report also provides the cURL requests the scan used to detect each issue.