Writing Security Rules on ApiFort

This guide explains how to define and customize security rules on the ApiFort platform. It covers the structure of a rule, the meaning of each field, and how to build effective rules tailored to specific security requirements. The goal is to help both internal teams and customers define rules that align with their security needs.

General Structure

Each rule is defined in YAML format and includes the following main sections:

YAML

id: RULE_ID

info:
  name: Rule Name
  description: Short description
  details: >
    Long explanation and technical details
  impact: Description of potential impact
  solution: Recommended mitigation or fix
  category:
    name: INJ / SM / BOLA / RCE etc.
    short_name: Abbreviation
    display_name: Display label
  sub_category: SUB_CATEGORY
  severity: LOW / MEDIUM / HIGH / CRITICAL
  references:
    - URL
  cwe:
    - CWE Code(s)
  cve:
    - CVE Number(s) (if available)
  owasp: APIx:2023 OWASP Category

execute:
  url_matches: REGEX  # Match the request URL
  request_payload_contains: ["payload"]
  request_payload_matches: REGEX
  request_header_name: "Header-Name"
  request_header_value_matches: REGEX
  body_parameter_name_matches: REGEX
  body_parameter_value_command: sqlparse
  http_method_contains: [ "PUT", "POST", "PATCH" ]
  request_payload_contains_all: [ "role", "admin", "etc." ]
  request_payload_contains: [ "email", "login", "etc." ]
  user_limit: false

limit:
  capacity: 10                  # Number of allowed requests
  duration_in_minutes: 1        # Time window in minutes
  ip_based: true                # Apply limit per IP

validate:
  response_code_equals: 200
  response_code_between: [200, 299]
  response_payload_contains: ["Expected payloads"]
  response_payload_contains_all: ["Mandatory payloads"]
  response_payload_matches: REGEX
  response_payload_not_contains: ["Unwanted payloads"]

Notes

• All regex patterns should be tested before deployment.
• Fields can be used in combination to create more precise rules.
• Use clear and consistent naming conventions for id and info.name to improve rule management.

Rule Components

This section describes the key components of a security rule on the APIFort platform.

1. id

A unique identifier for the rule. All rules are tracked using this ID.

2. info

Provides general metadata about the rule:

• name: A readable name for the rule.

• description: A short summary of the rule.

• details: Technical explanation and background.

• impact: Potential impact of the vulnerability.

• solution: Suggested remediation or fix.

• references: Relevant URLs or documentation.

• cwe, cve: Related vulnerability codes, if applicable.

3. category

Defines the type of vulnerability the rule targets, based on OWASP, CWE, or internal classification:

• INJ: Injection

• SM: Security Misconfiguration

• BOLA: Broken Object Level Authorization

• RCE: Remote Code Execution and others

4. execute

Specifies the conditions under which the rule is triggered. Common fields include:

• url_matches: Regex pattern to match request URL

• request_payload_contains: Triggered if payload contains specified values

• request_payload_matches: Payload matched via regex

• request_header_name + request_header_value_matches: Header filtering by name and regex

• body_parameter_name_matches: Regex for parameter names in body

• body_parameter_value_command: Specialized parser (e.g., sqlparse)

• http_method_contains: Filter by HTTP methods (PUT, POST, etc.)

• request_payload_contains_all: Triggers only if all values are present

• user_limit: Enables per-user restrictions

5. limit

Defines rate limiting settings to prevent abuse:

• capacity: Number of allowed executions

• duration_in_minutes: Time window in minutes

• ip_based: Whether the limit is IP-based

6. validate

Analyzes the response returned by the server:

• response_code_equals: Exact response code match (e.g., 200, 403)

• response_code_between: Valid range of status codes

• response_payload_contains: At least one of the given strings must exist

• response_payload_contains_all: All specified strings must exist

• response_payload_matches: Match response using regex

• response_payload_not_contains: Must not contain certain strings

7. owasp

