Method and apparatus for predicting parameter behavior risk of api document semantic awareness type

Abstract

The application relates to an API document semantic perception type parameter behavior risk prediction method and device, and belongs to the field of data security detection.The method comprises the following steps: setting an API document by adopting a routing configuration file framework; obtaining a target API document through an integration tool; parsing semantic information and constructing a baseline model; collecting behavior field parameter information in real time, constructing a dynamic model, and calculating constraint deviation; performing field-level risk scoring; according to the scoring result, outputting a risk report and updating the baseline model.The device comprises the following modules: an API document generation module; a target API document acquisition module; a baseline model creation module; a comparison and analysis module; a field-level scoring module; and a baseline updating module.The API document field constraint is converted into a runtime baseline which can be updated with versions, the behavior of each call is measured and abnormity is early warned field by field, explainable risk disposal suggestions are given, and a closed loop of 'document-detection-response' is realized.

Description

Technical Field

[0001] This invention belongs to the field of data security technology and relates to a method, apparatus, computer equipment, computer storage medium and computer program product for predicting API document semantic awareness parameter behavior risks. Background Technology

[0002] API semantic structures (OpenAPI, Swagger, AsyncAPI, etc.) were initially just "interface specifications" used to automatically generate documentation, mock services, or client SDKs. However, with the rise of cloud-native and microservice architectures, they have evolved into "digital contracts" that permeate design, testing, gateways, and operations. Based on this "digital contract" filled with rules for field values, lengths, and frequencies, research naturally focuses on whether each request follows these rules—this measurement of runtime parameter out-of-bounds behavior is known as "parameter behavior risk"; any deviation can be amplified into SQL injection, privilege escalation, or DoS attacks. Thus, API documentation has been given a new role: real-time baseline comparison, field-level alerts, and "living specifications" that evolve with version updates, transforming API documentation from simply "readable" to "comparable, perceptible, and self-healing."

[0003] Currently, several security detection technologies exist, including: a method and apparatus for constructing a 0DAY vulnerability detection model based on an AI large-scale model (CN202510453571.9). This method uses AST replacement + GAN adversarial examples to expand the training set, trains a Transformer-CNN combined model hierarchically, and detects 0DAY vulnerabilities at the source code level. However, it requires access to the source code and focuses on "code vulnerabilities" rather than "runtime parameters." The generated samples still rely on feature matching, are ineffective for unknown parameter anomalies, and are black-box unexplained. Another method for detecting software source code security vulnerabilities based on an artificial intelligence large-scale model (CN202510670435.5) uses abstract syntax trees / control flow graphs for static rule screening, and then uses fuzz testing + AI large-scale models for dynamic verification, forming a source code-level static-dynamic-AI closed loop. However, it can only discover potential vulnerabilities at the code level, cannot detect runtime parameter behavior anomalies, and is ineffective for third-party APIs without source code. The AI-based dynamic security risk assessment and intelligent response system and method (CN202510779614.2) deploys multi-dimensional sensors (network, terminal, physical) to collect traffic and behavior data, uses deep neural networks to generate threat intelligence and respond automatically. However, its data granularity is limited to macro-level indicators such as "traffic / device / user," without incorporating API documentation field constraints; the output is a system-level score, failing to pinpoint specific parameters. In summary, existing technologies generally focus on detecting static objects such as "source code vulnerabilities" or "macro-level traffic threats," resulting in detection baselines lagging behind API documentation version iterations, detection granularity remaining at the interface / parameter level, and a fragmented detection-response chain without closure. Furthermore, dynamic methods that use API documentation field constraints as a real-time baseline and perform runtime parameter field-level anomaly detection and interpretable risk prediction are almost nonexistent.

[0004] Therefore, how to build a dynamic baseline closed-loop adjustment mechanism that supports fine-grained field-level measurement, interpretable risk prediction, and adaptive with document version iteration by integrating the behavioral parameter characteristics of API documents is a core technical challenge that urgently needs to be overcome in the field of API security and compliance testing. Summary of the Invention

[0005] In order to solve the technical problems in the background art, the present invention provides a method, apparatus, computer device, computer storage medium and computer program product for predicting API document semantic-aware parameter behavior risks.

[0006] The technical solution of the present invention to solve the above-mentioned technical problems is as follows:

[0007] The first aspect provides a method for predicting API document semantically aware parameter behavior risks, the method comprising the following steps:

[0008] The API documentation is set up using a route configuration file framework. The framework consists of the following elements from the outside in: module name with version number, class name, route name, request method and its corresponding controller method name, and comments describing the functionality. The framework automatically generates URLs using the " / module / class / route" template and generates API description files simultaneously.

[0009] The target API documentation is obtained through the API integration tool. The API integration tool is configured to automatically start the version evolution analyzer when a major version change of the core business API is detected, analyze the semantic impact of the field type change, and trigger the manual review process.

[0010] Parse semantic information in the target API documentation and build a field-level behavior baseline model;

[0011] Real-time collection of behavioral field parameter information, construction of field-level behavioral dynamic model, comparison with baseline model, and calculation of real-time constraint deviation D_{ij};

[0012] The field-level risk scoring formula R_i is used to calculate whether the behavioral parameters deviate from the API document constraints. If they deviate, the abnormal behavior is identified and marked; if they do not deviate, no action is taken. The field-level risk scoring formula R_i is: R_i = [Σ(w_j × D_{ij})] × C_version, where R_i is the risk score of the i-th field; w_j is the weight of the j-th constraint type; D_{ij} is the deviation degree of the i-th field from violating the j-th constraint; and C_version is the version confidence adjustment factor.

[0013] Based on the risk scoring results, output a field-level interpretable risk report and update the baseline model.

[0014] Secondly, an API document semantic-aware parameter behavior risk prediction device is provided, the device comprising:

[0015] The API documentation generation module is used to set up API documentation using a route configuration file framework. This framework, from the outside in, consists of: module name with version number, class name, route name, request method and its corresponding method name, and comments describing the functionality. This framework automatically generates URLs according to the " / module / class / route" template and generates API description files simultaneously.

[0016] The "Get Target API Documentation" module is used to obtain the target API documentation through the API integration tool. The API integration tool is configured to automatically start the version evolution analyzer when a major version change of the core business API is detected, analyze the semantic impact of field type changes, and trigger a manual review process.

[0017] Create a baseline model module to parse semantic information in the target API document and build a field-level behavior baseline model;

[0018] The comparative analysis module is used to collect behavioral field parameter information in real time, build a field-level behavioral dynamic model, compare it with the baseline model, and calculate the real-time constraint deviation D_{ij}.

[0019] The field-level scoring module is used to calculate whether behavioral parameters deviate from API document constraints using the field-level risk scoring formula R_i. If a deviation is found, abnormal behavior is identified and marked; otherwise, no action is taken. The field-level risk scoring formula R_i is: R_i = [Σ(w_j × D_{ij})] × C_version, where R_i is the risk score of the i-th field; w_j is the weight of the j-th constraint type; D_{ij} is the deviation degree of the i-th field from violating the j-th constraint; and C_version is the version confidence adjustment factor.

[0020] The baseline update module is used to output a field-level interpretable risk report based on the risk scoring results and update the baseline model.

[0021] Thirdly, a computer device is provided, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, it implements the steps of the API document semantic-aware parameter behavior risk prediction method as described in any of the preceding claims.

[0022] Fourthly, a computer-readable storage medium is provided on which a computer program is stored, which, when executed by a processor, implements the API document semantic-aware parameter behavior risk prediction method described above.

[0023] Fifthly, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the API document semantic-aware parameter behavior risk prediction method described in any of the preceding claims.

[0024] The beneficial effects of this invention are:

[0025] (1) This invention, through the setting of the routing configuration file framework, can automatically identify the version directory of the framework and dynamically convert the route name into a URL path that conforms to the standard. This not only ensures the consistency between the document and the code and quickly parses semantic information, but also has version awareness capabilities, laying the foundation for generating interpretable models and risk reports.

[0026] (2) This invention fully considers the significant impact of API document version changes. By introducing a field-level risk score based on version factors, it can significantly enhance the robustness of the model to scenarios where multiple versions coexist, while making the field-level score more semantically coherent.

[0027] (3) This invention directly transforms document field constraints into runtime baselines that can be updated with each version, performs field-by-field measurement and anomaly warning for parameter values, lengths, types, and frequencies of each call, and provides explainable and implementable risk handling suggestions to achieve a closed loop of “document-detection-response”. Attached Figure Description

