From 0d1f672e1579c0fd8a39d311d8128f2db6eee621 Mon Sep 17 00:00:00 2001 From: arcuri82 Date: Thu, 1 Oct 2026 09:44:00 +0200 Subject: [PATCH 1/3] adding unique id to fault categories --- .../commons/faults/DefinedFaultCategory.java | 6 +++ .../commons/faults/FaultCategory.java | 11 +++++- .../wfc/faults/fault_categories.json | 39 +++++++++++++++++++ 3 files changed, 55 insertions(+), 1 deletion(-) diff --git a/src/main/java/com/webfuzzing/commons/faults/DefinedFaultCategory.java b/src/main/java/com/webfuzzing/commons/faults/DefinedFaultCategory.java index 439bccf..f2b8551 100644 --- a/src/main/java/com/webfuzzing/commons/faults/DefinedFaultCategory.java +++ b/src/main/java/com/webfuzzing/commons/faults/DefinedFaultCategory.java @@ -220,6 +220,12 @@ public enum DefinedFaultCategory implements FaultCategory { this.fullDescription = Objects.requireNonNull(fullDescription); } + @Override + public String getId(){ + //return the name of the enum + return super.name(); + } + @Override public int getCode() { return code; diff --git a/src/main/java/com/webfuzzing/commons/faults/FaultCategory.java b/src/main/java/com/webfuzzing/commons/faults/FaultCategory.java index 3d385c6..a1b3e4f 100644 --- a/src/main/java/com/webfuzzing/commons/faults/FaultCategory.java +++ b/src/main/java/com/webfuzzing/commons/faults/FaultCategory.java @@ -2,9 +2,18 @@ public interface FaultCategory { + /** + * A unique string that uniquely identify this fault category. + * This id is meant to be stable, and should not change among different releases of WFC. + * Fuzzer developers should be able to rely on these ids not changing. + * If for any reason an id must be changed, then that would trigger a new major release of WFC. + * Note the "code" are meant to be stable as well, however, those "might" change between minor releases. + */ + public String getId(); + /** - * A unique code identifying this fault category + * A unique, 3-digit code identifying this fault category */ public int getCode(); diff --git a/src/main/resources/wfc/faults/fault_categories.json b/src/main/resources/wfc/faults/fault_categories.json index 0734413..59871a2 100644 --- a/src/main/resources/wfc/faults/fault_categories.json +++ b/src/main/resources/wfc/faults/fault_categories.json @@ -2,6 +2,7 @@ "code" : 100, "testCaseLabel" : "causes500_internalServerError", "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'.", + "id" : "HTTP_STATUS_500", "descriptiveName" : "HTTP Status 500", "group" : "G_1XX", "label" : "F100:HTTP Status 500" @@ -9,6 +10,7 @@ "code" : 101, "testCaseLabel" : "invalidStatusCode", "fullDescription" : "HTTP status codes outside the range 100-599 are not valid.", + "id" : "HTTP_STATUS_NO_NON_STANDARD_CODES", "descriptiveName" : "HTTP Violation: no-non-standard-codes", "group" : "G_1XX", "label" : "F101:HTTP Violation: no-non-standard-codes" @@ -16,6 +18,7 @@ "code" : 102, "testCaseLabel" : "201OnDelete", "fullDescription" : "A DELETE operation is meant to remove a resource, and so it should not states to 201 create one.", + "id" : "HTTP_STATUS_NO_201_IF_DELETE", "descriptiveName" : "HTTP Violation: no-201-if-delete", "group" : "G_1XX", "label" : "F102:HTTP Violation: no-201-if-delete" @@ -23,6 +26,7 @@ "code" : 103, "testCaseLabel" : "201OnGet", "fullDescription" : "A GET operation is meant to retrieve a resource, and so it should not states to 201 create one.", + "id" : "HTTP_STATUS_NO_201_IF_GET", "descriptiveName" : "HTTP Violation: no-201-if-get", "group" : "G_1XX", "label" : "F103:HTTP Violation: no-201-if-get" @@ -30,6 +34,7 @@ "code" : 104, "testCaseLabel" : "201OnPatch", "fullDescription" : "A PATCH operation is meant to modify a resource, and so it should not states to 201 create one.", + "id" : "HTTP_STATUS_NO_201_IF_PATCH", "descriptiveName" : "HTTP Violation: no-201-if-patch", "group" : "G_1XX", "label" : "F104:HTTP Violation: no-201-if-patch" @@ -37,6 +42,7 @@ "code" : 105, "testCaseLabel" : "204WhenContent", "fullDescription" : "If a response contains a payload, it should not state it 204 contains none.", + "id" : "HTTP_STATUS_NO_204_IF_CONTENT", "descriptiveName" : "HTTP Violation: no-204-if-content", "group" : "G_1XX", "label" : "F105:HTTP Violation: no-204-if-content" @@ -44,6 +50,7 @@ "code" : 106, "testCaseLabel" : "413WhenNoPayload", "fullDescription" : "Cannot state a payload is too large if there is no payload.", + "id" : "HTTP_STATUS_NO_413_IF_NO_PAYLOAD", "descriptiveName" : "HTTP Violation: no-413-if-no-payload", "group" : "G_1XX", "label" : "F106:HTTP Violation: no-413-if-no-payload" @@ -51,6 +58,7 @@ "code" : 107, "testCaseLabel" : "415WhenNoPayload", "fullDescription" : "Cannot state a payload is of the wrong type if there is no payload.", + "id" : "HTTP_STATUS_NO_415_IF_NO_PAYLOAD", "descriptiveName" : "HTTP Violation: no-415-if-no-payload", "group" : "G_1XX", "label" : "F107:HTTP Violation: no-415-if-no-payload" @@ -58,6 +66,7 @@ "code" : 108, "testCaseLabel" : "304OnWrongVerb", "fullDescription" : "A 304 response is not valid if the request was not either a GET or a HEAD.", + "id" : "HTTP_STATUS_NO_304_IF_NO_GET_OR_HEAD", "descriptiveName" : "HTTP Violation: no-304-if-no-get-or-head", "group" : "G_1XX", "label" : "F108:HTTP Violation: no-304-if-no-get-or-head" @@ -65,6 +74,7 @@ "code" : 109, "testCaseLabel" : "401MissingWwwAuthenticate", "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.", + "id" : "HTTP_STATUS_NO_401_IF_NO_WWW_AUTHENTICATE", "descriptiveName" : "HTTP Violation: no-401-if-no-authenticate", "group" : "G_1XX", "label" : "F109:HTTP Violation: no-401-if-no-authenticate" @@ -72,6 +82,7 @@ "code" : 110, "testCaseLabel" : "405MissingAllow", "fullDescription" : "A 405 Not Allowed response must contain an Allow header specifying what is allowed.", + "id" : "HTTP_STATUS_NO_405_IF_NO_ALLOW", "descriptiveName" : "HTTP Violation: no-405-if-no-allow", "group" : "G_1XX", "label" : "F110:HTTP Violation: no-405-if-no-allow" @@ -79,6 +90,7 @@ "code" : 111, "testCaseLabel" : "205WhenContent", "fullDescription" : "If a response contains a payload, it should not return a 205, as that requires no payload.", + "id" : "HTTP_STATUS_NO_205_IF_CONTENT", "descriptiveName" : "HTTP Violation: no-205-if-content", "group" : "G_1XX", "label" : "F111:HTTP Violation: no-205-if-content" @@ -86,6 +98,7 @@ "code" : 112, "testCaseLabel" : "426MissingUpgrade", "fullDescription" : "A 426 response must contain an Upgrade header with the needed information.", + "id" : "HTTP_STATUS_NO_426_IF_NO_UPGRADE", "descriptiveName" : "HTTP Violation: no-426-if-no-upgrade", "group" : "G_1XX", "label" : "F112:HTTP Violation: no-426-if-no-upgrade" @@ -93,6 +106,7 @@ "code" : 113, "testCaseLabel" : "deleteDoesNotWork", "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.", + "id" : "HTTP_NONWORKING_DELETE", "descriptiveName" : "HTTP Violation: Resource Still Accessible After Successful DELETE", "group" : "G_1XX", "label" : "F113:HTTP Violation: Resource Still Accessible After Successful DELETE" @@ -100,6 +114,7 @@ "code" : 114, "testCaseLabel" : "sideEffectsFailedModification", "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.", + "id" : "HTTP_SIDE_EFFECTS_FAILED_MODIFICATION", "descriptiveName" : "HTTP Violation: A Failed PUT or PATCH Must Not Change The Resource", "group" : "G_1XX", "label" : "F114:HTTP Violation: A Failed PUT or PATCH Must Not Change The Resource" @@ -107,6 +122,7 @@ "code" : 115, "testCaseLabel" : "repeatedCreatePut", "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.", + "id" : "HTTP_REPEATED_CREATE_PUT", "descriptiveName" : "HTTP Violation: Repeated PUT Creates Resource With 201 Instead of Updating", "group" : "G_1XX", "label" : "F115:HTTP Violation: Repeated PUT Creates Resource With 201 Instead of Updating" @@ -114,6 +130,7 @@ "code" : 116, "testCaseLabel" : "misleadingCreatePut", "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.", + "id" : "HTTP_MISLEADING_CREATE_PUT", "descriptiveName" : "HTTP Violation: Misleading PUT 201 Creates When Resource Already Exists", "group" : "G_1XX", "label" : "F116:HTTP Violation: Misleading PUT 201 Creates When Resource Already Exists" @@ -121,6 +138,7 @@ "code" : 117, "testCaseLabel" : "partialUpdatePut", "fullDescription" : "A PUT operation is used to make a full replacement of a resource", + "id" : "HTTP_PARTIAL_UPDATE_PUT", "descriptiveName" : "HTTP Violation: The Verb PUT Must Make a Full Replacement", "group" : "G_1XX", "label" : "F117:HTTP Violation: The Verb PUT Must Make a Full Replacement" @@ -128,6 +146,7 @@ "code" : 118, "testCaseLabel" : "nonIdempotentPut", "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.", + "id" : "HTTP_NON_IDEMPOTENT_PUT", "descriptiveName" : "HTTP Violation: PUT Implementation Must be Idempotent", "group" : "G_1XX", "label" : "F118:HTTP Violation: PUT Implementation Must be Idempotent" @@ -135,6 +154,7 @@ "code" : 119, "testCaseLabel" : "invalidMergePatch", "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.", + "id" : "HTTP_INVALID_MERGE_PATCH", "descriptiveName" : "HTTP Violation: Invalid JSON Merge Patch", "group" : "G_1XX", "label" : "F119:HTTP Violation: Invalid JSON Merge Patch" @@ -142,6 +162,7 @@ "code" : 120, "testCaseLabel" : "returnsInvalidLocationHeader", "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.", + "id" : "HTTP_INVALID_LOCATION", "descriptiveName" : "HTTP Violation: Invalid Location HTTP Header", "group" : "G_1XX", "label" : "F120:HTTP Violation: Invalid Location HTTP Header" @@ -149,6 +170,7 @@ "code" : 200, "testCaseLabel" : "returnsMismatchResponseWithSchema", "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.", + "id" : "SCHEMA_INVALID_RESPONSE", "descriptiveName" : "Schema Violation: Received A Response From API With A Structure/Data That Is Not Matching Its Schema", "group" : "G_2XX", "label" : "F200:Schema Violation: Received A Response From API With A Structure/Data That Is Not Matching Its Schema" @@ -156,6 +178,7 @@ "code" : 201, "testCaseLabel" : "invalidAllow", "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.", + "id" : "SCHEMA_INVALID_ALLOW", "descriptiveName" : "Schema Violation: Invalid Allow HTTP Header", "group" : "G_2XX", "label" : "F201:Schema Violation: Invalid Allow HTTP Header" @@ -163,6 +186,7 @@ "code" : 202, "testCaseLabel" : "401WhenNoAuth", "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).", + "id" : "SCHEMA_STATUS_NO_401_IF_NO_AUTH", "descriptiveName" : "Schema Violation: no-401-if-no-auth", "group" : "G_2XX", "label" : "F202:Schema Violation: no-401-if-no-auth" @@ -170,6 +194,7 @@ "code" : 203, "testCaseLabel" : "403WhenNo401", "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).", + "id" : "SCHEMA_STATUS_NO_403_IF_NO_401", "descriptiveName" : "Schema Violation: no-403-if-no-401", "group" : "G_2XX", "label" : "F203:Schema Violation: no-403-if-no-401" @@ -177,6 +202,7 @@ "code" : 204, "testCaseLabel" : "406WhenValid", "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.", + "id" : "SCHEMA_STATUS_HAS_406_IF_ACCEPT", "descriptiveName" : "Schema Violation: has-406-if-accept", "group" : "G_2XX", "label" : "F204:Schema Violation: has-406-if-accept" @@ -184,6 +210,7 @@ "code" : 205, "testCaseLabel" : "501OnDeclaredEndpoint", "fullDescription" : "If a schema defines an endpoint, then a call on it should not return a 501 Non-Implemented.", + "id" : "SCHEMA_STATUS_NO_501_IF_IMPLEMENTED", "descriptiveName" : "Schema Violation: no-501-if-implemented", "group" : "G_2XX", "label" : "F205:Schema Violation: no-501-if-implemented" @@ -191,6 +218,7 @@ "code" : 206, "testCaseLabel" : "successOnInvalidInputs", "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.", + "id" : "SCHEMA_VALIDATION_BYPASS", "descriptiveName" : "Received Success Response When Sending Wrong Data", "group" : "G_2XX", "label" : "F206:Received Success Response When Sending Wrong Data" @@ -198,6 +226,7 @@ "code" : 300, "testCaseLabel" : "vulnerableToSQLInjection", "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.", + "id" : "SECURITY_SQL_INJECTION", "descriptiveName" : "SQL Injection (SQLi)", "group" : "G_3XX", "label" : "F300:SQL Injection (SQLi)" @@ -205,6 +234,7 @@ "code" : 301, "testCaseLabel" : "vulnerableToXSS", "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.", + "id" : "SECURITY_XSS", "descriptiveName" : "Cross-Site Scripting (XSS)", "group" : "G_3XX", "label" : "F301:Cross-Site Scripting (XSS)" @@ -212,6 +242,7 @@ "code" : 302, "testCaseLabel" : "vulnerableToSSRF", "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.", + "id" : "SECURITY_SSRF", "descriptiveName" : "Server-Side Request Forgery (SSRF)", "group" : "G_3XX", "label" : "F302:Server-Side Request Forgery (SSRF)" @@ -219,6 +250,7 @@ "code" : 303, "testCaseLabel" : "vulnerableToMassAssignment", "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.", + "id" : "SECURITY_MASS_ASSIGNMENT", "descriptiveName" : "Mass Assignment", "group" : "G_3XX", "label" : "F303:Mass Assignment" @@ -226,6 +258,7 @@ "code" : 304, "testCaseLabel" : "allowsUnauthorizedAccessToProtectedResource", "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.", + "id" : "SECURITY_EXISTENCE_LEAKAGE", "descriptiveName" : "Leakage Information Existence of Protected Resource", "group" : "G_3XX", "label" : "F304:Leakage Information Existence of Protected Resource" @@ -233,6 +266,7 @@ "code" : 305, "testCaseLabel" : "authenticatedButWronglyToldNot", "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.", + "id" : "SECURITY_NOT_RECOGNIZED_AUTHENTICATED", "descriptiveName" : "Wrongly Not Recognized as Authenticated", "group" : "G_3XX", "label" : "F305:Wrongly Not Recognized as Authenticated" @@ -240,6 +274,7 @@ "code" : 306, "testCaseLabel" : "missedAuthorizationCheck", "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.", + "id" : "SECURITY_WRONG_AUTHORIZATION", "descriptiveName" : "Allowed To Modify Resource That Likely Should Had Been Protected", "group" : "G_3XX", "label" : "F306:Allowed To Modify Resource That Likely Should Had Been Protected" @@ -247,6 +282,7 @@ "code" : 307, "testCaseLabel" : "ignoreAnonymous", "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.", + "id" : "SECURITY_IGNORE_ANONYMOUS", "descriptiveName" : "A Protected Resource Is Accessible Without Providing Any Authentication", "group" : "G_3XX", "label" : "F307:A Protected Resource Is Accessible Without Providing Any Authentication" @@ -254,6 +290,7 @@ "code" : 308, "testCaseLabel" : "anonymousModifications", "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.", + "id" : "SECURITY_ANONYMOUS_MODIFICATIONS", "descriptiveName" : "Anonymous Modifications", "group" : "G_3XX", "label" : "F308:Anonymous Modifications" @@ -261,6 +298,7 @@ "code" : 309, "testCaseLabel" : "leakedStackTrace", "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.", + "id" : "SECURITY_LEAKED_STACK_TRACES", "descriptiveName" : "Leaked Stack Trace", "group" : "G_3XX", "label" : "F309:Leaked Stack Trace" @@ -268,6 +306,7 @@ "code" : 310, "testCaseLabel" : "hiddenAccessible", "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).", + "id" : "SECURITY_HIDDEN_ACCESSIBLE_ENDPOINT", "descriptiveName" : "Hidden Accessible Endpoint", "group" : "G_3XX", "label" : "F310:Hidden Accessible Endpoint" From ad671d6a7373f5ba98165c98227f64a322fbd260 Mon Sep 17 00:00:00 2001 From: arcuri82 Date: Thu, 1 Oct 2026 09:54:29 +0200 Subject: [PATCH 2/3] fixed ordering of fields in generated json --- .../wfc/faults/fault_categories.json | 312 +++++++++--------- .../commons/faults/FaultsToJson.java | 2 + 2 files changed, 158 insertions(+), 156 deletions(-) diff --git a/src/main/resources/wfc/faults/fault_categories.json b/src/main/resources/wfc/faults/fault_categories.json index 59871a2..81942dc 100644 --- a/src/main/resources/wfc/faults/fault_categories.json +++ b/src/main/resources/wfc/faults/fault_categories.json @@ -1,313 +1,313 @@ [ { "code" : 100, - "testCaseLabel" : "causes500_internalServerError", - "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'.", - "id" : "HTTP_STATUS_500", "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", - "label" : "F100:HTTP Status 500" + "id" : "HTTP_STATUS_500", + "label" : "F100:HTTP Status 500", + "testCaseLabel" : "causes500_internalServerError" }, { "code" : 101, - "testCaseLabel" : "invalidStatusCode", - "fullDescription" : "HTTP status codes outside the range 100-599 are not valid.", - "id" : "HTTP_STATUS_NO_NON_STANDARD_CODES", "descriptiveName" : "HTTP Violation: no-non-standard-codes", + "fullDescription" : "HTTP status codes outside the range 100-599 are not valid.", "group" : "G_1XX", - "label" : "F101:HTTP Violation: no-non-standard-codes" + "id" : "HTTP_STATUS_NO_NON_STANDARD_CODES", + "label" : "F101:HTTP Violation: no-non-standard-codes", + "testCaseLabel" : "invalidStatusCode" }, { "code" : 102, - "testCaseLabel" : "201OnDelete", - "fullDescription" : "A DELETE operation is meant to remove a resource, and so it should not states to 201 create one.", - "id" : "HTTP_STATUS_NO_201_IF_DELETE", "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", - "label" : "F102:HTTP Violation: no-201-if-delete" + "id" : "HTTP_STATUS_NO_201_IF_DELETE", + "label" : "F102:HTTP Violation: no-201-if-delete", + "testCaseLabel" : "201OnDelete" }, { "code" : 103, - "testCaseLabel" : "201OnGet", - "fullDescription" : "A GET operation is meant to retrieve a resource, and so it should not states to 201 create one.", - "id" : "HTTP_STATUS_NO_201_IF_GET", "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", - "label" : "F103:HTTP Violation: no-201-if-get" + "id" : "HTTP_STATUS_NO_201_IF_GET", + "label" : "F103:HTTP Violation: no-201-if-get", + "testCaseLabel" : "201OnGet" }, { "code" : 104, - "testCaseLabel" : "201OnPatch", - "fullDescription" : "A PATCH operation is meant to modify a resource, and so it should not states to 201 create one.", - "id" : "HTTP_STATUS_NO_201_IF_PATCH", "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", - "label" : "F104:HTTP Violation: no-201-if-patch" + "id" : "HTTP_STATUS_NO_201_IF_PATCH", + "label" : "F104:HTTP Violation: no-201-if-patch", + "testCaseLabel" : "201OnPatch" }, { "code" : 105, - "testCaseLabel" : "204WhenContent", - "fullDescription" : "If a response contains a payload, it should not state it 204 contains none.", - "id" : "HTTP_STATUS_NO_204_IF_CONTENT", "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", - "label" : "F105:HTTP Violation: no-204-if-content" + "id" : "HTTP_STATUS_NO_204_IF_CONTENT", + "label" : "F105:HTTP Violation: no-204-if-content", + "testCaseLabel" : "204WhenContent" }, { "code" : 106, - "testCaseLabel" : "413WhenNoPayload", - "fullDescription" : "Cannot state a payload is too large if there is no payload.", - "id" : "HTTP_STATUS_NO_413_IF_NO_PAYLOAD", "descriptiveName" : "HTTP Violation: no-413-if-no-payload", + "fullDescription" : "Cannot state a payload is too large if there is no payload.", "group" : "G_1XX", - "label" : "F106:HTTP Violation: no-413-if-no-payload" + "id" : "HTTP_STATUS_NO_413_IF_NO_PAYLOAD", + "label" : "F106:HTTP Violation: no-413-if-no-payload", + "testCaseLabel" : "413WhenNoPayload" }, { "code" : 107, - "testCaseLabel" : "415WhenNoPayload", - "fullDescription" : "Cannot state a payload is of the wrong type if there is no payload.", - "id" : "HTTP_STATUS_NO_415_IF_NO_PAYLOAD", "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", - "label" : "F107:HTTP Violation: no-415-if-no-payload" + "id" : "HTTP_STATUS_NO_415_IF_NO_PAYLOAD", + "label" : "F107:HTTP Violation: no-415-if-no-payload", + "testCaseLabel" : "415WhenNoPayload" }, { "code" : 108, - "testCaseLabel" : "304OnWrongVerb", - "fullDescription" : "A 304 response is not valid if the request was not either a GET or a HEAD.", - "id" : "HTTP_STATUS_NO_304_IF_NO_GET_OR_HEAD", "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", - "label" : "F108:HTTP Violation: no-304-if-no-get-or-head" + "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, - "testCaseLabel" : "401MissingWwwAuthenticate", - "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.", - "id" : "HTTP_STATUS_NO_401_IF_NO_WWW_AUTHENTICATE", "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", - "label" : "F109:HTTP Violation: no-401-if-no-authenticate" + "id" : "HTTP_STATUS_NO_401_IF_NO_WWW_AUTHENTICATE", + "label" : "F109:HTTP Violation: no-401-if-no-authenticate", + "testCaseLabel" : "401MissingWwwAuthenticate" }, { "code" : 110, - "testCaseLabel" : "405MissingAllow", - "fullDescription" : "A 405 Not Allowed response must contain an Allow header specifying what is allowed.", - "id" : "HTTP_STATUS_NO_405_IF_NO_ALLOW", "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", - "label" : "F110:HTTP Violation: no-405-if-no-allow" + "id" : "HTTP_STATUS_NO_405_IF_NO_ALLOW", + "label" : "F110:HTTP Violation: no-405-if-no-allow", + "testCaseLabel" : "405MissingAllow" }, { "code" : 111, - "testCaseLabel" : "205WhenContent", - "fullDescription" : "If a response contains a payload, it should not return a 205, as that requires no payload.", - "id" : "HTTP_STATUS_NO_205_IF_CONTENT", "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", - "label" : "F111:HTTP Violation: no-205-if-content" + "id" : "HTTP_STATUS_NO_205_IF_CONTENT", + "label" : "F111:HTTP Violation: no-205-if-content", + "testCaseLabel" : "205WhenContent" }, { "code" : 112, - "testCaseLabel" : "426MissingUpgrade", - "fullDescription" : "A 426 response must contain an Upgrade header with the needed information.", - "id" : "HTTP_STATUS_NO_426_IF_NO_UPGRADE", "descriptiveName" : "HTTP Violation: no-426-if-no-upgrade", + "fullDescription" : "A 426 response must contain an Upgrade header with the needed information.", "group" : "G_1XX", - "label" : "F112:HTTP Violation: no-426-if-no-upgrade" + "id" : "HTTP_STATUS_NO_426_IF_NO_UPGRADE", + "label" : "F112:HTTP Violation: no-426-if-no-upgrade", + "testCaseLabel" : "426MissingUpgrade" }, { "code" : 113, - "testCaseLabel" : "deleteDoesNotWork", - "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.", - "id" : "HTTP_NONWORKING_DELETE", "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", - "label" : "F113:HTTP Violation: Resource Still Accessible After Successful DELETE" + "id" : "HTTP_NONWORKING_DELETE", + "label" : "F113:HTTP Violation: Resource Still Accessible After Successful DELETE", + "testCaseLabel" : "deleteDoesNotWork" }, { "code" : 114, - "testCaseLabel" : "sideEffectsFailedModification", - "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.", - "id" : "HTTP_SIDE_EFFECTS_FAILED_MODIFICATION", "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", - "label" : "F114:HTTP Violation: A Failed PUT or PATCH Must Not Change The Resource" + "id" : "HTTP_SIDE_EFFECTS_FAILED_MODIFICATION", + "label" : "F114:HTTP Violation: A Failed PUT or PATCH Must Not Change The Resource", + "testCaseLabel" : "sideEffectsFailedModification" }, { "code" : 115, - "testCaseLabel" : "repeatedCreatePut", - "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.", - "id" : "HTTP_REPEATED_CREATE_PUT", "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", - "label" : "F115:HTTP Violation: Repeated PUT Creates Resource With 201 Instead of Updating" + "id" : "HTTP_REPEATED_CREATE_PUT", + "label" : "F115:HTTP Violation: Repeated PUT Creates Resource With 201 Instead of Updating", + "testCaseLabel" : "repeatedCreatePut" }, { "code" : 116, - "testCaseLabel" : "misleadingCreatePut", - "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.", - "id" : "HTTP_MISLEADING_CREATE_PUT", "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", - "label" : "F116:HTTP Violation: Misleading PUT 201 Creates When Resource Already Exists" + "id" : "HTTP_MISLEADING_CREATE_PUT", + "label" : "F116:HTTP Violation: Misleading PUT 201 Creates When Resource Already Exists", + "testCaseLabel" : "misleadingCreatePut" }, { "code" : 117, - "testCaseLabel" : "partialUpdatePut", - "fullDescription" : "A PUT operation is used to make a full replacement of a resource", - "id" : "HTTP_PARTIAL_UPDATE_PUT", "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", - "label" : "F117:HTTP Violation: The Verb PUT Must Make a Full Replacement" + "id" : "HTTP_PARTIAL_UPDATE_PUT", + "label" : "F117:HTTP Violation: The Verb PUT Must Make a Full Replacement", + "testCaseLabel" : "partialUpdatePut" }, { "code" : 118, - "testCaseLabel" : "nonIdempotentPut", - "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.", - "id" : "HTTP_NON_IDEMPOTENT_PUT", "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", - "label" : "F118:HTTP Violation: PUT Implementation Must be Idempotent" + "id" : "HTTP_NON_IDEMPOTENT_PUT", + "label" : "F118:HTTP Violation: PUT Implementation Must be Idempotent", + "testCaseLabel" : "nonIdempotentPut" }, { "code" : 119, - "testCaseLabel" : "invalidMergePatch", - "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.", - "id" : "HTTP_INVALID_MERGE_PATCH", "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", - "label" : "F119:HTTP Violation: Invalid JSON Merge Patch" + "id" : "HTTP_INVALID_MERGE_PATCH", + "label" : "F119:HTTP Violation: Invalid JSON Merge Patch", + "testCaseLabel" : "invalidMergePatch" }, { "code" : 120, - "testCaseLabel" : "returnsInvalidLocationHeader", - "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.", - "id" : "HTTP_INVALID_LOCATION", "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", - "label" : "F120:HTTP Violation: Invalid Location HTTP Header" + "id" : "HTTP_INVALID_LOCATION", + "label" : "F120:HTTP Violation: Invalid Location HTTP Header", + "testCaseLabel" : "returnsInvalidLocationHeader" }, { "code" : 200, - "testCaseLabel" : "returnsMismatchResponseWithSchema", - "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.", - "id" : "SCHEMA_INVALID_RESPONSE", "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", - "label" : "F200:Schema Violation: Received A Response From API With A Structure/Data That Is Not Matching Its Schema" + "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, - "testCaseLabel" : "invalidAllow", - "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.", - "id" : "SCHEMA_INVALID_ALLOW", "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", - "label" : "F201:Schema Violation: Invalid Allow HTTP Header" + "id" : "SCHEMA_INVALID_ALLOW", + "label" : "F201:Schema Violation: Invalid Allow HTTP Header", + "testCaseLabel" : "invalidAllow" }, { "code" : 202, - "testCaseLabel" : "401WhenNoAuth", - "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).", - "id" : "SCHEMA_STATUS_NO_401_IF_NO_AUTH", "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", - "label" : "F202:Schema Violation: no-401-if-no-auth" + "id" : "SCHEMA_STATUS_NO_401_IF_NO_AUTH", + "label" : "F202:Schema Violation: no-401-if-no-auth", + "testCaseLabel" : "401WhenNoAuth" }, { "code" : 203, - "testCaseLabel" : "403WhenNo401", - "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).", - "id" : "SCHEMA_STATUS_NO_403_IF_NO_401", "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", - "label" : "F203:Schema Violation: no-403-if-no-401" + "id" : "SCHEMA_STATUS_NO_403_IF_NO_401", + "label" : "F203:Schema Violation: no-403-if-no-401", + "testCaseLabel" : "403WhenNo401" }, { "code" : 204, - "testCaseLabel" : "406WhenValid", - "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.", - "id" : "SCHEMA_STATUS_HAS_406_IF_ACCEPT", "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", - "label" : "F204:Schema Violation: has-406-if-accept" + "id" : "SCHEMA_STATUS_HAS_406_IF_ACCEPT", + "label" : "F204:Schema Violation: has-406-if-accept", + "testCaseLabel" : "406WhenValid" }, { "code" : 205, - "testCaseLabel" : "501OnDeclaredEndpoint", - "fullDescription" : "If a schema defines an endpoint, then a call on it should not return a 501 Non-Implemented.", - "id" : "SCHEMA_STATUS_NO_501_IF_IMPLEMENTED", "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", - "label" : "F205:Schema Violation: no-501-if-implemented" + "id" : "SCHEMA_STATUS_NO_501_IF_IMPLEMENTED", + "label" : "F205:Schema Violation: no-501-if-implemented", + "testCaseLabel" : "501OnDeclaredEndpoint" }, { "code" : 206, - "testCaseLabel" : "successOnInvalidInputs", - "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.", - "id" : "SCHEMA_VALIDATION_BYPASS", "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", - "label" : "F206:Received Success Response When Sending Wrong Data" + "id" : "SCHEMA_VALIDATION_BYPASS", + "label" : "F206:Received Success Response When Sending Wrong Data", + "testCaseLabel" : "successOnInvalidInputs" }, { "code" : 300, - "testCaseLabel" : "vulnerableToSQLInjection", - "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.", - "id" : "SECURITY_SQL_INJECTION", "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", - "label" : "F300:SQL Injection (SQLi)" + "id" : "SECURITY_SQL_INJECTION", + "label" : "F300:SQL Injection (SQLi)", + "testCaseLabel" : "vulnerableToSQLInjection" }, { "code" : 301, - "testCaseLabel" : "vulnerableToXSS", - "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.", - "id" : "SECURITY_XSS", "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", - "label" : "F301:Cross-Site Scripting (XSS)" + "id" : "SECURITY_XSS", + "label" : "F301:Cross-Site Scripting (XSS)", + "testCaseLabel" : "vulnerableToXSS" }, { "code" : 302, - "testCaseLabel" : "vulnerableToSSRF", - "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.", - "id" : "SECURITY_SSRF", "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", - "label" : "F302:Server-Side Request Forgery (SSRF)" + "id" : "SECURITY_SSRF", + "label" : "F302:Server-Side Request Forgery (SSRF)", + "testCaseLabel" : "vulnerableToSSRF" }, { "code" : 303, - "testCaseLabel" : "vulnerableToMassAssignment", - "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.", - "id" : "SECURITY_MASS_ASSIGNMENT", "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", - "label" : "F303:Mass Assignment" + "id" : "SECURITY_MASS_ASSIGNMENT", + "label" : "F303:Mass Assignment", + "testCaseLabel" : "vulnerableToMassAssignment" }, { "code" : 304, - "testCaseLabel" : "allowsUnauthorizedAccessToProtectedResource", - "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.", - "id" : "SECURITY_EXISTENCE_LEAKAGE", "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", - "label" : "F304:Leakage Information Existence of Protected Resource" + "id" : "SECURITY_EXISTENCE_LEAKAGE", + "label" : "F304:Leakage Information Existence of Protected Resource", + "testCaseLabel" : "allowsUnauthorizedAccessToProtectedResource" }, { "code" : 305, - "testCaseLabel" : "authenticatedButWronglyToldNot", - "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.", - "id" : "SECURITY_NOT_RECOGNIZED_AUTHENTICATED", "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", - "label" : "F305:Wrongly Not Recognized as Authenticated" + "id" : "SECURITY_NOT_RECOGNIZED_AUTHENTICATED", + "label" : "F305:Wrongly Not Recognized as Authenticated", + "testCaseLabel" : "authenticatedButWronglyToldNot" }, { "code" : 306, - "testCaseLabel" : "missedAuthorizationCheck", - "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.", - "id" : "SECURITY_WRONG_AUTHORIZATION", "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", - "label" : "F306:Allowed To Modify Resource That Likely Should Had Been Protected" + "id" : "SECURITY_WRONG_AUTHORIZATION", + "label" : "F306:Allowed To Modify Resource That Likely Should Had Been Protected", + "testCaseLabel" : "missedAuthorizationCheck" }, { "code" : 307, - "testCaseLabel" : "ignoreAnonymous", - "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.", - "id" : "SECURITY_IGNORE_ANONYMOUS", "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", - "label" : "F307:A Protected Resource Is Accessible Without Providing Any Authentication" + "id" : "SECURITY_IGNORE_ANONYMOUS", + "label" : "F307:A Protected Resource Is Accessible Without Providing Any Authentication", + "testCaseLabel" : "ignoreAnonymous" }, { "code" : 308, - "testCaseLabel" : "anonymousModifications", - "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.", - "id" : "SECURITY_ANONYMOUS_MODIFICATIONS", "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", - "label" : "F308:Anonymous Modifications" + "id" : "SECURITY_ANONYMOUS_MODIFICATIONS", + "label" : "F308:Anonymous Modifications", + "testCaseLabel" : "anonymousModifications" }, { "code" : 309, - "testCaseLabel" : "leakedStackTrace", - "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.", - "id" : "SECURITY_LEAKED_STACK_TRACES", "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", - "label" : "F309:Leaked Stack Trace" + "id" : "SECURITY_LEAKED_STACK_TRACES", + "label" : "F309:Leaked Stack Trace", + "testCaseLabel" : "leakedStackTrace" }, { "code" : 310, - "testCaseLabel" : "hiddenAccessible", - "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).", - "id" : "SECURITY_HIDDEN_ACCESSIBLE_ENDPOINT", "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", - "label" : "F310:Hidden Accessible Endpoint" + "id" : "SECURITY_HIDDEN_ACCESSIBLE_ENDPOINT", + "label" : "F310:Hidden Accessible Endpoint", + "testCaseLabel" : "hiddenAccessible" } ] \ No newline at end of file diff --git a/src/test/java/com/webfuzzing/commons/faults/FaultsToJson.java b/src/test/java/com/webfuzzing/commons/faults/FaultsToJson.java index 99e7f9f..f63f33f 100644 --- a/src/test/java/com/webfuzzing/commons/faults/FaultsToJson.java +++ b/src/test/java/com/webfuzzing/commons/faults/FaultsToJson.java @@ -2,6 +2,7 @@ import com.fasterxml.jackson.annotation.JsonFormat; import com.fasterxml.jackson.core.JsonProcessingException; +import com.fasterxml.jackson.databind.MapperFeature; import com.fasterxml.jackson.databind.ObjectMapper; import java.io.IOException; @@ -29,6 +30,7 @@ public static void main(String[] args) { public static String getJsonFromClass(){ ObjectMapper mapper = new ObjectMapper(); + mapper.configure(MapperFeature.SORT_PROPERTIES_ALPHABETICALLY, true); mapper.configOverride(DefinedFaultCategory.class) .setFormat(JsonFormat.Value.forShape(JsonFormat.Shape.OBJECT)); From 1226c9d88bcea0ae6f9bcc4fe04d20bda8224427 Mon Sep 17 00:00:00 2001 From: arcuri82 Date: Fri, 2 Oct 2026 13:28:47 +0200 Subject: [PATCH 3/3] recreated fault json after merge --- .../wfc/faults/fault_categories.json | 44 ++++++++++++++++++- 1 file changed, 42 insertions(+), 2 deletions(-) diff --git a/src/main/resources/wfc/faults/fault_categories.json b/src/main/resources/wfc/faults/fault_categories.json index 81942dc..a883045 100644 --- a/src/main/resources/wfc/faults/fault_categories.json +++ b/src/main/resources/wfc/faults/fault_categories.json @@ -166,6 +166,22 @@ "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", @@ -222,6 +238,14 @@ "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)", @@ -235,7 +259,7 @@ "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", + "id" : "SECURITY_XSS_INJECTION", "label" : "F301:Cross-Site Scripting (XSS)", "testCaseLabel" : "vulnerableToXSS" }, { @@ -275,7 +299,7 @@ "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_WRONG_AUTHORIZATION", + "id" : "SECURITY_INCONSISTENT_WRITE_AUTHORIZATION", "label" : "F306:Allowed To Modify Resource That Likely Should Had Been Protected", "testCaseLabel" : "missedAuthorizationCheck" }, { @@ -310,4 +334,20 @@ "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" } ] \ No newline at end of file