Astrum rules are the common set of directives that the user can define to identify the occurrences of suspicious and inept data in the open API specification.
There are two types of rules which the Astrum supports which can be represented using JSON.
- Regex Rule
- Assertion Rule
Regex Rule
A Regex rule takes a regular expression and matches it against the open API definition. Let's say as an API designer I want to style all my operation Ids to follow camel casing, we can represent it using the regex rule as below.
This rule applies the regex value defined in the "regex" field against the value present in the object path of the operation id and reports if they don't match the camel casing.
{
"name": "Operation Id should be Camel Case",
"description": "Operation Id should be Camel Case ",
"oasVersion": "2.0",
"status": "ACTIVE",
"objectPath": "$.paths.*.*.operationId",
"severity": "INFO",
"ruleType": {
"type": "REGEX",
"operation": "MATCHES",
"regex": "^[a-zA-Z]*$"
}
}
Assertion Rule
Assertion rules are forceful statements that can be applied against the open API definitions. For example, As an API security expert, I want all my APIs to be designed to run only using HTTPS protocol. Let's see how they can be achieved using the Assertion rule.
{
"name": "All Schemes Should be https",
"description": "All Schemes Should be https",
"oasVersion": 2.0,
"status": "ACTIVE",
"objectPath": "$.schemes.*",
"severity": "WARN",
"ruleType": {
"type": "ASSERT",
"operation": "equalTo",
"value": "https"
}
The above assertion rule takes the operation 'equalTo' and checks whether all my schemes are represented as 'HTTPS' failure of this assertion is captured in the linting report.
Assertion Rules support the below operations which can be used to apply against the API definitions
- equalTo
- present
- doesNotContain
- absent
- contains
- doesNotMatch