[0028] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0029] Figure 1 This is a schematic diagram of the API document semantic awareness parameter behavior risk prediction method provided in Embodiment 1 of the present invention.

[0030] Figure 2 This is a schematic diagram of the configuration file framework in Embodiment 1 of the present invention.

[0031] Figure 3 This is a schematic diagram of the interface for API tool integration in Embodiment 1 of the present invention.

[0032] Figure 4 This is a schematic diagram of the API document semantic parsing process in Embodiment 1 of the present invention.

[0033] Figure 5 This is a schematic diagram of the API document semantic awareness parameter behavior risk prediction method provided in Embodiment 2 of the present invention.

[0034] Figure 6 This is a schematic diagram of the API document semantic awareness parameter behavior risk prediction device provided in Embodiment 3 of the present invention.

[0035] Figure 7 This is a comparison chart of the risk detection performance of different models provided in Embodiment 3 of the present invention under API version evolution.

[0036] Figure 8 This is a schematic diagram of the structure of the electronic device provided in Embodiment 4 of the present invention.

[0037] The attached diagram lists the components represented by each number as follows:

[0038] 4001. API Documentation Generation Module; 4002. Target API Documentation Acquisition Module; 4003. Baseline Model Creation Module; 4004. Comparative Analysis Module; 4005. Field-Level Scoring Module; 4006. Baseline Update Module; 510. Processor; 520. Communication Interface; 530. Memory; 540. Communication Bus. Detailed Implementation

[0039] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0040] Example 1

[0041] Currently, existing security detection technologies generally focus on detecting static objects such as "source code vulnerabilities" or "macro traffic threats," resulting in the detection baseline lagging behind API document version iterations, detection granularity remaining at the interface level / parameter overall level, and the detection-response link being fragmented and lacking a closed loop. Furthermore, there is a near absence of dynamic prediction methods that use API document field constraints as the real-time baseline and perform runtime parameter field-level anomaly detection and interpretable risk prediction.

[0042] Therefore, how to build a dynamic baseline closed-loop adjustment mechanism that supports fine-grained field-level measurement, interpretable risk prediction, and adaptive with document version iteration by integrating the behavioral parameter characteristics of API documents is a core technical challenge that urgently needs to be overcome in the field of API security and compliance testing.

[0043] To address the aforementioned issues, this invention provides a method for predicting API document semantically aware parameter behavior risks. Figure 1 This is a schematic diagram of the API document semantic-aware parameter behavior risk prediction method provided in an embodiment of the present invention, such as... Figure 1 As shown, this method includes:

[0044] Step S101: Configure the API documentation using a route configuration file framework. The framework consists of the following elements from the outside in: module name with version number, class name, route name, request method and its corresponding controller method name, and comment function description. The framework automatically generates URLs according to the " / module / class / route" template and generates API description files simultaneously.

[0045] Understandably, module names with version numbers distinguish different versions of the module, such as v1 / user, where v1 represents the version number and user represents the module name; class names are the names of classes associated with the module, used to organize and manage the functionality within the module, such as Role; route names are identifiers for specific API requests, used to distinguish different API endpoints, such as roles; request methods and their corresponding controller method names are HTTP request methods and their corresponding processing methods in the controller, such as get corresponding to getRoleList, post corresponding to addRole, etc.; comment descriptions are brief comments on the functionality of controller methods, used to explain the function of the method, such as / / get user role list.

[0046] Preferably, step S101 further includes:

[0047] Step S1011: Traverse all route configuration files in the target directory and extract all route rules;

[0048] Step S1012: Based on the configuration file framework of " / module / class / route", generate a URL with version number, request method, controller class name and method name for each route rule in real time, and output the API description file synchronously.

[0049] Step S1013: Extract the annotation function description of the controller method using PHP reflection;

[0050] Step S1014: After serializing the URL, request method, API required parameters and functional description in the controller method comments according to the standard interface description format, publish a readable and testable API document with one click based on the route configuration file framework; wherein, the configuration file framework consists of the following from the outside to the inside: module name with version number, class name, route name, request method and its corresponding controller method name, and comment functional description.

[0051] Understandably, the standard interface description format can be the OpenAPI specification, the RAML specification, or the gRPC specification, depending on the usage scenario and requirements. For example, if the scenario requirements are relatively general, OpenAPI might be used, as it is the most universal and widely used standard, applicable to various languages ​​and frameworks, and capable of generating rich documentation. Conversely, if the scenario requires a clear expression of the API's structure and behavior, providing a hierarchical and semantic description of API resources and operations, RAML might be used, offering powerful features and extensibility. Furthermore, the output API documentation can be in JSON or YAML format. This embodiment does not impose specific limitations on these formats.

[0052] It's also understandable that PHP's reflection mechanism is a powerful tool that allows programs to inspect detailed information about classes, interfaces, methods, properties, etc., at runtime. In the process described above, by utilizing PHP's reflection mechanisms, such as `ReflectionClass` and `ReflectionMethod`, detailed information about controller classes and methods, including parameter comments, can be dynamically obtained, thereby enabling automated documentation generation.

[0053] In API documentation generation scenarios, PHP reflection can be used to automatically extract information such as controller method comments and parameter types. This reduces the workload of manually writing documentation and ensures consistency between documentation and code. However, PHP reflection is not the only option; other methods can be used to achieve similar functionality, such as:

[0054] Static analysis tools: Some static analysis tools can analyze source code and extract relevant information without running the code;

[0055] Annotation parsing libraries: If you use annotations to mark information in your code, you can use a dedicated annotation parsing library to read these annotations and generate documentation.

[0056] Therefore, the choice of which method to use to extract annotation function descriptions depends on the specific project requirements, technology stack, and the development team's preferences. This embodiment does not impose any specific limitations on this.

[0057] It's worth noting that the routing configuration file framework, from the outside in, consists of: module name with version number, class name, route name, request method and its corresponding controller method name, and comments describing the functionality. This structured configuration allows the system to easily identify different versions of modules, thus enabling it to be highly aware of version changes. When generating API documentation, the system can quickly construct URL paths that conform to standard specifications based on this framework, ensuring the accuracy and timeliness of the API documentation. Simultaneously, this precise management of versions and routes provides a solid foundation for subsequently generating highly interpretable models and risk reports, enabling developers to more deeply understand and analyze the API's behavior and potential risks.

[0058] To facilitate understanding the structure of the configuration file framework, such as Figure 2 As shown, we provide a specific example using PHP arrays, as follows:

[0059] Beginning with return;

[0060] Next is a single-line comment: / / User Roles Module;

[0061] Define an array element with the key 'user_v1', and add a single-line comment: / / The module has a version name, and its value is an array.

[0062] This array contains array elements with the key 'Role', and the single-line comment / / class name has an array value.

[0063] This array contains array elements with the key 'roles', a single-line comment / / route name, whose value is an array;

[0064] Within this array, there is a single-line comment: / / Request method => Method name;

[0065] Then there are four key-value pairs:

[0066] 'get'=>'getRoleList', followed by a single-line comment / / Get the list of user roles;

[0067] 'post'=>'addRole', followed by a single-line comment / / Add a new user role;

[0068] 'put'=>'editRole', followed by a single-line comment / / Edit user role;

[0069] 'delete'=>'delRole', followed by a single-line comment / / Delete user role;

[0070] Ending with ] indicates the end of the array hierarchy.

[0071] Step S102: Obtain the target API documentation through the API integration tool. The API integration tool is configured to automatically start the version evolution analyzer when a major version change of the core business API is detected, analyze the semantic impact of the field type change, and trigger the manual review process.

[0072] It is understandable that API integration tools are not single software, but rather a toolchain covering the entire process of "design → development → testing → documentation → release → monitoring → governance". The choice of tools depends on the scenario. For example, for low-cost and rapid verification, a lightweight all-in-one tool can be selected; for API design, Swagger Editor can be selected, which is open source and allows for online interface definition; and for documentation tools, Swagger UI can be selected to automatically generate visual documentation. However, these choices are well known to those skilled in the art, and this embodiment does not impose specific limitations.

