webfuzzing-commons 0.10.0__py3-none-any.whl

webfuzzing_commons/data/auth.yaml

@@ -0,0 +1,263 @@
+#####################################################################################################################
+## We use a JSON Schema to validate JSON/YAML configuration files with auth info.
+## However, such files need to be post-processed to handle merge of keys from 'authTemplate'.
+## In the past, YAML had native support for this in the form of templates, but this is no longer the case.
+## A concrete side-effect of this issue is that we cannot use "required" constraints, as those would be applied
+## to the document as it is, before the template resolution.
+## A pragmatic compromise is to avoid "required" for fields that can be merged, and rather use "x-required".
+## The validation of x-required constraints would then be delegated to whatever is used to resolve the templates.
+##
+## An "x-required" custom entry can be either an array of strings (with same semantic of "required") or an object (with
+## fields such as  "allOf" and "oneOf" to express more fine-grained constraints)
+#####################################################################################################################
+$schema: "https://json-schema.org/draft/2020-12/schema"
+$id: "https://github.com/WebFuzzing/Commons/blob/master/src/main/resources/wfc/schemas/auth.yaml"
+title: "Web Fuzzing Commons Authentication"
+description: "Schema Definition for Web Fuzzing Commons Authentication"
+type: object
+properties:
+  schemaVersion:
+    type: string
+    description: "The schema version of WFC needed to use to validate and process this document."
+  auth:
+    description: "List of authentication information for different users."
+    type: array
+    items:
+      $ref: "#/$defs/AuthenticationInfo"
+  authTemplate:
+    description: "Optional authentication information template. This is used to avoid duplication in the auth list. \
+                 Entries defined in the template will be applied to all elements in the auth list that do not specify them."
+    allOf:
+    - $ref: "#/$defs/AuthenticationInfo"
+    - type: object
+  configs:
+    description: "Optional map of configuration parameters, in the form key:value strings. \
+                  This can be useful to provide extra custom information in the same configuration file, \
+                  independently of the defined authentication information."
+    type: object
+    additionalProperties:
+      type: string
+required: ["auth"]
+$defs:
+  HttpVerb:
+    type: string
+    enum:
+      - POST
+      - GET
+      - PATCH
+      - DELETE
+      - PUT
+  Header:
+    description: "HTTP header information"
+    type: object
+    properties:
+      name:
+        description: "The header name, e.g., 'Authorization'."
+        type: string
+      value:
+        description: "The value of the header"
+        type: string
+    required: ["name","value"]
+  AuthenticationInfo:
+    type: object
+    properties:
+      name:
+        description: "The name given to this authentication info. \
+                      This works as a unique id for this authentication configuration."
+        type: string
+      requireMockHandling:
+        description: "Specify that the authentication for this user requires setting up mock responses from an external service. \
+                      This will be done as part of the fuzzing, although only possible for white-box testing. \
+                      One consequence here is that, even if we provide correct auth info as input, then a request might still \
+                      fail due to unauthorized access if the fuzzing process does not properly set up these mocked responses in the API itself."
+        type: boolean
+      fixedHeaders:
+        description: "The headers needed for authentication. \
+                      This is used to represent cases in which auth info is static/fixed, e.g., \
+                      when passing an id or username/password through a HTTP header (and not \
+                      using for example a dynamically generated token from a login endpoint first)."
+        type: array
+        items:
+          $ref: "#/$defs/Header"
+      loginEndpointAuth:
+          $ref: "#/$defs/LoginEndpoint"
+      createUsers:
+          $ref: "#/$defs/CreateUsers"
+    x-required: ["name"]
+  ###
+  CreateUsers:
+    description: "For some example APIs, it might be possible to create new users with a single HTTP request. \
+                      In these cases, instead of relying on knowledge of existing users, the fuzzer can create them on \
+                      the fly. This can be useful when endpoints might modify data of existing users, whose auth info \
+                      could get invalidated during the fuzzing session."
+    type: object
+    properties:
+      endpoint:
+        description: "The endpoint path (eg '/users') where to execute the create user action. \
+                      It assumes it is on same server of API.\
+                      If not, rather use 'externalEndpointURL'."
+        type: string
+      externalEndpointURL:
+        description: "If the create endpoint is on a different server, here can rather specify the full URL for it."
+        type: string
+      payloadRaw:
+        description: "The raw payload to send, as a string. This will need to contain the template placeholders \
+                      defined in the generators. "
+        type: string
+      verb:
+        $ref: "#/$defs/HttpVerb"
+      contentType:
+        description: "Specify the format in which the payload is sent to the login endpoint. \
+                      A common example is 'application/json'."
+        type: string
+      generators:
+        description: "List of generators for unique/random names to use in payload template resolution."
+        type: array
+        minLength: 1
+        items:
+          $ref: "#/$defs/Generator"
+    x-required:
+      allOf: ["verb","contentType","payloadRaw","generators"]
+      oneOf: ["endpoint","externalEndpointURL"]
+
+  Generator:
+    description: "Parametric producer of unique string values. \
+                  This is needed for example when creating user-names dynamically in the authentication configurations."
+    type: object
+    properties:
+      placeHolder:
+        description: "Placeholder tag used to represent a value generated with this generator. \
+                      String interpolation will be applied to the raw payloads to replace any found instance of \
+                      this placeholder with the generated value."
+        type: string
+        minLength: 1
+        examples:
+        - "{$username}"
+        - "{$email}"
+      minLength:
+        description: "Minimum length of the generated string"
+        type: integer
+        min: 0
+      maxLength:
+        description: "Maximum length of the generated string"
+        type: integer
+        min: 0
+      prefix:
+        description: "Fixed prefix shared by all generated strings"
+        type: string
+        examples:
+        - "user_"
+      postfix:
+        description: "Fixed postfix shared by all generated strings"
+        type: string
+        examples:
+          - "@example.com"
+    x-required: ["placeHolder"]
+
+  LoginEndpoint:
+    description: "Used to represent the case in which a login endpoint is used to obtain the authentication credentials. \
+                      These can be cookies, or a token extracted from the login endpoint's response. \
+                      This token can then be added to an HTTP header in the following requests."
+    type: object
+    properties:
+      endpoint:
+        description: "The endpoint path (eg '/login') where to execute the login. \
+                      It assumes it is on same server of API.\
+                      If not, rather use 'externalEndpointURL'."
+        type: string
+      externalEndpointURL:
+        description: "If the login endpoint is on a different server, here can rather specify the full URL for it."
+        type: string
+      payloadRaw:
+        description: "The raw payload to send, as a string."
+        type: string
+      payloadUserPwd:
+        $ref: "#/$defs/PayloadUsernamePassword"
+      headers:
+        description: "HTTP headers needed when calling the login endpoint. \
+                      Username/password could be passed by headers instead of by the body payload."
+        type: array
+        items:
+          $ref: "#/$defs/Header"
+      verb:
+        $ref: "#/$defs/HttpVerb"
+        ## FIXME: need to schema version with $ref not replacing everything
+#        description: "The verb used to connect to the login endpoint. \
+#                      Most of the time, this will be a 'POST'."
+#        allOf:
+#          - $ref: "#/$defs/HttpVerb"
+#          - type: string
+      contentType:
+        description: "Specify the format in which the payload is sent to the login endpoint. \
+                      A common example is 'application/json'."
+        type: string
+      token:
+        $ref: "#/$defs/TokenHandling"
+      expectCookies:
+        description: "Specify if we are expecting to get cookies from the login endpoint. \
+                      If so, a fuzzer can use those as auth info in following requests, instead of trying to extract \
+                      an auth token from the response payload."
+        type: boolean
+    x-required:
+      allOf: ["verb"]
+      oneOf: ["endpoint","externalEndpointURL"]
+  ###
+  TokenHandling:
+    description: "Specify how to extract the token from the HTTP response, and how to use it for auth in following requests. \
+                  Not needed if rather expect to get back a cookie."
+    type: object
+    properties:
+      extractFrom:
+        description: "Specify from where the token should be extracted in the HTTP response."
+        type: string
+        enum: ["body", "header"]
+      extractSelector:
+        description: "How to extract the token from the HTTP response. \
+                      This depends on where the token is located. \ 
+                      For a 'body' location, the returned body payload like a JSON could have few fields, possibly nested. \ 
+                      In this case, this selector is expressed as a JSON Pointer (RFC 6901). \
+                      For a 'header' location, this selector would represent the name of the HTTP header (e.g., 'X-Auth-Token')."
+        type: string
+      sendIn:
+        description: "The obtained auth token could be send for authentication in following requests in different ways. \
+                      For example, in a HTTP header (e.g., 'Authorization') or a query parameter."
+        type: string
+        enum: ["header", "query"]
+      sendName:
+        description: "Header or query name where the token should be put in the authenticated requests. \
+                      Typically, for a header, this would be 'Authorization'."
+        type: string
+        examples:
+          - "Authorization"
+      sendTemplate:
+        description: "Template with {token} placeholder. \ 
+                      The placeholder will be interpolated with the actual token value.  \
+                      When sending out the obtained token in an HTTP request, specify if there should be any other \
+                      text information around it. \    
+                      For example, when sending the token in an 'Authorization' header, possible \
+                      values could be 'Bearer {token}' and 'JWT {token}'."
+        type: string
+        default: "{token}"
+        examples:
+          - "Bearer {token}"
+          - "JWT {token}"
+    x-required: ["extractFrom", "extractSelector", "sendIn", "sendName"]
+  ###
+  PayloadUsernamePassword:
+    description: "Payload with username and password information. \
+                  It will be automatically formatted in a proper payload based on content type."
+    type: object
+    properties:
+      username:
+        description: "The id of the user."
+        type: string
+      password:
+        description: "The password of the user, in plain-text. This must NOT be hashed."
+        type: string
+      usernameField:
+        description: "The name of the field in the body payload containing the username."
+        type: string
+      passwordField:
+        description: "The name of the field in the body payload containing the password"
+        type: string
+    x-required: ["username","usernameField","password","passwordField"]

