Enforce API Schema
CloudGuard WAF's Schema Validation engine validates that API input conforms to the schema provided by the admin.
The admin provides the schema (using the OpenAPI specification, or OAS in short) and enhances the ability of CloudGuard WAF to detect and prevent illegal requests that do not comply.
What is OpenAPI Specifiction (OAS)
The OpenAPI Specification (OAS) defines a standard, language-agnostic interface to RESTful APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection. When properly defined, a consumer can understand and interact with the remote service with a minimal amount of implementation logic.
An OpenAPI definition can then be used by documentation generation tools to display the API, code generation tools to generate servers and clients in various programming languages, testing tools, and many other use cases.
API Discovery behavior change after activating Schema Validation
As long as schema validation is not active yet, API discovery can differentiate real APIs from requests by online scanners, by disregarding all APIs that do not receive a 200 OK HTTP response code.
Once schema validation is active in prevent mode, it will block all responses that do not conform to the schema. For this reason, the only way to detect new APIs that are missing from the schema is to use data from requests that are blocked by schema validation as well.
Once schema validation is active in Prevent mode, the need to carefully review new API changes in the following versions of the detected schema becomes much more important. The user must not accept changes of new APIs that are not used by the web server.
Use the multi-select option explained below to remove new APIs that are not supported by your server.
How to set up CloudGuard WAF Schema Validation
Step 1: Follow API discovery until it is recommended to enforce the detected schema (or create an OpenAPI YAML file of your API manually)
The recommended flow, even if you already had a highly maintained openAPI schema file of your APIs, is to allow API discovery learning mechanism to detect the actually used APIs in your server.
Follow the instructions for configuring API discovery and tracking its learning results, to see when it is recommended to enforce the detected schema.
If you did have a highly maintained openAPI schema file, it is recommended to compare teh detected schema by CloudGuard WAF's API discovery and your own schema, and review the differences.
After merging the 2 schemas, and enforcing the new schema using the configuration described below, continue maintaining the schema through CloudGuard WAF which will track changes based on the uploaded schema file.
Step 2: Browse to Policy->Assets and edit the Web API asset
Once the asset edit window opens, select the Threat Prevention tab and scroll to the Schema Validation sub-practice.
Step 3: Use the discovered schema (or, less recommended, upload a manually created schema file)
The recommended option is to select Use Discovered Schema and click Select. The schema selection window will appear:
The top will show the Currently enforced scheme name (or "No revision" upon the first time activating the schema validation feature).
Select:
Whether the "Changes" column will show APIs that have changed in any of their parameters and configuration, or just compare the endpoints (HTTP Method and URI) without query parameters, request body structure, etc.
The less recommended option is to select Use Custom Schema and Click on the Upload button the file selection window will appear:
Click the "Add File" icon to add a new file.
Optionally - you can click the "Download" icon to verify an existing file's content.
Select the file you wish to be used for schema validation.
Click OK.
When making the first change to the default Web API Best Practice's configuration such as uploading your unique OpenAPI schema file for Schema Validation purposes, you will be prompted to change the name of the Practice to your own custom practice name.
Step 4: Select if to enforce the schema according to the entire file or just API endpoints
It possible to enforce the schema at 2 levels:
Full schema - The entire schema file is enforced
API endpoints only - everything in the schema file, except the HTTP methods and URIs is disregarded. Requests are being compared to the schema for enforcement solely based on their HTTP method and URI.
Step 5: Make sure the Mode of the Schema Validation sub-practice is as desired
Setting the Mode to As Top Level means inheriting the primary mode of the practice.
Otherwise you can override it only for this specific sub-practice to Detect/Prevent/Disable.
It is recommended to initially set the mode to "Detect" to verify the input schema file is correct by looking at the logs created by this capability. Afterwards, restore the mode to the desired state.
Step 6: Enforce Policy
Click Enforce on the top banner of the Infinity Portal.
Last updated