[0073] It is worth noting that since version information is used throughout this embodiment, the version evolution analyzer is very important. First, it carries out multi-dimensional semantic change analysis. When a major version change of a business interface is detected, such as / api / v2 / resource, it automatically collects the differences between the old and new documents, expanding the analysis dimensions to: field type changes, constraint rule adjustments, and reconstruction of inter-field dependencies. Second, it provides impact assessment and transformation guidance, and can generate an "Interface Version Change Impact Report", which includes: client compatibility risk level (high / medium / low), a list of related interfaces that need to be transformed, and the location of the affected code modules.

[0074] However, in API integration tools, the version evolution analyzer is generally an engine within the "API document governance module" that specifically handles "document version difference analysis, risk assessment, and process triggering." It serves as the technical carrier for the "detection stage" in the "document-detection-response" closed loop. Therefore, it can exist as an independent microservice or a plug-in module, deployed in the API tool's "document processing cluster," interacting with the "document storage layer" and "response execution layer" via API or message queues. However, in monolithic API tools, it can also be more deeply embedded into the logic layer of the "document generation service." This embodiment does not specifically limit this.

[0075] It is also worth noting that when the version evolution analyzer detects high-impact changes, such as disruptive adjustments to field types, conflicts in core business rules, or broken dependency chains of multiple interfaces, this embodiment automatically triggers a manual review process, which can achieve business semantic risk coverage and a risk mitigation mechanism.

[0076] Step S103: Parse the semantic information in the target API document and construct a field-level behavior baseline model.

[0077] It is understandable that the semantic information in the API documentation is a key convention for the proper functioning of the interface, and the specific content includes, but is not limited to:

[0078] Field type: Clearly specify the allowed data types for the field, such as string, integer, floating-point number, boolean value, etc., to ensure that the data format is correct;

[0079] Length Limits: Set the maximum and minimum length of string or array fields to prevent errors caused by data that is too long or too short;

[0080] Enumerated values: Specify a fixed set of allowed values ​​for a field, such as the status field which may only allow active or inactive values;

[0081] Required / Optional: Indicates whether the field must be provided in the request, helping developers understand the usage requirements of the interface;

[0082] Default value: Specify the default value for a field when it is not provided in the request to ensure that the interface can process the request normally;

[0083] Regular expression constraints: Use regular expressions to define the format of a field, such as the email field must conform to the format specifications of an email address.

[0084] Another way to understand this is that, since the field-level behavior baseline model is built upon the semantic information in the API documentation, it serves not only as prior knowledge but also to describe the normal behavior pattern of each field. Specifically, based on semantic information, normal behavior patterns can be defined for each field; for example, the normal behavior of the `age` field is to receive an integer between 1 and 120. At runtime, the actual input parameter value can be directly compared. If a negative number is input to the `age` field, exceeding the range defined by the baseline model, it is considered abnormal behavior. Furthermore, very subtle anomalies can be captured, such as an `unknown` value not defined in the enumeration values ​​being input to the `status` field, or the format of the `email` field not conforming to regular expression constraints. In short, by constructing a field-level behavior baseline model, the semantic information in the API documentation can be transformed into executable rules, thereby enabling fine-grained detection and control of parameters at runtime.

[0085] To facilitate the semantic parsing process of API documentation, such as Figure 3 As shown, specifically: the API document first completes semantic parsing and structural processing through the parser, then the constraint extractor identifies and extracts various constraints related to the fields from the parsing results, such as data type, value range, and other rules. The model builder then builds a baseline model that reflects the behavioral characteristics of the fields based on these constraints, and finally forms a field-level behavioral baseline model for field compliance detection scenarios.

[0086] Step S104: Collect behavioral field parameter information in real time, construct a field-level behavioral dynamic model, compare it with the baseline model, and calculate the real-time constraint deviation D_{ij}. The constraint deviation is specifically calculated using the length deviation D_{length}.

[0087] In step S104, the specific formula for D_{length} is:

[0088] D_{length}=max(0,L_{actual}-L_{expected}) / (L_{max}-L_{expected})×W_field, where max(0,L_{actual}-L_{expected}) is the difference between the actual length and the expected length; L_{max}-L_{expected} is the difference between the maximum length defined in the document and the expected length, which serves as the maximum tolerance range; W_field is the field semantic weight factor, a coefficient greater than or equal to 1, which is dynamically adjusted according to the business semantics of the field.

[0089] Understandably, real-time collection of behavioral characteristics from API calls is crucial for understanding API usage patterns and detecting abnormal behavior. Specific behavioral characteristics include:

[0090] Field values ​​and lengths: The actual value and length of each field are obtained in real time and compared with the length limit in the API documentation to detect whether there are any cases of being too long or too short;

[0091] Call frequency: Statistically analyze the call frequency of specific API endpoints or parameters to identify potential high-frequency calls or DoS attacks;

[0092] Call order: Record the order of API calls and analyze whether there are any call orders that do not conform to business logic, such as the failure to perform necessary initialization calls before a certain operation;

[0093] Parameter Combination: Detects whether the combination of multiple parameters conforms to the expected pattern, identifies uncommon or potentially dangerous parameter combinations, which helps to discover possible attack intentions.

[0094] It's worth noting that the calculation of the constraint deviation D_{ij} should not be rigid, but rather closely related to the specific needs and real-time changes of the business. By introducing business semantics, the importance and sensitivity of different fields in the business can be reflected more accurately. Specifically:

[0095] Critical business fields, such as amount and user_id, are typically essential for the normal operation and security of the business. Even slight deviations can have a significant impact on the business. Therefore, these fields can be assigned higher weights, such as W_field being 2.0 or higher, to ensure strict monitoring and handling.

[0096] Common descriptive fields, such as description and remark, have a relatively small impact on business operations and can be assigned a lower weight, such as W_field being set to 1.0 or lower, to reflect their lower business sensitivity.

[0097] This method of dynamically adjusting weights ensures that risk assessments are more aligned with actual business needs, improving the accuracy and effectiveness of risk identification.

[0098] It is also worth noting that the constraint deviation can be a combination of multiple factors. In addition to the length deviation D_{length} mentioned above, type deviation D_type and enumeration deviation D_enum can also be used. Type deviation D_type checks whether the data type of the field value is consistent with the type defined in the document. If the field value's type is consistent with the document's defined type, then D_type = 0; if the field value's type is inconsistent with the document's defined type, then D_type = 1. Enumeration deviation D_enum checks whether the field value is within the numerical range defined in the document. If the field value is within the defined range, then D_range = 0; if the field value exceeds the defined range, then D_range = 1. Therefore, those skilled in the art can use one or more constraint deviations to assist in the calculation according to business needs, and this embodiment does not specifically limit this.

[0099] Preferably, in step 104, the behavior field parameter information is collected through traffic mirroring or log collection.

[0100] Traffic mirroring and log collection are two non-intrusive data acquisition methods that can effectively capture the actual parameter values ​​in API calls without affecting the operation of existing systems. Specifically:

[0101] Traffic mirroring refers to copying traffic from network devices to monitoring devices or systems to achieve real-time monitoring of API requests. This allows for the complete copying and analysis of data packets in the network without interfering with normal business traffic, and the extraction of the actual parameter values ​​in API calls.

[0102] Log collection involves extracting parameter information from log files generated by API gateways, servers, or applications. Logs typically record detailed information about each API call, including the request method, path, query parameters, and request body content. By parsing these logs, the actual parameter values ​​used in the call can be obtained without modifying the application code.

[0103] Step S105: Calculate whether the behavioral parameters deviate from the API document constraints using the field-level risk scoring formula R_i. If they deviate, identify and mark the abnormal behavior; if they do not deviate, do not take any action.

[0104] In step S105, the specific formula for the field-level risk score R_i is:

[0105] R_i = [Σ(w_j×D_{ij})]× C_version, where R_i is the risk score of the i-th field; w_j is the weight of the j-th constraint type; D_{ij} is the deviation of the i-th field from violating the j-th constraint; and C_version is the version confidence adjustment factor.

[0106] It's worth noting that APIs typically undergo multiple iterations and updates, with different versions potentially having different constraints and requirements. This embodiment introduces a version confidence adjustment factor, C_version, into the field-level risk scoring formula. This dynamically adjusts field weights, enabling the model to quickly adapt to API document version changes, reducing false positives and false negatives. The impact of version changes is reflected in the risk report, enhancing the transparency of results. A smooth transition occurs when old and new versions are used together, avoiding model fluctuations. Furthermore, the model is dynamically updated based on version release duration or traffic share, ensuring that it reflects the actual risk distribution in real time. Therefore, this embodiment not only significantly improves the model's robustness in scenarios with multiple versions coexisting but also makes field-level scoring more semantically coherent.