webfuzzing_commons/data/fault_categories.json

@@ -0,0 +1,353 @@
+[ {
+  "code" : 100,
+  "descriptiveName" : "HTTP Status 500",
+  "fullDescription" : "The HTTP status code 500 represents a 'Server Error'. Typically, when there is crash in the business logic of the tested backend, like for example due to a null-pointer exception, the server would not crash, but rather return a response with status code 500. Therefore, the presence of such a response 'might' indicate the presence of a fault in the backend. However, such code might also be used for other cases that have nothing to do with software faults. For example, if a request cannot be handled due to issue with the environment, e.g., databases and  communications with other APIs, a status code 500 could be sent. As such, although there is high chances that a 500 status code might point to the presence of a software fault in the tested application, they still need to be manually checked due to possible 'false-positive'.",
+  "group" : "G_1XX",
+  "id" : "HTTP_STATUS_500",
+  "label" : "F100:HTTP Status 500",
+  "testCaseLabel" : "causes500_internalServerError"
+}, {
+  "code" : 101,
+  "descriptiveName" : "HTTP Violation: no-non-standard-codes",
+  "fullDescription" : "HTTP status codes outside the range 100-599 are not valid.",
+  "group" : "G_1XX",
+  "id" : "HTTP_STATUS_NO_NON_STANDARD_CODES",
+  "label" : "F101:HTTP Violation: no-non-standard-codes",
+  "testCaseLabel" : "invalidStatusCode"
+}, {
+  "code" : 102,
+  "descriptiveName" : "HTTP Violation: no-201-if-delete",
+  "fullDescription" : "A DELETE operation is meant to remove a resource, and so it should not states to 201 create one.",
+  "group" : "G_1XX",
+  "id" : "HTTP_STATUS_NO_201_IF_DELETE",
+  "label" : "F102:HTTP Violation: no-201-if-delete",
+  "testCaseLabel" : "201OnDelete"
+}, {
+  "code" : 103,
+  "descriptiveName" : "HTTP Violation: no-201-if-get",
+  "fullDescription" : "A GET operation is meant to retrieve a resource, and so it should not states to 201 create one.",
+  "group" : "G_1XX",
+  "id" : "HTTP_STATUS_NO_201_IF_GET",
+  "label" : "F103:HTTP Violation: no-201-if-get",
+  "testCaseLabel" : "201OnGet"
+}, {
+  "code" : 104,
+  "descriptiveName" : "HTTP Violation: no-201-if-patch",
+  "fullDescription" : "A PATCH operation is meant to modify a resource, and so it should not states to 201 create one.",
+  "group" : "G_1XX",
+  "id" : "HTTP_STATUS_NO_201_IF_PATCH",
+  "label" : "F104:HTTP Violation: no-201-if-patch",
+  "testCaseLabel" : "201OnPatch"
+}, {
+  "code" : 105,
+  "descriptiveName" : "HTTP Violation: no-204-if-content",
+  "fullDescription" : "If a response contains a payload, it should not state it 204 contains none.",
+  "group" : "G_1XX",
+  "id" : "HTTP_STATUS_NO_204_IF_CONTENT",
+  "label" : "F105:HTTP Violation: no-204-if-content",
+  "testCaseLabel" : "204WhenContent"
+}, {
+  "code" : 106,
+  "descriptiveName" : "HTTP Violation: no-413-if-no-payload",
+  "fullDescription" : "Cannot state a payload is too large if there is no payload.",
+  "group" : "G_1XX",
+  "id" : "HTTP_STATUS_NO_413_IF_NO_PAYLOAD",
+  "label" : "F106:HTTP Violation: no-413-if-no-payload",
+  "testCaseLabel" : "413WhenNoPayload"
+}, {
+  "code" : 107,
+  "descriptiveName" : "HTTP Violation: no-415-if-no-payload",
+  "fullDescription" : "Cannot state a payload is of the wrong type if there is no payload.",
+  "group" : "G_1XX",
+  "id" : "HTTP_STATUS_NO_415_IF_NO_PAYLOAD",
+  "label" : "F107:HTTP Violation: no-415-if-no-payload",
+  "testCaseLabel" : "415WhenNoPayload"
+}, {
+  "code" : 108,
+  "descriptiveName" : "HTTP Violation: no-304-if-no-get-or-head",
+  "fullDescription" : "A 304 response is not valid if the request was not either a GET or a HEAD.",
+  "group" : "G_1XX",
+  "id" : "HTTP_STATUS_NO_304_IF_NO_GET_OR_HEAD",
+  "label" : "F108:HTTP Violation: no-304-if-no-get-or-head",
+  "testCaseLabel" : "304OnWrongVerb"
+}, {
+  "code" : 109,
+  "descriptiveName" : "HTTP Violation: no-401-if-no-authenticate",
+  "fullDescription" : "If an API responds with a 401 non-authenticated error, such response MUST contain a www-authenticate header, with the needed information. In HTTP, this is not optional.",
+  "group" : "G_1XX",
+  "id" : "HTTP_STATUS_NO_401_IF_NO_WWW_AUTHENTICATE",
+  "label" : "F109:HTTP Violation: no-401-if-no-authenticate",
+  "testCaseLabel" : "401MissingWwwAuthenticate"
+}, {
+  "code" : 110,
+  "descriptiveName" : "HTTP Violation: no-405-if-no-allow",
+  "fullDescription" : "A 405 Not Allowed response must contain an Allow header specifying what is allowed.",
+  "group" : "G_1XX",
+  "id" : "HTTP_STATUS_NO_405_IF_NO_ALLOW",
+  "label" : "F110:HTTP Violation: no-405-if-no-allow",
+  "testCaseLabel" : "405MissingAllow"
+}, {
+  "code" : 111,
+  "descriptiveName" : "HTTP Violation: no-205-if-content",
+  "fullDescription" : "If a response contains a payload, it should not return a 205, as that requires no payload.",
+  "group" : "G_1XX",
+  "id" : "HTTP_STATUS_NO_205_IF_CONTENT",
+  "label" : "F111:HTTP Violation: no-205-if-content",
+  "testCaseLabel" : "205WhenContent"
+}, {
+  "code" : 112,
+  "descriptiveName" : "HTTP Violation: no-426-if-no-upgrade",
+  "fullDescription" : "A 426 response must contain an Upgrade header with the needed information.",
+  "group" : "G_1XX",
+  "id" : "HTTP_STATUS_NO_426_IF_NO_UPGRADE",
+  "label" : "F112:HTTP Violation: no-426-if-no-upgrade",
+  "testCaseLabel" : "426MissingUpgrade"
+}, {
+  "code" : 113,
+  "descriptiveName" : "HTTP Violation: Resource Still Accessible After Successful DELETE",
+  "fullDescription" : "If a resource is deleted, and the API responds that such request was successful, then such resource should no longer being available. New requests to access it should fail. Otherwise, if it is still possible to access the resource, then it was not really deleted. Then, as such, it means that the delete operation is faulty.",
+  "group" : "G_1XX",
+  "id" : "HTTP_NONWORKING_DELETE",
+  "label" : "F113:HTTP Violation: Resource Still Accessible After Successful DELETE",
+  "testCaseLabel" : "deleteDoesNotWork"
+}, {
+  "code" : 114,
+  "descriptiveName" : "HTTP Violation: A Failed PUT or PATCH Must Not Change The Resource",
+  "fullDescription" : "Write operations that fail due to user errors should not leave side effects on the system. There should not be partial updates: either all are applied, or none.",
+  "group" : "G_1XX",
+  "id" : "HTTP_SIDE_EFFECTS_FAILED_MODIFICATION",
+  "label" : "F114:HTTP Violation: A Failed PUT or PATCH Must Not Change The Resource",
+  "testCaseLabel" : "sideEffectsFailedModification"
+}, {
+  "code" : 115,
+  "descriptiveName" : "HTTP Violation: Repeated PUT Creates Resource With 201 Instead of Updating",
+  "fullDescription" : "A PUT operation can either update (e.g., 200 or 204) or create (201) a resource. If a resource is 201 created with a PUT, a second PUT should update the resource, and not be marked as recreated.",
+  "group" : "G_1XX",
+  "id" : "HTTP_REPEATED_CREATE_PUT",
+  "label" : "F115:HTTP Violation: Repeated PUT Creates Resource With 201 Instead of Updating",
+  "testCaseLabel" : "repeatedCreatePut"
+}, {
+  "code" : 116,
+  "descriptiveName" : "HTTP Violation: Misleading PUT 201 Creates When Resource Already Exists",
+  "fullDescription" : "A PUT operation can either update (e.g., 200 or 204) or create (201) a resource. If a resource already exists, than a PUT operation on it would update it, and not create it.",
+  "group" : "G_1XX",
+  "id" : "HTTP_MISLEADING_CREATE_PUT",
+  "label" : "F116:HTTP Violation: Misleading PUT 201 Creates When Resource Already Exists",
+  "testCaseLabel" : "misleadingCreatePut"
+}, {
+  "code" : 117,
+  "descriptiveName" : "HTTP Violation: The Verb PUT Must Make a Full Replacement",
+  "fullDescription" : "A PUT operation is used to make a full replacement of a resource",
+  "group" : "G_1XX",
+  "id" : "HTTP_PARTIAL_UPDATE_PUT",
+  "label" : "F117:HTTP Violation: The Verb PUT Must Make a Full Replacement",
+  "testCaseLabel" : "partialUpdatePut"
+}, {
+  "code" : 118,
+  "descriptiveName" : "HTTP Violation: PUT Implementation Must be Idempotent",
+  "fullDescription" : "A PUT operation is treated as idempotent. A write operation with a PUT that is not implemented as idempotent might have severe repercussions, as such operation could be automatically repeated any entity involved in the HTTP connection without any warning to the user.",
+  "group" : "G_1XX",
+  "id" : "HTTP_NON_IDEMPOTENT_PUT",
+  "label" : "F118:HTTP Violation: PUT Implementation Must be Idempotent",
+  "testCaseLabel" : "nonIdempotentPut"
+}, {
+  "code" : 119,
+  "descriptiveName" : "HTTP Violation: Invalid JSON Merge Patch",
+  "fullDescription" : "A JSON Merge Path has a specific semantics, defining how values are modified based on the input payloads. Modifying entries not specified in the payload would be a clear implementation fault.",
+  "group" : "G_1XX",
+  "id" : "HTTP_INVALID_MERGE_PATCH",
+  "label" : "F119:HTTP Violation: Invalid JSON Merge Patch",
+  "testCaseLabel" : "invalidMergePatch"
+}, {
+  "code" : 120,
+  "descriptiveName" : "HTTP Violation: Invalid Location HTTP Header",
+  "fullDescription" : "Even outside of 3xx redirections, the Location header can be used to specify for example where newly created resources can be accessed. However, if a Location value point to a path for which there is no valid operation (not necessarily a GET) in the API, then such value might be likely wrong.",
+  "group" : "G_1XX",
+  "id" : "HTTP_INVALID_LOCATION",
+  "label" : "F120:HTTP Violation: Invalid Location HTTP Header",
+  "testCaseLabel" : "returnsInvalidLocationHeader"
+}, {
+  "code" : 121,
+  "descriptiveName" : "HTTP Status 5xx Other Than 500 And 501",
+  "fullDescription" : "Status codes in the 5xx range represent server-side errors. Apart from 500 and 501, any other 5xx code (e.g., 502, 503 and 504) might indicate faults in the tested application, or in how it deals with the services it depends on. Like 500, these codes need a manual check: the environment can cause them (e.g., a temporarily unavailable database).",
+  "group" : "G_1XX",
+  "id" : "HTTP_OTHER_STATUS_5XX",
+  "label" : "F121:HTTP Status 5xx Other Than 500 And 501",
+  "testCaseLabel" : "causes5xx_serverError"
+}, {
+  "code" : 122,
+  "descriptiveName" : "HTTP Violation: Resource Not Found Right After Successful Creation",
+  "fullDescription" : "If a resource is successfully created (e.g., with a POST), then it should be possible to access it right after. If a request on the new resource (e.g., using the identifier returned in the creation response) gives a 404, and nobody deleted it, then either the resource was not created, or the API returns wrong information about how to access it.",
+  "group" : "G_1XX",
+  "id" : "HTTP_CREATED_RESOURCE_NOT_FOUND",
+  "label" : "F122:HTTP Violation: Resource Not Found Right After Successful Creation",
+  "testCaseLabel" : "createdResourceNotFound"
+}, {
+  "code" : 200,
+  "descriptiveName" : "Schema Violation: Received A Response From API With A Structure/Data That Is Not Matching Its Schema",
+  "fullDescription" : "A schema, like for example OpenAPI for REST, defines the structures not only of the inputs but also the outputs of the API. If what returned by an API is not conforming to its schema, then it is a clear fault. However, whether the fault is in the API (i.e., it does not conform to the schema) or in the schema itself (i.e., it is underspecified, or having mistakes) is something that cannot be known for sure without debugging the issue.",
+  "group" : "G_2XX",
+  "id" : "SCHEMA_INVALID_RESPONSE",
+  "label" : "F200:Schema Violation: Received A Response From API With A Structure/Data That Is Not Matching Its Schema",
+  "testCaseLabel" : "returnsMismatchResponseWithSchema"
+}, {
+  "code" : 201,
+  "descriptiveName" : "Schema Violation: Invalid Allow HTTP Header",
+  "fullDescription" : "A returned Allow header specifies what operations (e.g., GET and PATCH) are available on a resource. For consistency, this needs to match what actually defined in the schema of the API, apart from special cases such as HEAD and OPTIONS.",
+  "group" : "G_2XX",
+  "id" : "SCHEMA_INVALID_ALLOW",
+  "label" : "F201:Schema Violation: Invalid Allow HTTP Header",
+  "testCaseLabel" : "invalidAllow"
+}, {
+  "code" : 202,
+  "descriptiveName" : "Schema Violation: no-401-if-no-auth",
+  "fullDescription" : "Should not return a 401 non-authenticated if there is no authentication in the definition of the API (or conversely, authentication definition is wrongly missing).",
+  "group" : "G_2XX",
+  "id" : "SCHEMA_STATUS_NO_401_IF_NO_AUTH",
+  "label" : "F202:Schema Violation: no-401-if-no-auth",
+  "testCaseLabel" : "401WhenNoAuth"
+}, {
+  "code" : 203,
+  "descriptiveName" : "Schema Violation: no-403-if-no-401",
+  "fullDescription" : "Should not return a 403 non-authorized if there is no 401 non-authenticated in the definition of the API (or conversely, such definition is wrongly missing).",
+  "group" : "G_2XX",
+  "id" : "SCHEMA_STATUS_NO_403_IF_NO_401",
+  "label" : "F203:Schema Violation: no-403-if-no-401",
+  "testCaseLabel" : "403WhenNo401"
+}, {
+  "code" : 204,
+  "descriptiveName" : "Schema Violation: has-406-if-accept",
+  "fullDescription" : "If a valid payload is sent based on what declared in the schema, it should not happen that the API responds with a 406 non-valid payload type.",
+  "group" : "G_2XX",
+  "id" : "SCHEMA_STATUS_HAS_406_IF_ACCEPT",
+  "label" : "F204:Schema Violation: has-406-if-accept",
+  "testCaseLabel" : "406WhenValid"
+}, {
+  "code" : 205,
+  "descriptiveName" : "Schema Violation: no-501-if-implemented",
+  "fullDescription" : "If a schema defines an endpoint, then a call on it should not return a 501 Non-Implemented.",
+  "group" : "G_2XX",
+  "id" : "SCHEMA_STATUS_NO_501_IF_IMPLEMENTED",
+  "label" : "F205:Schema Violation: no-501-if-implemented",
+  "testCaseLabel" : "501OnDeclaredEndpoint"
+}, {
+  "code" : 206,
+  "descriptiveName" : "Received Success Response When Sending Wrong Data",
+  "fullDescription" : "API inputs might have constraints (e.g., integers in a specific range, and strings matching a given regular expression). Also, they need be to of specific types (e.g., integers, booleans, strings, dates, arrays and objects). If some input data does not satisfy the type on constraints defined in the schema, then the API should mark the request as 'user error'. However, if for any reason the request is processed successfully, then it is a fault. Either the schema is incorrect, or the API is not properly discarding invalid data.",
+  "group" : "G_2XX",
+  "id" : "SCHEMA_VALIDATION_BYPASS",
+  "label" : "F206:Received Success Response When Sending Wrong Data",
+  "testCaseLabel" : "successOnInvalidInputs"
+}, {
+  "code" : 207,
+  "descriptiveName" : "Received User Error Response When Sending Valid Data",
+  "fullDescription" : "The converse of 'Received Success Response When Sending Wrong Data'. If all input data satisfies the types and constraints defined in the schema, then the API should not mark the request as 'user error' (e.g., with a 400 or 422 in REST). Status codes that do not depend on data validity, like 401, 403, 404, 409 and 429, are not considered here. Either the schema is incorrect (e.g., it is missing some constraints), or the API rejects valid data. As OpenAPI is not able to express all possible types of input constraints (e.g., inter-parameter dependencies), depending on the API this oracle might lead to some false positives.",
+  "group" : "G_2XX",
+  "id" : "SCHEMA_VALID_INPUT_REJECTED",
+  "label" : "F207:Received User Error Response When Sending Valid Data",
+  "testCaseLabel" : "rejectedValidInputs"
+}, {
+  "code" : 300,
+  "descriptiveName" : "SQL Injection (SQLi)",
+  "fullDescription" : "Input data was not properly sanitized. Its use in SQL commands led to execute arbitrary commands on the database. See OWASP Top 10 for more information.",
+  "group" : "G_3XX",
+  "id" : "SECURITY_SQL_INJECTION",
+  "label" : "F300:SQL Injection (SQLi)",
+  "testCaseLabel" : "vulnerableToSQLInjection"
+}, {
+  "code" : 301,
+  "descriptiveName" : "Cross-Site Scripting (XSS)",
+  "fullDescription" : "XSS is an attack in which it is possible to inject malicious scripts into web pages viewed users. This works as well in APIs, if the malicious payload is stored as it is, and then read afterwards by a frontend web application. See OWASP Top 10 for more information.",
+  "group" : "G_3XX",
+  "id" : "SECURITY_XSS_INJECTION",
+  "label" : "F301:Cross-Site Scripting (XSS)",
+  "testCaseLabel" : "vulnerableToXSS"
+}, {
+  "code" : 302,
+  "descriptiveName" : "Server-Side Request Forgery (SSRF)",
+  "fullDescription" : "Some inputs might be URLs, which are then used by the API to retrieve data from external services. However, if the hostnames of these URLs are not verified, the API could be tricked into making requests towards servers it should not to, like for example the 'localhost'. See OWASP Top 10 for more information.",
+  "group" : "G_3XX",
+  "id" : "SECURITY_SSRF",
+  "label" : "F302:Server-Side Request Forgery (SSRF)",
+  "testCaseLabel" : "vulnerableToSSRF"
+}, {
+  "code" : 303,
+  "descriptiveName" : "Mass Assignment",
+  "fullDescription" : "This vulnerability exploits possible active record pattern misconfigurations to modify fields of  a record that should not be accessible via the API. See OWASP Top 10 for more information.",
+  "group" : "G_3XX",
+  "id" : "SECURITY_MASS_ASSIGNMENT",
+  "label" : "F303:Mass Assignment",
+  "testCaseLabel" : "vulnerableToMassAssignment"
+}, {
+  "code" : 304,
+  "descriptiveName" : "Leakage Information Existence of Protected Resource",
+  "fullDescription" : "When accessing a protected resource, could get as a response a 403 not-authorized status code. If the resource does not exist, then returning a 404 would be a security leak, as now the client would know if resources, they have no access to, do exist or not. In these cases, to avoid unauthorized information leakage, a server should consistently either always return 403 or 404 for protected resources, regardless of whether they exist or not.",
+  "group" : "G_3XX",
+  "id" : "SECURITY_EXISTENCE_LEAKAGE",
+  "label" : "F304:Leakage Information Existence of Protected Resource",
+  "testCaseLabel" : "allowsUnauthorizedAccessToProtectedResource"
+}, {
+  "code" : 305,
+  "descriptiveName" : "Wrongly Not Recognized as Authenticated",
+  "fullDescription" : "If the user is providing valid credentials, and if they try to access a protected resource, they should get a status code 403 (not authorized), and not 401 (not authenticated). With a 401, the user might wrongly think there is a problem with their credentials, and not that they have no right to access to that resource. However, to avoid false positives related to misconfigured credentials, these credentials should be first successfully validated on some other resources before flagging a returned 401 as a server fault.",
+  "group" : "G_3XX",
+  "id" : "SECURITY_NOT_RECOGNIZED_AUTHENTICATED",
+  "label" : "F305:Wrongly Not Recognized as Authenticated",
+  "testCaseLabel" : "authenticatedButWronglyToldNot"
+}, {
+  "code" : 306,
+  "descriptiveName" : "Allowed To Modify Resource That Likely Should Had Been Protected",
+  "fullDescription" : "BOLA and BFLA are major security vulnerabilities. To avoid users accessing protected resources, authorization mechanisms are usually put in place. However, it can happen that, on some endpoints, these authorization mechanisms are missing or misconfigured by mistake. This can have disastrous consequences, e.g., a regular user deleting all data from all other users. However, access policies could be arbitrarily complex, where some users might validly interact with some resources of other users. A common example is 'administrator' users. Without a formal specification describing in details the access policies in place, it is hard to say automatically if we are in the case of a BOLA/BFLA vulnerability. Still, some heuristics could be used to flag highly suspicious cases. For example, if a user is blocked with a 403 to do a PUT and a PATCH on a resource, it would be quite suspicious if a DELETE would work just fine on that resource.",
+  "group" : "G_3XX",
+  "id" : "SECURITY_INCONSISTENT_WRITE_AUTHORIZATION",
+  "label" : "F306:Allowed To Modify Resource That Likely Should Had Been Protected",
+  "testCaseLabel" : "missedAuthorizationCheck"
+}, {
+  "code" : 307,
+  "descriptiveName" : "A Protected Resource Is Accessible Without Providing Any Authentication",
+  "fullDescription" : "Protected resources would return a 403 status code when a user that has no rights to them tries to access them. Without providing a formal specification, it might not be possible to know which users have rights or not on a resource. However, being able to access it with no authentication, while some authenticated users are blocked, would be a major security vulnerability. Blocked users could simply drop their authentication credentials to access those protected resources.",
+  "group" : "G_3XX",
+  "id" : "SECURITY_IGNORE_ANONYMOUS",
+  "label" : "F307:A Protected Resource Is Accessible Without Providing Any Authentication",
+  "testCaseLabel" : "ignoreAnonymous"
+}, {
+  "code" : 308,
+  "descriptiveName" : "Anonymous Modifications",
+  "fullDescription" : "Not all systems require authentication when reading data, or creating new ones. Without a formal specification, a fuzzer cannot know if a resource is expected to be public or not. However, 'modifying' data (e.g., with DELETE, PUT and PATCH) with no credentials is problematic.  A user could delete all existing data, or change any new data as soon as it is created by others.",
+  "group" : "G_3XX",
+  "id" : "SECURITY_ANONYMOUS_MODIFICATIONS",
+  "label" : "F308:Anonymous Modifications",
+  "testCaseLabel" : "anonymousModifications"
+}, {
+  "code" : 309,
+  "descriptiveName" : "Leaked Stack Trace",
+  "fullDescription" : "In case of bugs, the internal business logic of the tested application could throw exceptions. For debugging reasons, the responses from the HTTP server could contain the stack-trace of those thrown exceptions. Albeit useful for debugging, those stack-traces could reveal internal details of the system. This would be a security leak if those debugging settings are left in production.",
+  "group" : "G_3XX",
+  "id" : "SECURITY_LEAKED_STACK_TRACES",
+  "label" : "F309:Leaked Stack Trace",
+  "testCaseLabel" : "leakedStackTrace"
+}, {
+  "code" : 310,
+  "descriptiveName" : "Hidden Accessible Endpoint",
+  "fullDescription" : "To test an API, there is the need of a schema that specifies what endpoints can be called. Being able to call endpoints that are not declared in the schema is a potential risk, as those might be either forgotten endpoints, work-in-progress, admin-only endpoints, etc., whose security protections might not be fully tested or in place. Either the call should fail for auth reasons (e.g., 401 and 403 in REST APIs), or the system should respond that the endpoint does not exist (e.g., 405 and 501).",
+  "group" : "G_3XX",
+  "id" : "SECURITY_HIDDEN_ACCESSIBLE_ENDPOINT",
+  "label" : "F310:Hidden Accessible Endpoint",
+  "testCaseLabel" : "hiddenAccessible"
+}, {
+  "code" : 311,
+  "descriptiveName" : "Declared Authentication Is Not Enforced",
+  "fullDescription" : "A schema can declare that an operation requires authentication (e.g., with security requirements in OpenAPI). If a request with valid credentials succeeds, then the same request with no credentials, or with invalid ones, should be rejected (e.g., with a 401 or 403 in REST). Otherwise, either the schema declares authentication by mistake, or the API does not enforce it. Modifications (e.g., DELETE, PUT and PATCH) accepted with no credentials are handled in 'Anonymous Modifications'; this code covers all other cases, including reads and invalid credentials.",
+  "group" : "G_3XX",
+  "id" : "SECURITY_DECLARED_AUTH_NOT_ENFORCED",
+  "label" : "F311:Declared Authentication Is Not Enforced",
+  "testCaseLabel" : "declaredAuthNotEnforced"
+}, {
+  "code" : 312,
+  "descriptiveName" : "Call Timeout",
+  "fullDescription" : "A call that does not get a response within a given time limit, or never gets one, might point to a denial-of-service vulnerability: specific inputs make the API spend excessive time (or resources) handling the request. An attacker could send such requests repeatedly to make the API unavailable to other users. The environment can also cause slow responses (e.g., an overloaded server or a slow database), so these calls need a manual check. The time limit should match the expected performance of the API.",
+  "group" : "G_3XX",
+  "id" : "SECURITY_CALL_TIMEOUT",
+  "label" : "F312:Call Timeout",
+  "testCaseLabel" : "callTimeout"
+} ]