Specifies the corresponding OWASP API Security Top 10 (2023) category. This links the rule to international security standards and clarifies the type of API vulnerability being detected.

OWASP Code	Vulnerability Type	Description
API1:2023	Broken Object Level Authorization	Accessing other objects without proper permissions (e.g., IDOR)
API2:2023	Broken Authentication	Flaws in authentication mechanisms (e.g., token issues)
API3:2023	Broken Object Property Level Authorization	Changing fields without proper access control
API4:2023	Unrestricted Resource Consumption	Lack of rate limiting or quotas
API5:2023	Broken Function Level Authorization	Missing role-based access control
API6:2023	Unrestricted Access to Sensitive Business Flows	Unauthorized access to business-critical flows
API7:2023	Server Side Request Forgery (SSRF)	Server misuse for sending external requests
API8:2023	Security Misconfiguration	Issues like debug mode, default passwords, exposed configs
API9:2023	Improper Inventory Management	Poor tracking of API versions and endpoints
API10:2023	Unsafe Consumption of APIs	Blindly trusting external APIs without validation

Why It Matters

Linking rules to OWASP categories:

• Clarifies the intent and scope of the rule

• Strengthens alignment with industry standards

• Supports organizational security compliance efforts

Example Rule

Below is an example of internal system information leakage in error messages of Java-based applications.

YAML

id: DESCRIPTIVE_ERROR_MESSAGE_JAVA_SERVER
info:
  name: Descriptive Error Message Using Java server
  description: "Verifies error messages for sensitive information leakage, specifically preventing the exposure of Java stack traces, enhancing application security."
  details: >
    "This test ensures that Java-based applications do not leak sensitive error messages such as stack traces.
    Such messages may contain class names, line numbers, and internal logic that can help attackers craft more targeted attacks.
    Proper error handling should ensure that the end user receives only a generic error message, while technical details are logged internally."
  impact: "Verbose Java error messages may reveal class names, file paths, or internal server logic, enabling attackers to identify weaknesses and plan targeted exploits."
  solution: >
    "Configure the application to handle exceptions gracefully. Avoid displaying raw stack traces or Java exception messages in API responses.
    Instead, log these details securely on the server side and return a generic error message to clients."
  category:
    name: VEM
    short_name: VEM
    display_name: Verbose Error Messages (VEM)
  sub_category: DESCRIPTIVE_ERROR_MESSAGE_JAVA_SERVER
  severity: LOW
  tags:
    - Business logic
    - OWASP top 10
    - HackerOne top 10
  references:
    - "https://owasp.org/www-community/Improper_Error_Handling"
  cwe:
    - CWE-209
    - CWE-200
  cve:
    - CVE-2020-11883
    - CVE-2020-15652

owasp: API8:2023 Security Misconfiguration

validate:
  response_code_between: [400, 599]
  response_payload_contains:
    - "[java.lang."
    - "class java.lang."
    - "java.lang.NullPointerException"
    - "java.rmi.ServerException"
    - "at java.lang."
    - "at org.apache"
    - "org.springframework."
    - "org.hibernate."
    - "javax.servlet.ServletException"
    - "org.apache.catalina."
    - "org.apache.jasper."
    - "org.apache.struts."
    - "org.jboss."
    - "org.glassfish."
    - "java.sql.SQLException"
    - "java.io.IOException"
    - "org.springframework.web.util.NestedServletException"
    - "java.lang.reflect.InvocationTargetException"

Best Practices

• Test your payloads using their URL-encoded equivalents.

• Keep regex patterns specific and narrow to reduce false positives.

• Add only reliable and consistent markers in the validate section.

• Use OWASP and CWE references to document and categorize your rules effectively.

How Can Customers Write Their Own Rules?

Customers can define their own rules through the following steps:

1. Use the “Add New Rule” option from the APIFort interface to create a new blank rule.
2. Clone an existing rule and customize it as needed for their environment.
3. Reuse the payload and regex samples provided in this documentation.
4. Deploy the rule in a test environment first and verify against false positives.