[0107] Step S106: Based on the risk scoring results, output a field-level interpretable risk report and update the baseline model.

[0108] Understandably, a field-level explainable risk report is a targeted and detailed risk assessment report. It performs separate risk assessment and explanation for each field, and its core characteristics should lie in its granularity and explainability. Specifically:

[0109] Granularity: The report focuses on each field, rather than the entire API request or response, which means that the risk of each field is assessed and quantified separately;

[0110] Explainability: The report not only provides a risk score, but also explains in detail the source of risk for each field. For example, it will indicate whether a field's value is outside the allowed range, whether the type is mismatched, or whether an unexpected value has appeared.

[0111] In addition, for ease of understanding, we provide a field-level interpretable risk report structure, which may include the following:

[0112] Field name: Identifies the specific field, such as amount or user_id;

[0113] Risk score: A quantitative value, a score between 0 and 1, indicating the level of risk for that field;

[0114] Deviation Description: Describe in detail how the field value deviates from the constraints defined in the API documentation, such as whether the value exceeds the length limit, whether the type does not match, or whether it violates the definition of the enumeration value;

[0115] Constraint violation type: Specifies the specific type of violation, such as length exceeding the limit, type mismatch, illegal enumeration value, etc.

[0116] Risk type: The classification of risks, such as SQL injection, type out of bounds, illegal parameters, etc.;

[0117] Recommendations: Provide specific solutions or mitigation measures for the identified risks;

[0118] Specific example: Field name user_id, risk score 0.7, deviation reason is that the type should be an integer, but it is actually a string, violating type mismatch, the risk type is an illegal parameter, the handling suggestion is to ensure that the input value is an integer;

[0119] Field-level interpretable risk reports allow for quick identification of specific problem fields, rather than searching for the root cause in large amounts of data. This provides better operability and transparency, while also effectively improving the efficiency and accuracy of model updates.

[0120] To facilitate understanding of the overall operating architecture of this embodiment, as follows: Figure 4 As shown, specifically:

[0121] In the overall operational architecture, the API documentation adopts a routing configuration file framework, and a baseline model is generated after parsing the API documentation; behavioral field parameter information is collected in real time and input into the dynamic model; the dynamic model and the baseline model are jointly subjected to comparative analysis, and behavioral anomalies are identified by combining risk scores; the comparative analysis outputs a risk report, which is used to update the baseline model.

[0122] In this embodiment, document field constraints are directly transformed into a runtime baseline that can be updated automatically with each version. The parameter values, lengths, types, and frequencies of each call are measured and anomaly warnings are issued for each field. Explainable and actionable risk management suggestions are provided to achieve a closed loop of "document-detection-response".

[0123] Example 2

[0124] like Figure 5 As shown in one embodiment, an API document semantic-aware parameter behavior risk prediction method is provided. This method includes:

[0125] Step S201: Configure the API documentation using a route configuration file framework. The framework consists of the following elements from the outside in: module name with version number, class name, route name, request method and its corresponding controller method name, and comment function description. The framework automatically generates URLs according to the " / module / class / route" template and generates API description files simultaneously.

[0126] Step S202: Obtain the target API documentation using the API integration tool. The API integration tool is configured as follows:

[0127] When a major version change of a core business API is detected, the version evolution analyzer is automatically started to analyze the semantic impact of the field type change and trigger the manual review process.

[0128] For core operation identifiers, core dedicated fields are automatically extracted and assigned preset semantic weights.

[0129] Understandably, the identifier corresponds to the route context adjustment factor C_route; the dedicated field corresponds to the field weight W_field. For example, when the URL path matches the disaster recovery operation identifier / api / v1 / recovery or / backup, the system triggers two adjustments simultaneously:

[0130] Routing layer: C_route has been upgraded from the default 0.6 to 1.8;

[0131] Field layer: The W_field for disaster recovery fields such as restore_point and backup_target_region has been upgraded to version 2.0;

[0132] Both are then incorporated into the same field-level risk scoring formula, achieving a two-dimensional amplification through "context + field semantics".

[0133] Step S203: Parse the semantic information in the target API document and construct a field-level behavior baseline model.

[0134] Step S204: Collect behavioral field parameter information in real time, construct a field-level behavioral dynamic model, compare it with the baseline model, and calculate the real-time constraint deviation D_{ij}. The constraint deviation is specifically calculated using the length deviation D_{length}.

[0135] In step S204, the specific formula for D_{length} is:

[0136] D_{length}=max(0,L_{actual}-L_{expected}) / (L_{max}-L_{expected})×W_field, where max(0,L_{actual}-L_{expected}) is the difference between the actual length and the expected length; L_{max}-L_{expected} is the difference between the maximum length defined in the document and the expected length, which serves as the maximum tolerance range; W_field is the field semantic weight factor, a coefficient greater than or equal to 1, which is dynamically adjusted according to the business semantics of the field.

[0137] Step S205: Calculate whether the behavioral parameters deviate from the API document constraints using the field-level risk scoring formula R_i. If they deviate, identify and mark the abnormal behavior; if they do not deviate, do not take any action.

[0138] In step S205, the specific formula for the field-level risk score R_i is:

[0139] The formula for R_i is: R_i=[Σ(w_j×D_{ij})]×C_version×C_route, where R_i is the risk score of the i-th field; w_j is the weight of the j-th constraint type; D_{ij} is the deviation of the i-th field from violating the j-th constraint; C_version is the version confidence adjustment factor; and C_route is the routing context adjustment factor, with the value of C_route being a preset semantic weight value when the URL contains a core operation identifier.

[0140] It's worth noting that C_route quantifies the global context of "whether the current interface is a core disaster recovery point" into coefficients that can be substituted into formulas; W_field quantifies the local semantics of "whether a field is critical for disaster recovery" into coefficients. When these two work together: deviations of the same degree (such as enumeration out-of-bounds) will have their risk score amplified twice in disaster recovery interfaces, immediately triggering high-risk alerts; while in ordinary interfaces, the amplification is limited, maintaining normal tolerance. Thus, the system doesn't need to rewrite rules; it completes context-sensitive scoring for "same deviation, different scenarios, different risk levels" using only two configurable coefficients.

[0141] Step S206: Perform combined suspicion normalization. Calculate whether the field behavior parameters deviate from the API documentation constraints using the parameter combination risk scoring formula R_combo. If a hard rule is violated, it is judged as a hard deviation and directly scored as 1. If no hard rule is violated, a machine learning model is used to output the deviation score.

[0142] In step S206, the specific formula for the parameter combination risk score R_combo is as follows:

[0143] R_combo=\begin{cases}1.0,&\text{if}R_{rule}=1.0\\R_{ml},&\text{if}R_{rule}=0.0\end{cases}, where:

[0144] R_combo is the risk score for the parameter combination, with a value range of [0,1], where 1 indicates that there is a high-risk combination and 0 indicates that it is safe.

[0145] P_1, P_2, ..., P_n are n parameters that appear together as input parameters in a single API request;

[0146] R_{rule} represents the rule base matching. Specifically, R_{rule}=\begin{cases}1.0,& \text{if}(P_i,P_j,...,P_k)\in\text{Known\_Dangerous\_Pairs} \\0.0,&\text{otherwise}\end{cases}. Known\_Dangerous\_Pairs is a configurable, predefined rule base for dangerous parameter combinations. This rule base is stored in persistent storage and supports dynamic loading and hot updates. Rule entries are defined in the form of structured data. (P_i,P_j,...,P_k) represents a specific set of k parameters extracted from n parameters, where k≤n.

[0147] R_{ml} represents machine learning pattern recognition, where R_{ml} = \text{Model}(P_1, P_2, ..., P_n), Model is a pre-trained machine learning classification model, and (P_1, P_2, ..., P_n) are the feature vectors of the parameter combinations of the current request.

[0148] As mentioned above, Known_Dangerous_Pairs is a configurable, predefined rule base for combining dangerous parameters. Specific rule entries can be defined using structured data, for example:

[0149] (action=delete,force=true): Force deletion operation, high risk, hard deviation, directly set R_rule=1.0;

[0150] (file_path=.. / .. / .. / ,operation=read): Path traversal attack, high risk, hard deviation, directly set R_rule=1.0;

[0151] Therefore, if the current request's parameter combination matches any rule in the knowledge base, then R_rule=1.0.

[0152] It's also understandable that R_{ml} is a soft score based on a machine learning model:

[0153] Model: A pre-trained machine learning classification model, such as a random forest, gradient boosting tree, or neural network;

[0154] Model input: Feature vector of the parameter combination (P_1, P_2, ..., P_n) of the current request, such as parameter name, parameter value, data type, parameter order, statistical characteristics of parameter values, etc.;

[0155] Model output: A risk probability value between 0.5 and 1.0, representing the likelihood of this parameter combination resulting in abnormal behavior;

[0156] Training data: Historical API call logs (containing a large number of normal requests) and known attack samples (such as attack traffic generated by OWASP ZAP and Burp Suite scans) are used for training.

[0157] Parameter combination risk scoring is a quantitative indicator of risk for "interrelationship logic between multiple fields". It helps to solve the hidden risk of "individual fields being compliant, but the combination of fields violating business rules". For example, the API documentation stipulates that backup_target_region (enumeration value: us / eu) must be linked with storage_type (enumeration value: hot / cold) (e.g., us only supports hot storage). If at runtime backup_target_region=us (field-level score=10, compliant) and storage_type=cold (field-level score=10, compliant), but the combination violates the rules, parameter combination risk scoring is triggered.

[0158] Step S207: Collect and normalize the total interface risk using interface behavior parameters, and calculate the interface-level comprehensive risk R_total.

[0159] In step S207, the specific formula for the interface-level comprehensive risk R_total is as follows:

[0160] R_total = α × R_field + β × R_freq + γ × R_combo, where R_field is the weighted average risk score based on field business weights, calculated as R_field = (Σ(W_field × R_i)) / (ΣW_field); R_freq is the call frequency risk score, calculated as R_freq = min(1, (F_{actual} - F_{expected}) / F_{expected}); R_combo is the parameter combination risk score, calculated as R_combo = (1.0 if a known dangerous combination is detected, otherwise a value between 0.5 and 1.0 output by the machine learning model); α, β, and γ are three weight coefficients, satisfying α + β + γ = 1.

[0161] Understandably, W_field refers to the importance weight of a single field in the business, defined by business rules. For example, in a disaster recovery scenario, backup_target_region has a weight of Wi=2.0, while ordinary fields have a weight of Wi=1.0. R_i is the basic risk score of a single field, based on the deviation from "document constraint rules + runtime parameters".

[0162] It is also understandable that R_freq is the risk of the API call frequency deviating from the compliance threshold, F_{actual} is the frequency of non-actual calls, and F_{expected} is the expected compliance frequency. The difference between the two refers to the degree of deviation, covering scenarios such as "high-frequency malicious calls" and "low-frequency abnormal calls".

[0163] What's even more understandable is that R_combo quantifies the risk of multiple field combinations violating business rules. If it matches a known dangerous combination, it is directly assigned a value of 1.0; otherwise, the machine learning model outputs a probability value between 0.5 and 1.0 to resolve the hidden risk of "single field compliance but combination violation".

[0164] These three elements constitute a progressive risk governance chain: "single-field risk → multi-field combination risk → global call risk." The weighted average risk score R_field, based on the business weight of each field, accurately identifies anomalies in a single field. The frequency-level score R_freq aggregates field-level risks to the interface call dimension, determining whether "the interface as a whole is high-risk due to abnormal frequency + field risk." The combination risk score R_combo covers "combined violations" scenarios that cannot be identified by the field-level score. Finally, the comprehensive interface-level risk R_total = α × R_field + β × R_freq + γ × R_combo, where α, β, and γ are weighting coefficients determined by the business scenario; for example, γ is higher in disaster recovery scenarios.

[0165] Step S208: Collect and normalize the online confidence scores using model behavior parameters to calculate the model update confidence score C.

[0166] In step S208, the specific formula for updating the model confidence level C is as follows:

[0167] C = (|CommonFields| / |OldFields|) x (1 - ΔR_avg) x V_stability, where |CommonFields| / |OldFields| measures the retention rate of new and old documents at the field level; ΔR_avg is the average score difference between the new and old models on historical call data, calculated as ΔR_avg = |R_new_avg - R_old_avg|; and V_stability is the API version stability factor.

[0168] Understandably, |CommonFields| / |OldFields| measures the retention rate of new and old documents at the field level. The higher the retention rate, the higher the basic confidence level.

[0169] It is also understandable that ΔR_avg is the average difference in scores between the new and old models on historical call data. It is calculated as ΔR_avg=|R_new_avg-R_old_avg|. The smaller the difference, the more consistent the behavior of the new model is with the old model, and the higher the confidence level.

[0170] It is also understandable that V_stability is the API version stability factor. For major version number changes, such as from v1 to v2, V_stability takes a lower value; for minor version number changes, such as from v1.1 to v1.2, V_stability takes a higher value.

[0171] By comprehensively considering three dimensions—field retention rate, historical behavior consistency, and version change level—a relatively comprehensive model update confidence assessment system has been established. This ensures the reliability of model updates and avoids false alarms caused by document changes. For high-risk major version updates, the system will be more cautious, thereby guaranteeing system stability and security. Furthermore, if the model update confidence score C falls below a preset threshold, manual review should be triggered.

[0172] Step S209: Combine the results of the field-level risk score R_i, the parameter combination risk score R_combo, the interface-level comprehensive risk R_total, and the model update confidence C to output a field-level interpretable risk report and update the baseline model.

[0173] To better understand the entire risk scoring process, we will first provide a calculation example under a single version, using a disaster recovery scenario:

[0174] (1) Scenario: "Immediate Recovery" API in disaster recovery system

[0175] API path: / api / v1 / recovery

[0176] Request method: POST

[0177] Request parameters (JSON Body):

[0178] {

[0179] "strategy":"full_backup_2023",

[0180] "restore_disk":" / dev / sdb",

[0181] "restore_location":".. / .. / .. / etc / passwd",

[0182] "immediate_restore":true,

[0183] "script_content":"rm-rf / "

[0184] }

[0185] (2) Background: A user initiates a recovery task. However, the restore_location and script_content parameters exhibit obvious malicious behavior characteristics.

[0186] (3) Risk assessment process and formula calculation

[0187] According to the technical solution of the embodiment, the final risk score R_total of the request is calculated step by step.

[0188] Step 1: Semantic parsing of API documentation

[0189] Suppose the following field constraints are parsed from the API documentation, as shown in Table 1:

[0190] Table 1. API Documentation Field Definitions and Constraints

[0191] field name type Required Constraint / Enumeration Values strategy string yes ^backup_[a-z0-9_]+$ restore_disk string yes ^ / dev / [az]{3}$ restore_location string yes ^ / data / backups / .+$ immediate_restore boolean no Default is false script_content string no Length <= 500 characters, and must not contain dangerous commands such as rm, chmod, chown, etc.

[0192] Step 2: The system collects the above request parameters in real time and establishes a dynamic model.

[0193] Step 3: First calculate R_i for each field, then take a weighted average to get R_field.

[0194] (1) strategy field:

[0195] Actual value: "full_backup_2023"

[0196] Check: Matches the regular expression ^backup_[a-z0-9_]+$

[0197] R_strategy=0.

[0198] (2) The restore_disk field:

[0199] Actual value: " / dev / sdb"

[0200] Check: Conforms to the regular expression ^ / dev / [az]{3}$.

[0201] (3) R_restore_disk=0.

[0202] (4) The restore_location field:

[0203] Actual value: ".. / .. / .. / etc / passwd" (path traversal)

[0204] Check: Significant deviation from constraint ^ / data / backups / .+$

[0205] w_j: The weight of the "regularity constraint" is set to 1.0.

[0206] D_ij: Deviation degree; since there is no complete mismatch, D_ij = 1.0

[0207] C_route: The current route is / api / v1 / recovery, which is the core disaster recovery interface. C_route=1.8

[0208] C_version: API version is stable, C_version=0.9

[0209] W_field:restore_location is the critical recovery path, W_field=2.0

[0210] R_restore_location=[1.0x1.0]x1.8x0.9x2.0=3.24 (after exceeding 1, it can be normalized to 1.0).

[0211] immediate_restore field:

[0212] Actual value: true

[0213] Check: It falls within the Boolean range and conforms to the business logic (the user wants to restore immediately).

[0214] R_immediate_restore=0

[0215] script_content field:

[0216] Actual value: "rm-rf / " (dangerous command).

[0217] examine:

[0218] Includes disabling the command rm

[0219] Length exceeded (although short, the content is dangerous).

[0220] w_j: "Content Security" has an extremely high weight, set to 1.2

[0221] D_ij: Because it contains a fatal command, D_ij=1.0

[0222] C_route=1.8, C_version=0.9, W_field=2.0 (The script content has a significant impact)

[0223] R_script_content=[1.2x1.0]x1.8x0.9x2.0=3.888 (normalized to 1.0).

[0224] Calculate R_field:

[0225] Weighted average: R_field = (Σ(W_field x R_i)) / (ΣW_field)

[0226] Only `restore_location` and `script_content` have risk scores.

[0227] R_field=(2.0x1.0+2.0x1.0) / (2.0+2.0)=(2+2) / 4=1.0.

[0228] Step 4: Call frequency risk scoring R_freq

[0229] Assume that the user has not called this interface in the past minute.

[0230] F_actual=1, F_expected (historical average)=0.1 times / minute

[0231] R_freq=min(1,(1-0.1) / 0.1)=min(1,9)=1.0.

[0232] Step 5: Parameter Combination Risk Score R_combo

[0233] Rule base matching R_rule:

[0234] There is a rule in the rule base: (restore_location=.. / .. / *, script_content=contains(rm|chmod|chown)) → High risk, and the current request perfectly matches this rule.

[0235] R_rule=1.0.

[0236] Machine learning pattern recognition (R_ml):

[0237] The model input feature vector contains all parameters.

[0238] The model analysis revealed a strong correlation between "path traversal + root directory deletion script".

[0239] R_ml=0.95.

[0240] Final R_combo:

[0241] R_combo=max(R_rule,R_ml)=max(1.0,0.95)=1.0.

[0242] Step 6: Calculate the interface-level comprehensive risk score (R_total)

[0243] Weights are set as follows: α = 0.4 (field), β = 0.3 (frequency), γ = 0.3 (combination).

[0244] R_total=αxR_field+βxR_freq+γxR_combo

[0245] R_total=0.4x1.0+0.3x1.0+0.3x1.0=1.0

[0246] Step 7: Final Results and Recommendations

[0247] The overall risk score R_total=1.0, reaching the highest risk level.

[0248] Risk Report:

[0249] Exception fields: restore_location, script_content

[0250] Constraints violated: `restore_location` violates the path whitelist regular expression; `script_content` contains the disabled command `rm`.

[0251] Risk types: path traversal attack, remote command execution (RCE).

[0252] Combination Risk: High-risk parameter combination detected (restore_location=.. / .. / *,script_content=contains(rm)).

[0253] Recommended action: Immediately block the request, log it in the audit log, and notify the security administrator.

[0254] Below, based on the single-version calculation example (i.e., the calculation process of the comprehensive field-level risk score R_i, parameter combination risk score R_combo, and interface-level comprehensive risk R_total will not be repeated), we will provide a calculation example with version changes. This example will further demonstrate the calculation process of the model update confidence score C, specifically:

[0255] (1) Brief description

[0256] ΔR_avg: Difference in average score between old and new models for historical call data: Using the same set of historical normal call data, inference is performed using the old model (v1) and the new model (v1.1) respectively to obtain two sets of interface-level comprehensive risk R_total (or the weighted average risk score R_field of field business weights, when there is no interface-level comprehensive risk) scores, and then the absolute value of the difference between their average values ​​is calculated.

[0257] V_stability Version stability factor: An empirical coefficient determined by the version number type, set as follows:

[0258] Major version change (v1→v2): V_stability=0.5;

[0259] Version change (v1.0→v1.1): V_stability=0.7;

[0260] Revision (v1.1.0→v1.1.1): V_stability=0.9.

[0261] (2) Hypothetical scenario

[0262] Calculation example, version v1.0 → version v1.1.

[0263] v1.0 version document fields: strategy, restore_disk, restore_location, immediate_restore → a total of 4 fields;

[0264] v1.1 version documentation fields: strategy, restore_disk, restore_location, timeout → a total of 4 fields;

[0265] The strategy, restore_disk, and restore_location are completely identical to those in v1.0 (same name and same constraints), while immediate_restore has been deprecated and timeout has been added.

[0266] Step 1: Calculate the field retention rate

[0267] |CommonFields|=3 (Three reserved fields)

[0268] |OldFields|=4

[0269] Field retention rate = 3 / 4 = 0.75.

[0270] Step 2: Calculate the average score difference ΔR_avg between the old and new models on historical call data.

[0271] Select 10,000 normal call logs from the v1.0 era.

[0272] Scoring this batch of data using the v1.0 model → Average score R_old_avg = 0.12

[0273] Scoring the same batch of data using the v1.1 model → Average score R_new_avg = 0.21

[0274] ΔR_avg=|0.21-0.12|=0.09.

[0275] Note: If the new model scores significantly higher on old data, it indicates that the new rule is too sensitive and may lead to false positives.

[0276] Step 3: Determine the version stability factor

[0277] v1.0→v1.1 is a minor version upgrade → V_stability=0.7.

[0278] Step 4: Calculate the model update confidence score C

[0279] C=(0.75)×(1−0.09)×0.7=0.75×0.91×0.7≈0.478

[0280] If C < 0.6, the model update risk is considered high, and a manual review process needs to be triggered.

[0281] Unlike the above embodiments, this embodiment, under the pervasive influence of version information, uses R_field to accurately capture single-point anomalies, R_combo to crack hidden risks in combination, R_total to aggregate and output decision-making basis, and C to dynamically ensure decision quality. The four work together to form a risk assessment chain of "version awareness → single field → multiple fields → global". This not only achieves real-time synchronization of "version changes, rule changes, score changes, and decision changes", but also ensures that "no single-field risk is missed, no combination risk is overlooked, and global decisions are based on evidence". This upgrades risk handling from "blind automation" to a dynamic, trustworthy, and precise API risk governance closed loop.

[0282] Example 3

[0283] like Figure 6 As shown, in one embodiment, a long-term and short-term data backup and storage device based on disk CDP is provided. This device includes:

[0284] The API documentation generation module 4001 is used to set up API documentation using a route configuration file framework. This framework, from the outside in, consists of: module name with version number, class name, route name, request method and its corresponding method name, and comment function description. This framework automatically generates URLs according to the " / module / class / route" template and generates API description files simultaneously.

[0285] The target API documentation module 4002 is used to obtain the target API documentation through the API integration tool. The API integration tool is configured to automatically start the version evolution analyzer when a major version change of the core business API is detected, analyze the semantic impact of the field type change, and trigger the manual review process.

[0286] Create a baseline model module 4003 to parse semantic information in the target API document and build a field-level behavior baseline model;

[0287] The comparative analysis module 4004 is used to collect behavioral field parameter information in real time, build a field-level behavioral dynamic model, compare it with the baseline model, and calculate the real-time constraint deviation D_{ij}.

[0288] The field-level scoring module 4005 is used to calculate whether behavioral parameters deviate from API document constraints using the field-level risk scoring formula R_i. If a deviation is found, abnormal behavior is identified and marked; otherwise, no action is taken. The field-level risk scoring formula R_i is: R_i = [Σ(w_j × D_{ij})] × C_version, where R_i is the risk score of the i-th field; w_j is the weight of the j-th constraint type; D_{ij} is the deviation degree of the i-th field from violating the j-th constraint; and C_version is the version confidence adjustment factor.

[0289] The baseline update module 4006 is used to output a field-level interpretable risk report and update the baseline model based on the risk scoring results.

[0290] Below, we provide some comparative experiments to further illustrate this embodiment. The specific experimental environment configuration parameters are shown in Table 2:

[0291] Table 2. Experimental Environment Configuration Parameters

[0292] name Configuration CPU Intel Core i5 12400 operating system Windows 10 Memory 32GB Programming Languages C++ and Python Model tools OpenAPI

[0293] (1) Experimental setup and subjects

[0294] This experiment employs a hybrid C++ and Python architecture to implement the core risk assessment engine. High-performance modules such as field parsing and rule matching are written in C++ and compiled into shared libraries, deployed in user space. Dynamic weight calculation, machine learning inference, and version metadata management modules are implemented in Python and run at the application layer. The entire system underwent functional and stress testing in a Rocky Linux 9.3 virtual machine environment (4 vCPUs / 8GB RAM / SSD storage).

[0295] (2) Test object

[0296] The disaster recovery API interfaces under multiple version evolutions are used to evaluate the comprehensive performance of different risk assessment models in terms of false positive rate (FPR) by simulating the abnormal parameter injection scenario of high-frequency calls in a large-scale microservice architecture.

[0297] (3) Construction of test dataset

[0298] Basic traffic generation: Based on the OpenAPI 3.0 specification, it automatically parses the interface definitions of three versions: recovery_api_v1.0.yaml, v1.1.yaml, and v2.0.yaml, and uses the Grammar-Based Fuzzing fuzzing engine to generate legitimate request samples.

[0299] Total sample size: A total of 5 million API request logs were generated, covering continuous call scenarios over 24 hours, with timestamp accuracy at the second level.

[0300] Each request contains the following fields: strategy (string, backup strategy identifier), restore_disk (device path, such as / dev / sdb), and restore_location (target path, version-dependent).

[0301] immediate_restore (boolean), script_content (optional script content), api_version (explicitly indicates the API version the request is targeting).

[0302] Abnormal sample injections accounted for approximately 15% of the total.

[0303] 3.5% - Field values ​​violate the current version's regular expression constraints. For example, v2.0 requires `restore_location` to be ` / data / backups / .*`, but `.. / .. / .. / etc / passwd` is passed in.

[0304] 2.0%, dangerous parameter combination attacks, such as immediate_restore=true + script_content=rm-rf / ;

[0305] 6.0%, cross-version obfuscation attacks, such as a client calling a v2.0 interface using a v1.0 obsolete field format;

[0306] 3.5%, high-frequency probing behavior, such as the same IP initiating more than 50 recovery requests within 1 second;

[0307] (4) Experimental group design

[0308] To verify the model's performance in different scenarios, multiple sets of comparative experiments were designed. The model configurations and core mechanisms of each experimental group are compared in Table 3.

[0309] Table 3. Detailed introduction of experimental groups

[0310] experimental group Model Configuration Core Mechanism Baseline Group Traditional static rule engine It uses a field blacklist with a fixed threshold (0.85) and regular expression validation, lacking version awareness and combined analysis capabilities. Exp-1 group Field-level dynamic scoring model Introducing the field risk scoring formula R_i, supporting dynamic loading of validation rules based on API version documentation. Exp-2 group End-to-end intelligent risk assessment system (Full Model) It integrates four formulas: R_i (field), R_freq (frequency), R_combo (combination), and R_total (fusion), and dynamically adjusts the overall sensitivity using C=f(C_route,C_version).

[0311] (5) Test scenario and parameters

[0312] For API versions v1.0, v1.1, and v2.0, the accuracy and robustness tests shown in Table 4 were performed under the following multi-dimensional parameter combinations:

[0313] Table 4. Test Dimensions and Values

[0314] Test Dimensions Range of values Time window 1 hour, 6 hours, 12 hours, 24 hours Single request parameter complexity 3 fields, 5 fields, 8 fields Concurrent pressure 100 QPS, 1,000 QPS, 5,000 QPS Version Mixing Ratio Pure v1.0 / Pure v2.0 / Mixed traffic, v1.0: 30%, v1.1: 30%, v2.0: 40%

[0315] (6) Performance evaluation indicators

[0316] False Positive Rate (FPR): The percentage of legitimate requests that are incorrectly classified as high-risk. FPR = Number of legitimate requests incorrectly classified as high-risk / Total number of legitimate requests.

[0317] False Negative Rate (FNR): The proportion of genuine attack requests that were not detected. FNR = number of missed attack requests / total number of attack requests.

[0318] Unified judgment threshold: An alarm or block is triggered when the comprehensive risk score R_total output by all models is greater than or equal to 0.85;

[0319] Auxiliary metrics: average response latency, CPU / memory utilization.

[0320] (7) Test results

[0321] To evaluate the detection performance of the models across API version evolutions, risk detection tests were conducted on the three models, and the results are compared in Table 5:

[0322] Table 5. Risk detection test results of the three models under API version evolution

[0323]

[0324] (8) Suggestions for data interpretation and chart drawing

[0325] 8.1. False Alarm Rate (FPR) Line Chart

[0326] X-axis: API version (v1.0, v1.1, v2.0)

[0327] Y-axis: False Alarm Rate (%)

[0328] Baseline (solid red line): In v1.1 and v2.0, the false positive rate rose sharply to 25.6% because its model could not adapt to document changes, misjudging a large number of legitimate new format requests as abnormal.

[0329] Exp-1 (blue solid line): Thanks to the routing configuration file framework settings and the introduction of the version confidence adjustment factor C_version in the field-level risk score R_i, the false positive rate is 10.4%. When the version changes, the sensitivity of the risk score is automatically reduced or an audit is triggered, effectively suppressing the surge in the false positive rate.

[0330] Exp-2 (solid green line): With the complete model, the false alarm rate is 6.5%. The system can more intelligently determine when human intervention is needed, further controlling the false alarm rate to a low level.

[0331] 8.2. Line chart of false negative rate (FNR)

[0332] X-axis: API version (v1.0, v1.1, v2.0)

[0333] Y-axis: Missed Report Rate (%)

[0334] Baseline (orange dashed line): In v2.0, the false negative rate also increased to 15.3% because it lacked awareness of the attack patterns in the new version.

[0335] Exp-1 (red dashed line): Thanks to the routing configuration file framework settings and the introduction of the version confidence adjustment factor C_version in the field-level risk score R_i, the false negative rate does not exceed 10.7%, which can control false alarms to a certain extent.

[0336] Exp-2 (green dashed line): With the help of the configuration file framework and the complete R_field, R_combo, R_total, and C scoring models, the system can not only identify anomalies in a single field, but also discover complex attack patterns. Therefore, the false negative rate is the lowest, at only 7.2%.

[0337] (9) Conclusion

[0338] As shown in Table 4 and appendix above Figure 7As shown, when the API underwent version evolution, the baseline system, which did not adopt the solution of this embodiment, had a false positive rate as high as 25.6%, severely interfering with the normal operation of business. Experimental group Exp-1, which only used field-level risk scoring, successfully reduced the false positive rate to 10.4%, demonstrating the effectiveness of the version framework and field-level risk scoring system. Experimental group 2, which fully applied all formulas, performed best, with a false positive rate of only 6.5% and a false negative rate of the lowest at 7.2%, verifying the advantages of the 'document semantics-behavioral model-closed-loop update' architecture proposed in this embodiment in ensuring system stability and security.

[0339] This embodiment constructs a device structure that integrates document parsing, baseline management, real-time detection, and risk response. First, the intelligent document parsing engine converts the field constraints in the API document into a runtime baseline with self-updating capabilities in real time. Then, it measures the parameters of each call in real time. Next, it links the interpretable risk scoring module and the baseline update module to generate a root cause report and matches feasible handling actions such as interception and rate limiting from a pre-set policy library to realize a parameter behavior risk prediction device applicable to API documents.

[0340] Example 4

[0341] exist Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention, such as... Figure 8 As shown, the electronic device may include a processor 510, a communication interface 520, a memory 530, and a communication bus 540, wherein the processor 510, the communication interface 520, and the memory 530 communicate with each other through the communication bus 540. The processor 510 may call logical instructions in the memory 530 to execute the API document semantic-aware parameter behavior risk prediction method as described in Embodiment 1 or 2.

[0342] Furthermore, the logical instructions in the aforementioned memory 530 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, essentially, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0343] Example 5

[0344] In this embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the program is executed by a processor, it implements the API document semantic-aware parameter behavior risk prediction method as described in Embodiment 1 or 2.

[0345] Example 6

[0346] In this embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the API document semantically aware parameter behavior risk prediction method as described in Embodiment 1 or 2.

[0347] The computer storage medium of this invention can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0348] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0349] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0350] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, Ruby, and Go, as well as conventional procedural programming languages ​​such as "C" or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0351] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention. Therefore, the scope of protection of this patent should be determined by the appended claims.

Claims

1. An API document semantic-aware parameter behavior risk prediction method, characterized in that, The method comprises the steps of: The API document is set in a routing configuration file framework, which is from outside to inside: module name with version number, class name, route name, request method and corresponding controller method name, and annotation function description; the framework automatically generates a URL according to the " / module / class / route" template, and synchronously generates an API description file; A target API document is acquired through an API integration tool, and the API integration tool is configured to: when a core business API main version change is detected, automatically start a version evolution analyzer, analyze the semantic influence of field type changes, and trigger a manual review process; Semantic information in the target API document is parsed to construct a field-level behavior baseline model; Field-level behavior dynamic models are constructed by collecting field parameter information in real time, and are compared with the baseline model to calculate real-time constraint deviation D_{ij}, specifically using length deviation D_{length}, the formula of which is: D_{length}=max(0,L_{actual}-L_{expected}) / (L_{max}-L_{expected})×W_field, wherein max(0,L_{actual}-L_{expected}) is the difference between the actual length and the expected length; L_{max}-L_{expected} is the difference between the maximum length defined in the document and the expected length, serving as a maximum tolerance range; W_field is a field semantic weight factor, which is a coefficient greater than or equal to 1 and is dynamically adjusted according to the business semantics of the field; Whether the behavior parameters deviate from the API document constraints is calculated through a field-level risk score R_i formula, if deviating, an abnormal behavior is identified and marked; if not deviating, no processing is performed; wherein the field-level risk score R_i formula is: R_i=[Σ(w_j×D_{ij})]× C_version, R_i is the risk score of the i-th field; w_j is the weight of the j-th constraint type; D_{ij} is the deviation of the i-th field from the j-th constraint; C_version is a version confidence adjustment factor; According to the risk score result, a field-level explainable risk report is output, and the baseline model is updated.

2. The API documentation semantically aware parameter behavior risk prediction method of claim 1, wherein, The step of setting the API document in the routing configuration file framework further comprises: All routing configuration files under the target directory are traversed to extract all routing rules; According to the configuration file framework of " / module / class / route", a URL with a version number, a request method, a controller class name and a method name are generated for each routing rule in real time, and an API description file is synchronously output; The annotation function description of the controller method is extracted through PHP reflection; The URL, request method, API required parameters and function description in the controller method annotation are serialized according to the standard interface description format, and the API document is published in a readable and testable manner based on the routing configuration file framework; The configuration file framework is from outside to inside: module name with version number, class name, route name, request method and corresponding controller method name, and annotation function description.

3. The API document semantically aware parameter behavior risk prediction method according to claim 1 or 2, characterized in that, In the API integration tool, it is also configured with: For core operation identification, automatically extract core special fields and assign preset semantic weight; At the same time, the field level risk score R_i formula increases C_route, specifically: R_i=[Σ(w_j× D_ij)]×C_version×C_route, wherein C_route is a routing context adjustment factor, and the value of C_route is the preset semantic weight value when the URL contains the core operation identification.

4. The API document semantically aware parameter behavior risk prediction method according to claim 1 or 2, characterized in that, Before the step of outputting a field-level explainable risk report according to the risk score result and updating the baseline model, it further includes: The combination suspicion degree is normalized, and whether the field behavior parameter deviates from the API document constraint is calculated through a parameter combination risk score formula R_combo. If the hard rule is violated, it is judged as hard deviation, and directly scored as 1; if the hard rule is not violated, the deviation score is output by using a machine learning model; wherein the parameter combination risk score formula R_combo formula is: R_{combo}=\begin{cases}1.0,&\text{if}R_{rule}=1.0\\R_{ml},& \text{if} R_{rule}=0.0\end{cases}, wherein: R_combo is the parameter combination risk score, the value range is [0, 1], 1 indicates that there is a high-risk combination, and 0 indicates safety; P_1, P_2,..., P_n are n parameters that commonly appear as input parameters in an API request; R_{rule} is a rule library matching, specifically, R_{rule}=\begin{cases}1.0,& \text{if}(P_i,P_j,...,P_k)\in\text{Known\_Dangerous\_Pairs} \\0.0,&\text{otherwise}\end{cases}, Known\_Dangerous\_Pairs is a configurable and predefined dangerous parameter combination rule library, which is stored in a persistent storage medium and supports dynamic loading and hot updating, the rule entry is defined in the form of structured data, (P_i, P_j,..., P_k) is a specific group of k parameters extracted from n parameters, k≤n; R_{ml} is a machine learning pattern recognition, R_{ml}=\text{Model}(P_1, P_2,...,P_n), Model is a pre-trained machine learning classification model, and (P_1, P_2,..., P_n) is a feature vector of the current request parameter combination.

5. The API document semantically aware parameter behavior risk prediction method according to claim 1 or 2, characterized in that, Before the step of outputting a field-level explainable risk report according to the risk score result and updating the baseline model, it further includes: The interface total risk is normalized by collecting and using interface behavior parameters, and an interface-level comprehensive risk R_total is calculated, and a calculation formula is R_total=α×R_field+β×R_freq+γ×R_combo, R_field is a weighted average risk score based on field service weight, a calculation formula is R_field= (Σ(W_field×R_i)) / (ΣW_field) ; R_freq is a calling frequency risk score, a calculation formula is R_freq=min(1,(F_{actual}-F_{expected}) / F_{expected}) ; R_combo is a parameter combination risk score, a calculation formula is R_combo=(if a known dangerous combination is detected, then 1.0, otherwise a value between 0.5-1.0 output by a machine learning model); α, β, γ are three weight coefficients, and α+β+γ=1 is satisfied; The online confidence score is normalized by collecting and using model behavior parameters, and a model update confidence C is calculated, and a calculation formula is C=(|CommonFields| / |OldFields|)*(1-ΔR_avg)* V_stability, |CommonFields| / |OldFields| is a retention rate of new and old documents at the field level;ΔR_avg is an average score difference of new and old models for historical calling data, and a calculation formula is ΔR_avg=|R_new_avg-R_old_avg|;V_stability is an API version stability factor.

6. An API document semantic-aware parameter behavior risk prediction apparatus, characterized by, The device comprises: An API document generation module is configured to set an API document in a routing configuration file framework, and the framework comprises, from outside to inside, a module name with a version number, a class name, a routing name, a request method and a corresponding method name, and an annotation function description;The framework automatically generates a URL according to a " / module / class / route" template, and synchronously generates an API description file; An API document acquisition module is configured to acquire a target API document by using an API integration tool, and the API integration tool is configured to automatically start a version evolution analyzer when a core business API main version is changed, analyze semantic influence of field type changes, and trigger a manual review process; A baseline model creation module is configured to parse semantic information in the target API document, and build a field-level behavior baseline model. The comparison analysis module is configured to collect behavior field parameter information in real time, construct a field-level behavior dynamic model, compare the field-level behavior dynamic model with a baseline model, and calculate a real-time constraint deviation D_{ij}. The length deviation D_{length} is used, and the formula is D_{length}=max(0,L_{actual}-L_{expected}) / (L_{max}-L_{expected})×W_field, where max(0,L_{actual}-L_{expected}) is the difference between the actual length and the expected length; L_{max}-L_{expected} is the difference between the maximum length defined in the document and the expected length, which is used as the maximum tolerance range; and W_field is a field semantic weight factor, which is a coefficient greater than or equal to 1 and is dynamically adjusted according to the business semantics of the field. The field-level scoring module is configured to calculate whether the behavior parameter deviates from the API document constraint by using a field-level risk score R_i formula. If the behavior parameter deviates from the API document constraint, the field-level scoring module identifies abnormal behavior and marks the abnormal behavior. If the behavior parameter does not deviate from the API document constraint, the field-level scoring module does not process the behavior parameter. The field-level risk score R_i formula is R_i=[Σ(w_j×D_{ij})]× C_version, where R_i is the risk score of the i-th field; w_j is the weight of the j-th constraint type; D_{ij} is the deviation of the i-th field from the j-th constraint; and C_version is a version confidence adjustment factor. The baseline update module is configured to output a field-level interpretable risk report according to the risk score result and update the baseline model.

7. A computer device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor executes the program to implement the steps of the API document semantic-aware parameter behavior risk prediction method according to any one of claims 1 to 5.

8. A computer-readable storage medium having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the API document semantic-aware parameter behavior risk prediction method according to any one of claims 1 to 5.

9. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the API document semantic-aware parameter behavior risk prediction method according to any one of claims 1 to 5.

Images