API security monitoring and analysis system

Abstract

The invention relates to the technical field of API monitoring, and discloses an API security monitoring and analysis system. The system comprises an acquisition module used for acquiring and preprocessing inbound and outbound traffic of an API gateway to obtain normalized API call data; the feature extraction module is used for extracting API behavior features and API structure features; the establishing module is used for establishing an API behavior security baseline and an API structure security baseline; the anomaly detection module is used for carrying out two-dimensional anomaly detection and generating an abnormal event record; and the generation module is used for carrying out security event association analysis based on the abnormal event record and generating an API security event report and a defense strategy. The method ensures the reservation of complete API interaction details, solves the problem of fuzzy security event reconstruction, and can effectively cope with continuously changing API security threats.

Description

TECHNICAL FIELD

[0001] The application relates to the technical field of API monitoring, and in particular to an API security monitoring and analysis system. BACKGROUND

[0002] Traditional API security protection schemes mainly rely on preset rules and signature features, and cannot cope with advanced persistent threats and zero-day vulnerabilities, especially when facing complex business logic vulnerabilities and carefully disguised abnormal behaviors, the detection effect is seriously insufficient. More troublesome is that the existing API security monitoring scheme often takes behavior analysis and structure detection as independent protection layers, lacks effective information sharing mechanism, and cannot identify cross-domain combination attacks, and when an attack simultaneously uses behavior anomalies and structural vulnerabilities, the existing system is difficult to discover and associate in time.

[0003] The existing API security monitoring technology has obvious short boards in the data collection link. Due to the consideration of gateway performance and business continuity, most schemes can only collect part of the sample data or simplified interaction summary, resulting in the loss of key details in the security event reconstruction process. At the same time, API security monitoring faces the contradiction between explosive growth of data volume and analysis accuracy. With the explosive increase of enterprise API quantity, the traditional single-dimensional feature extraction method is difficult to cope with complex and variable attack patterns, especially under the condition of limited historical data, the model generalization ability is seriously insufficient, causing frequent false alarms and low analysis efficiency. SUMMARY

[0004] The application provides an API security monitoring and analysis system, which ensures the preservation of complete API interaction details, solves the problem of fuzzy security event reconstruction, and can effectively cope with changing API security threats.

[0005] In a first aspect, the application provides an API security monitoring and analysis system, which comprises: A collection module for preprocessing the inbound and outbound traffic of an API gateway to obtain normalized API call data; A feature extraction module for extracting API behavior features and API structure features based on the normalized API call data; An establishment module for establishing API behavior security baseline and API structure security baseline according to the API behavior features and the API structure features; An anomaly detection module for performing two-dimensional anomaly detection on the API behavior security baseline and the API structure security baseline to generate an abnormal event record; A generation module for performing security event correlation analysis based on the abnormal event record to generate an API security event report and a defense strategy.

[0006] With reference to the first aspect, in a first implementation form of the first aspect of the present application, the collecting module further comprises: a listening unit, configured to deploy a distributed data collector in front of an API gateway, listen to a communication channel of the API gateway, and acquire API communication data flow; a capturing unit, configured to capture data packets of the API communication data flow, and extract target API interaction records containing a request system, a URL path, a request header, a request body, a status code, a response body, a response time, and a client identifier; a grouping unit, configured to store the target API interaction records into a temporary buffer, and associate and group the target API interaction records according to API endpoints, timestamps, and session identifiers, to form original API flow data; a normalization unit, configured to perform normalization preprocessing on the original API flow data, to obtain normalized API call data.

[0007] With reference to the first aspect, in a second implementation form of the first aspect of the present application, the normalization unit is specifically configured to: perform format identification on the original API flow data, to obtain API type identification information containing REST, GraphQL and SOAP; perform format unification conversion on the original API flow data based on the API type identification information, to obtain uniform format API data, and perform data cleaning on the uniform format API data, to obtain cleaned API data; perform tokenization processing on sensitive fields in the cleaned API data, to replace sensitive information of a user identifier and an authentication credential with an irreversible token value, while retaining the correlation between data, to obtain privacy protection API data; perform field standardization processing on the privacy protection API data, to obtain field standardized API data, and perform data shunting preparation on the field standardized API data, to obtain normalized API call data.

[0008] With reference to the first aspect, in a third implementation form of the first aspect of the present application, the feature extraction module further comprises: a division unit, configured to divide the normalized API call data into behavior flow data and structure flow data, the behavior flow data containing time sequence features and frequency features of API calling, and the structure flow data containing parameter features and structure features of API request and response; a time sequence feature extraction unit, configured to perform time sequence feature extraction on the behavior flow data through a time sequence convolution network, to extract API behavior time sequence features; The parameter dependency processing unit is used to construct an API parameter dependency graph based on the structured flow data, and process the API parameter dependency graph through a graph neural network to obtain API structural relationship features. The multi-scale feature analysis unit is used to input the API behavior temporal features into the multi-scale receptive field structure for multi-scale feature analysis to obtain multi-scale API behavior features, and to perform message passing calculation on the API structure relationship features to obtain enhanced API structure features. The interactive fusion unit is used to interactively fuse the multi-scale API behavior features and the enhanced API structure features through a feature mapping matrix to obtain API behavior features and API structure features.

[0009] In conjunction with the first aspect, in a fourth implementation of the first aspect of the present invention, the parameter dependency processing unit is specifically used for: Parameters are extracted from the structured stream data to obtain the API parameter set; Based on the API parameter set, each parameter is mapped to a uniquely identified graph node, and each node is assigned attribute information including parameter type, length limit, and value range, thus obtaining the API parameter node set; Dependency analysis is performed on the API parameter node set to obtain the API parameter edge set, and an API parameter dependency graph is constructed based on the API parameter node set and the API parameter edge set. A graph convolutional network is used to extract features from the API parameter dependency graph and perform multiple rounds of message passing iterations to calculate the API parameter node embedding representation. The embedded representation of the API parameter nodes is subjected to graph pooling, and node representations with similar structural features are merged to generate API structural relationship features.

[0010] In conjunction with the first aspect, in a fifth implementation of the first aspect of the present invention, the establishing module is specifically used for: The encoder in the autoencoder network model is used to perform time-series reconstruction calculation on the API behavior features to obtain the API behavior encoded representation. The API behavior encoding representation is input into the decoder in the autoencoder network model for sequence reconstruction to obtain the sequence reconstruction result. The error matrix between the API behavior feature and the sequence reconstruction result is calculated to obtain API behavior reconstruction error data. Kernel density estimation is performed on the API behavior reconstruction error data to construct a normal behavior probability distribution model for each API endpoint. Dynamic thresholds are set according to the differences in API call patterns in different time periods to obtain the API behavior safety baseline. The API structural features are subjected to parameter syntax rule learning to extract a set of API parameter constraints containing the type, value range and dependency relationship of API parameters; Based on the API parameter constraint set, frequent subgraph mining is performed to extract common structural patterns and dependencies between API parameters, thereby obtaining the API structural security baseline.

[0011] In conjunction with the first aspect, in the sixth implementation of the first aspect of the present invention, the anomaly detection module is specifically used for: A multidimensional time-series feature vector is constructed based on real-time API call data, and the Mahalanobis distance between the multidimensional time-series feature vector and the historical normal pattern distribution in the API behavior safety baseline is calculated to obtain the behavior anomaly score. The parameter structure of real-time API requests and responses is recursively traversed and checked to verify whether the type, length, and value range of each parameter conform to the constraints of the structure syntax tree in the API structure security baseline, and a structure anomaly score is obtained. Based on the API type identification information and the context of the current API call, a weighted allocation is performed on the behavioral anomaly score and the structural anomaly score to obtain a comprehensive anomaly score; The comprehensive anomaly score is graded and determined to obtain the first anomaly determination result; A deep inspection is performed on the API calls identified as suspicious in the first anomaly determination result. The current API call is placed in the context sequence of the most recent N calls for comprehensive evaluation. The context-aware determination model is applied to perform a second evaluation on the suspicious call to obtain the second anomaly determination result. Based on the second anomaly determination result, an anomaly event record is generated that includes the anomaly type, anomaly score, triggering rules, relevant API call context information, and a timestamp.

[0012] In conjunction with the first aspect, in the seventh implementation of the first aspect of the present invention, the generation module is specifically used for: The abnormal event records are mapped to a bounded space interval, and random noise following a Laplace distribution is added to form perturbation data. Boundary pruning is performed on the perturbation data to obtain privacy-preserving abnormal data. Temporal correlation analysis is performed on the privacy-protected anomaly data to obtain temporal correlation results, and spatial correlation analysis is performed on the privacy-protected anomaly data based on the API dependency graph to obtain spatial correlation results. Based on the API call behavior fingerprint features extracted from the privacy protection anomaly data, attacker association results are obtained. Furthermore, by querying the vulnerability knowledge graph, the privacy protection anomaly data is matched and analyzed with known vulnerabilities to obtain vulnerability association results. The time-dimensional correlation results, the spatial-dimensional correlation results, the attacker correlation results, and the vulnerability correlation results are input into the behavior-structure hybrid model for abnormal event classification to obtain the attack classification results; An API security incident report is generated based on the attack classification results, and a corresponding defense strategy is constructed based on the attack type and risk level in the API security incident report.

[0013] The technical solution provided by this invention employs a dual-branch feature extraction architecture that can simultaneously capture the behavioral patterns and structural features of API calls. Information sharing between the two branches is achieved through a feature mapping matrix, effectively identifying cross-domain combined attacks and complex threat patterns. A high-performance full-data acquisition and standardized preprocessing mechanism ensures the preservation of complete API interaction details, resolving the ambiguity issue in security event reconstruction. Simultaneously, token mapping technology achieves a balance between data privacy protection and analytical value. The multi-task learning model significantly enhances feature extraction capabilities, effectively distinguishing between abnormal API call behavior and API structural vulnerabilities even under limited historical data constraints, greatly improving model generalization ability. The self-supervised security baseline learning technology eliminates the need for manually labeled abnormal samples. Through dynamic threshold adjustment of adaptive time windows and parameter syntax rule learning, it establishes a security baseline that better reflects actual API usage. The dual-dimensional anomaly detection and multi-level joint judgment mechanism, combined with context-aware evaluation, effectively reduces the false positive rate. In particular, the deep inspection process accurately determines boundary conditions, significantly improving detection accuracy. The bidirectional bounded perturbation handling mechanism ensures ε-local differential privacy while limiting noise impact to a controllable range, balancing data privacy protection and analytical accuracy, enabling security analysis to be completed in a single communication round. Multi-dimensional security event correlation analysis forms a complete attack chain view, accurately classifying attack types through a behavior-structure hybrid model and correlating with known vulnerability databases to generate targeted defense strategies and security hardening recommendations. The defense effectiveness verification mechanism and dynamic updates to the security baseline form a closed-loop feedback system, enabling the entire API security monitoring and analysis system to continuously evolve and effectively address ever-changing API security threats. Attached Figure Description

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

[0015] Figure 1 This is a schematic block diagram illustrating the structure of the API security monitoring and analysis system provided in the embodiments of this application. Detailed Implementation

[0016] The technical solutions of the embodiments of the present invention will be clearly and objectively described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0017] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content and operations / steps, nor does it necessarily have to be performed in the described order. For example, some operations / steps can be broken down, combined, or partially merged, so the actual execution order may change based on the actual situation.

[0018] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of the application. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0019] It should also be further understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0020] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features described herein can be combined with each other.

[0021] Please see Figure 1 , Figure 1 A flowchart illustrating the API security monitoring and analysis system 100 provided in this application embodiment is shown below. Figure 1 As shown, the API security monitoring and analysis system 100 provided in this application embodiment includes: The data acquisition module 110 is used to preprocess the inbound and outbound traffic of the API gateway to obtain standardized API call data. Specifically, the monitoring unit embeds a distributed, high-performance collector at the front end of the API gateway, integrated into the network communication channel layer, to transparently monitor all data streams passing through the API gateway with low latency and no loss. This unit can proactively probe multiple protocol stacks such as TCP, HTTP / HTTPS, etc., to capture protocol-independent data streams and dynamically identify traffic types. During the monitoring process, if a new API session is established or a data packet flows through the gateway, the interception unit immediately performs layered packet interception on the communication data stream. Through deep packet inspection technology, it extracts key data content from each API call interaction, including the identity of the requesting system, the target URL path, detailed request header fields and request body content, the status code and response body returned by the backend, the timestamps and delayed response times for each request and response, and the unique identifier of the terminal client device. All interaction information is encapsulated into target API interaction records. The grouping unit writes the real-time captured target API interaction records into a high-efficiency memory buffer. For high-concurrency and high-traffic scenarios, a concurrent queue and high-performance buffer pool management mechanism is adopted to ensure that traffic records are not lost. During the buffering phase, scattered interaction records are automatically merged according to logical sessions based on API endpoints, global timestamps, and unique identifiers for each session, forming a raw API traffic data stream with clear correlation. The normalization unit performs multiple rounds of data normalization and preprocessing operations on the raw API traffic data stored in the buffer. Adaptive field mapping is performed for different API protocol styles (such as REST, GraphQL, SOAP, etc.), uniformly transforming various types of raw data into a standardized JSON structure, and using regular expression validation, field completion, and other methods to correct potential formatting errors and missing fields. For sensitive parameters and privacy information, an anonymization mechanism based on irreversible encrypted tokens is integrated to ensure that original identities, credentials, phone numbers, email addresses, etc., are not exposed in the downstream analysis process, while maintaining the inherent correlation between data. Through field normalization, data cleaning, and structural consistency checks, a normalized API call data stream is output.

[0022] The system performs format identification on raw API traffic data. Using an embedded protocol analysis engine, it parses the protocol type of each data entry, distinguishing and marking the corresponding API type for REST-style URL paths and parameters, GraphQL queries and fields, or SOAP XML message bodies, generating API type identification information for subsequent data processing. Based on the API type identification, the standardization unit initiates a format unification conversion process, using targeted data mapping templates to map various structures, such as REST parameter pairs, GraphQL queries and variables, and SOAP nested XML content, into a unified internal JSON format. During the conversion, it intelligently corrects format anomalies, field misalignments, and encoding inconsistencies, and completes missing fields to obtain unified format API data. The unified format API data undergoes data cleaning, filtering out redundant, useless, or malformed data fragments, removing duplicate records and null fields, improving data purity and usability, resulting in cleaned API data. Addressing the core requirements of data security and user privacy protection, the standardization unit integrates a high-strength sensitive field tokenization mechanism. For highly sensitive information such as user identifiers, authentication credentials, mobile phone numbers, and email addresses, the system automatically identifies and replaces them with irreversible encrypted tokens. Simultaneously, a token mapping index is established to ensure that the data maintains its relevance at the call chain and session levels after anonymization. After privacy protection is completed, API data undergoes field standardization. Through unified field naming, value range normalization, and type correction, all data achieves a high degree of standardization at the field level, facilitating feature extraction and logical analysis in subsequent modules. Based on the consistent standardization of all fields and data structures, the standardization unit performs multi-stream preparation of the data, automatically streaming it according to different purposes such as behavioral analysis and structural analysis to obtain standardized API call data.

[0023] Feature extraction module 120 is used to extract API behavior features and API structure features based on standardized API call data; Specifically, the partitioning unit divides API call data into two subsets based on features such as timestamps, call order, and request-response cycles: behavioral flow data and structural flow data. Behavioral flow data retains dynamic characteristics such as timing features, call frequency, and call intervals in API interactions, while structural flow data extracts static structural features such as parameter distribution, field nesting, dependency paths, and return structures from the API request and response bodies. After obtaining the behavior flow data, the temporal feature extraction unit initiates the temporal modeling process of API behavior. It uses a temporal convolutional network to perform sliding window convolution operations on the API call sequence to capture call frequency change patterns, periodic fluctuation characteristics, and behavioral trend information at different time scales. It also combines an attention mechanism with learnable weights to weight and strengthen key behavior segments, extracting distinctive API behavior temporal features. Simultaneously, the structure flow data is input into the parameter dependency processing unit. In this unit, an API parameter dependency graph is automatically constructed based on the order of appearance, nesting level, and dependency reference relationships of parameters in the request and response. This graph treats each parameter as a node and field references or conditional dependencies as edges, forming a semantic structure graph. By using a graph neural network to perform node embedding and neighbor propagation operations on this graph, the system can learn the structural dependency strength and attack-sensitive paths between parameters, extracting API structural relationship features with attack semantics. To enhance the model's ability to recognize complex behaviors and structural changes, the multi-scale feature analysis unit refines and enhances the two types of features mentioned above. Specifically, the temporal features of API behavior are input into a multi-scale receptive field structure. By setting convolutional kernels and sliding windows of different sizes, parallel modeling of short-term frequent call patterns and long-term gradual trends is achieved, outputting multi-scale API behavior features with a time-dimensional hierarchy. Simultaneously, a multi-layer message passing mechanism from a graph neural network is applied to the API structural relationship features, aggregating adjacent node information layer by layer. This improves the semantic integrity of the contextual embedding of nodes in the parameter-dependent graph, resulting in enhanced API structural features with stronger structural consistency and clearer anomaly boundaries. The interactive fusion unit performs semantic cross-fusion of these two types of features through a learnable feature mapping matrix. The fusion process introduces the mapping matrix and trainable weights to achieve bidirectional information flow between behavior and structure. This allows behavioral patterns to reference structural features for contextual awareness, while structural relationships can be inferred from behavioral trajectories, yielding API behavioral features and API structural features.

[0024] By parsing the request and response body fields in the structured flow data, all parameters in each API interaction are extracted with high precision, forming an API parameter set. This set includes top-level key-value pairs, as well as multi-level structures such as nested objects, array fields, and conditional reference paths. Each independent parameter in this API parameter set is mapped to a uniquely identified node in the graph. Simultaneously with node creation, static attribute information related to the parameter is injected into each node, such as the parameter type (e.g., string, integer, boolean, object), possible length limits, value range, regular expression constraints, and their optionality. This metadata becomes the input features for subsequent graph structure learning, forming a set of attributed API parameter nodes. Dependency analysis is performed on the API parameter node set. The dependency analysis module identifies structural dependencies or semantic relationships between parameters and constructs an API parameter edge set accordingly. Dependency discovery is based on multiple mechanisms, such as path nesting between fields, conditional binding of field values, and constraints such as "if A exists, then B must exist" or "the value range of B depends on the specific value of A." Extraction is achieved through a dual mechanism of rule engine and statistical co-occurrence analysis, constructing a node-edge data structure. A directed or undirected API parameter dependency graph is generated based on the node set and edge set. This graph is an explicit model of the API request or response structure logic, reflecting the business logic constraints and parameter propagation paths behind the API interface design. The parameter dependency processing unit inputs the API parameter dependency graph into a graph convolutional network structure. The graph convolutional network learns the contextual embedding representation of parameter nodes in the entire graph layer by layer through iteratively performing feature aggregation and information passing operations. In each round of message passing, the system weights and integrates the features of each node with the features of its neighboring nodes, and improves the feature expressiveness through a non-linear activation function. After multiple rounds of iteration, each API parameter node contains its own attribute information, as well as deep embedding vectors of its adjacency structure features and semantic environment. These vectors are used to determine whether the parameter is in an abnormal topology or deviates from common dependency patterns. Graph pooling is performed on the above embedding vector set. Through methods such as clustering reduction, graph attention filtering, or isomorphic structure folding, multiple node representations with similar semantics, similar functions, or repetitive structures are merged into a representative node, thereby effectively merging structurally repetitive fragments, simplifying the graph structure complexity, improving representation compactness, and generating API structural relationship features.

[0025] Establish module 130, which is used to establish API behavior security baseline and API structure security baseline based on API behavior characteristics and API structure characteristics; Specifically, high-dimensional API behavior feature sequences are input into the encoder part of the autoencoder network. Through multi-layer nonlinear mapping, complex temporal data of behavior is compressed into a low-dimensional latent space encoded representation, effectively extracting key behavioral patterns and hidden associations from the original API behavior sequences, forming an efficient representation of the original behavior flow. The encoded API behavior representation is then input into the decoder part of the same autoencoder, performing inverse mapping and sequence reconstruction to restore temporal feature results that are as close as possible to the original API behavior sequences. An error matrix is ​​calculated by measuring the difference between the original API behavior features and the sequence reconstruction results from the autoencoder's decoding output. A kernel density estimation method is used to statistically model the large amount of collected API behavior reconstruction error data, establishing a separate probability distribution model for behavior reconstruction errors for each API endpoint. This statistical distribution can characterize the error fluctuation patterns exhibited when the API behavior sequence deviates from the "healthy baseline" learned by the autoencoder under normal business scenarios, providing a theoretical basis for anomaly detection. Meanwhile, considering that API call patterns dynamically change with time periods, business peaks, weekdays / weekends, etc., in actual business environments, a dynamic threshold setting mechanism is introduced during baseline modeling. By adaptively segmenting and modeling the distribution of API behavior in different time periods, the behavioral security baseline can automatically perceive and adapt to normal fluctuations under different business cycles, thereby reducing the risk of false positives and false negatives. Simultaneously, for API structural feature modeling, a parameter syntax rule learning algorithm is used to summarize the types, statistically analyze the value ranges, and perform parameter dependency analysis on parameters appearing in historical data for each API endpoint, forming a structured set of API parameter constraints. Based on this set of parameter constraints, a frequent subgraph mining algorithm is executed to analyze the combination relationships, dependency graphs, and frequency of occurrence of parameters in historical call samples, extracting the most common and representative API structural patterns and stable parameter dependency structures, providing highly reliable sample evidence for the structural security modeling of API interfaces. Through the above dual modeling mechanism of autoencoder behavior reconstruction and structural subgraph mining, a behavioral security baseline reflecting the temporal security of API calls and a structural security baseline reflecting the compliance of interface structures are constructed simultaneously.

[0026] Anomaly detection module 140 is used to perform two-dimensional anomaly detection on API behavior security baseline and API structure security baseline, and generate anomaly event records; Specifically, high-dimensional temporal features are extracted from real-time API call data. The behavioral characteristics of each API request, including call time intervals, request frequency, call duration, and request sequence order, are encoded into a multi-dimensional temporal feature vector. This vector is then statistically compared with the historical normal pattern distribution in a pre-established API behavior security baseline. Mahalanobis distance is used as a distance metric to calculate the distance between the current temporal feature vector and the center of the normal baseline distribution. Mahalanobis distance automatically eliminates the influence of different feature dimensions and comprehensively considers the correlation between features to obtain a behavior anomaly score. Simultaneously, the anomaly detection module recursively traverses and validates the parameter structure of each real-time API request and response. By traversing each node of the parameter tree, it checks whether the parameter type, length, and value range strictly conform to the constraints set in the structure syntax tree of the API structure security baseline. If a parameter has a type error, out-of-bounds value, or does not conform to the dependency relationship, the system dynamically accumulates a structure anomaly score. This score effectively reflects whether the API data structure is at risk of tampering, injection attacks, or non-standard calls. Based on API type identification information and the context of the current API call, a weighted fusion mechanism is used to allocate weights for behavioral anomaly scores and structural anomaly scores. The weight allocation depends on the API interface type (e.g., REST, GraphQL, SOAP) and is also related to the business context, such as call frequency, operation scenario, and user sensitivity. Dynamic weight allocation ensures that the comprehensive anomaly score accurately reflects the multi-dimensional risk profile of the current API call, neither exaggerating low-risk behaviors nor concealing structural threats. After obtaining the comprehensive anomaly score, it is graded based on preset grading thresholds, outputting the first anomaly judgment result. Calls that are clearly safe or abnormal receive a rapid response, while API calls in the suspicious gray area proceed to a deep inspection stage. In the deep inspection stage, the anomaly detection module combines the current suspicious API call with the most recent N historical calls to form a context sequence, which is input into the context-aware judgment model. This model comprehensively analyzes the logical consistency, behavioral trends, and anomaly propagation paths between the current call and the historical behavior chain. Through sequence modeling and context constraints, it improves the recognition rate of complex attack behaviors such as multi-step attacks, low-frequency insertions, and hidden dependency disruptions, and outputs the second anomaly judgment result. The system automatically generates a structured record of abnormal events based on the second abnormality determination result. This record contains key information such as abnormality type, abnormality score, triggering rules, relevant API call context information, and event timestamp.

[0027] The generation module 150 is used to perform security event correlation analysis based on abnormal event records, and generate API security event reports and defense strategies.

[0028] Specifically, the feature vectors of anomalous events are mapped to a predefined bounded spatial interval, and random perturbation noise conforming to a Laplace distribution is added within this interval to form perturbed anomalous data. Boundary pruning is then performed on the perturbed data; that is, the clip function is used to forcibly truncate outliers exceeding the interval [a, b], limiting the data to a computable, secure, and legal range, resulting in a set of privacy-preserving anomalous data. Temporal correlation analysis is performed on the privacy-preserving anomalous data, combining factors such as timestamps, call frequency, and behavioral change trends to perform hierarchical temporal correlation analysis on the anomalous events in the time dimension, extracting potential time-intensive attack chains, periodic attack attempts, or long-tailed multi-step attack features, forming temporal correlation results. Simultaneously, based on a pre-constructed API dependency graph, path tracing is performed on the API endpoints involved in the anomalous events, identifying the lateral propagation, permission jumps, and resource concatenation paths of anomalous behavior between different API interfaces, outputting spatial correlation results, effectively revealing the true behavioral trajectory of attackers "moving laterally" within the system. By employing behavioral fingerprinting modeling, the behavioral patterns of each anomalous call are sequentially modeled and feature-encoded to generate a set of fingerprint vectors representing attacker characteristics. Multiple dispersed anomalous events are aggregated to a single attack source through fingerprint clustering and similarity calculation, forming attacker association results and enabling continuous tracking of potential malicious actors. Based on this, semantic matching and pattern comparison are performed on the structural content of the anomalous call, such as parameters, paths, and operation types, with a vulnerability knowledge graph. This reveals known vulnerability patterns such as SQL injection, XSS attacks, authentication bypass, and parameter pollution, outputting vulnerability association results to ensure the system can efficiently map and associate unknown attacks with historical threat knowledge. The association results from the time, space, attacker, and vulnerability dimensions are uniformly input into a behavior-structure hybrid classification model based on deep feature fusion. This model jointly learns anomalous behavioral features and structural anomalous features, comprehensively decides on different attack sources and types, and ultimately outputs specific attack classification results. These classification results cover attack categories such as SQL injection, privilege escalation, denial of service, and parameter tampering, and annotate the attack's impact range, anomalous intensity, and attack path, providing clear guidance for response mechanisms. Based on attack classification results, standardized API security incident reports are automatically generated. These reports include attack type, risk level, related call chains, attack path graphs, and recommended response measures. Corresponding defense strategies are automatically matched and generated based on the report content. For example, parameter purifying rules are automatically deployed for SQL injection attacks, access frequency limiting mechanisms are enabled for brute-force attacks, and graph-based call path access control is configured for lateral movement attacks. All defense strategies are continuously monitored for effectiveness and feedback after deployment, feeding back into the security baseline model for continuous evolution, forming a closed-loop "detection-defense-optimization" API security governance system.

[0029] Optionally, the acquisition module 110 also includes: The monitoring unit is used to deploy a distributed data collector in front of the API gateway to monitor the communication channels of the API gateway and obtain API communication data streams. The interception unit is used to intercept API communication data streams and extract target API interaction records containing request system, URL path, request header, request body, status code, response body, response time, and client identifier. Grouping units are used to store target API interaction records into a temporary buffer and group them according to API endpoint, timestamp, and session identifier to form raw API traffic data; The normalization unit is used to perform normalization preprocessing on the raw API traffic data to obtain normalized API call data.

[0030] Specifically, a distributed data collector is deployed at the front end of the API gateway. Coordinated and scheduled by the listening unit, the collector integrates with the gateway communication link and selects appropriate mirroring, bypassing, or direct insertion methods for different network architectures (such as cloud-native Kubernetes Ingress, traditional load balancing, or SDN virtualization channels) to directly monitor all data flows entering and leaving the API gateway. The listening unit has a built-in protocol adaptation engine that automatically detects various application layer protocols such as HTTP, HTTPS, and WebSocket, and parses the underlying TCP / IP and TLS handshake phases, ensuring that even in encrypted communication, traffic decryption and restoration can be completed in a trusted environment. This step achieves full-channel coverage of API traffic and, through load balancing and dynamic scaling capabilities, adapts to the high-concurrency business needs of cloud, microservice, and hybrid deployments, while ensuring the robustness and stability of the collection nodes themselves, preventing them from becoming bottlenecks due to surges in main business traffic. The interception unit processes raw data streams acquired in real-time from network interfaces or protocol stacks in an efficient asynchronous mode, using techniques such as deep packet inspection, protocol segmentation and reassembly, and data stream reordering to completely reconstruct multiple TCP packets or UDP message fragments belonging to the same API call into a single logical request. The system automatically merges long message content transmitted across packets based on metadata such as packet headers, flow identifiers, and session keys, avoiding the loss of critical fields due to fragmentation. The interception unit invokes a flexible data structure extraction engine to deeply analyze each API request and its response, accurately extracting key fields from the protocol header, body, and interaction metadata, including the requesting system (such as the calling source, user identifier, and originating application), URL path, complete request header content, request body parameters, response status code, response body data (including JSON / XML / text formats), response time of this request (millisecond precision), and client fingerprint or terminal identifier. All intercepted target API interaction records are written to an efficient temporary buffer, managed uniformly by the grouping unit. The buffer employs an in-memory database, a high-concurrency queue, and a first-in, first-out (FIFO) mechanism to ensure write performance while preventing packet loss, overflow, or blocking during peak periods. The grouping unit extracts the API endpoint (such as the specific interface name, service module, routing parameters, etc.), precise timestamps, and session identifiers (such as Token, SessionID, TraceID, CorrelationID, etc.) for each interaction record. Using these as primary keys, the raw data stream is grouped and merged in multiple dimensions, enabling automatic aggregation of all API requests and responses within the same session or transaction. This facilitates the reconstruction of multiple call relationships within a business chain and allows for tracing complex call flows across modules, services, and time zones. After the raw API traffic data is grouped and organized, the normalization unit initiates multiple rounds of preprocessing and format standardization processes on this data.The system automatically identifies the protocol type of API traffic (REST, GraphQL, SOAP, etc.) and maps parameters, structures, and call patterns of different protocol styles to a unified JSON structure through built-in adapters. To ensure compatibility and scalability, the normalization unit introduces configurable field mapping templates and regular expression extraction rules to dynamically adjust field names, levels, and types, resolving data clutter issues caused by inconsistent interface designs from different development teams. For nested objects, arrays, and binary content in the request and response bodies, recursive parsing and structured expansion are used to organize all meaningful data fields into a standardized multi-level JSON document. Simultaneously, the normalization unit performs data cleaning on the original data, including removing duplicate data packets, redundant or invalid fields, correcting format misalignments caused by transmission errors, and filling in missing fields with default values. Addressing the practical needs of privacy protection, the normalization unit integrates a token-based desensitization mechanism, performing irreversible encrypted replacement on sensitive data such as user IDs, authentication credentials, mobile phone numbers, email addresses, and bank cards. A token index is also built, ensuring that data that could be linked between different API calls remains traceable, but the sensitive content itself can never be restored. All de-identified, standardized, and structurally complete API traffic data undergo field normalization and numerical standardization to ensure data distribution consistency across different calling environments. The data verification module verifies the format and structure consistency of each API call, and all verified data is distributed and pushed to backend core modules such as security analysis, feature extraction, and anomaly detection to form a standardized API call data flow.

[0031] Optionally, the normalized unit is specifically used for: The raw API traffic data is formatted to obtain API type identification information including REST, GraphQL, and SOAP. Based on the API type identification information, the original API traffic data is converted into a unified format to obtain unified format API data. Then, the unified format API data is cleaned to obtain cleaned API data. Sensitive fields in the cleaned API data are tokenized, replacing sensitive information such as user identifiers and authentication credentials with irreversible token values, while preserving the correlation between data, resulting in privacy-protected API data. The privacy-protected API data is processed to standardize the fields, resulting in standardized API data. Then, the standardized API data is processed for data splitting to obtain normalized API call data.

[0032] Specifically, the system automatically identifies the format of raw API traffic data. Through multiple methods, including protocol header analysis, payload feature extraction, and key field rule matching, the system determines the protocol type of each data entry. For example, it efficiently and accurately identifies the protocol attributes of URL parameters and verbs in the REST style, complex queries and field projections in GraphQL requests, and nested XML message bodies in SOAP protocols, automatically generating API type identification information. This identification includes the protocol name and can also distinguish in detail the version, method type, parameter style, and structural nesting level. Based on the API type identification, an adaptation and conversion mechanism is automatically initiated. For REST traffic, parameters such as URL, Path, Query, and Body are parsed to extract all key-value pairs and request methods, mapping them to an internal standard JSON structure. For GraphQL requests, the query string, variable parts, and response content are parsed using a syntax tree, expanding complex query relationships and data dependencies into a structured document. For SOAP protocols, the XML content is tagged and traversed at multiple levels to extract request methods, input and output parameters, namespaces, and data types, then converted into a unified nested JSON format. A unified format API data is obtained through a protocol-adaptive multi-template mapping mechanism. This unified format API data undergoes data cleaning. Duplicate detection and deduplication are performed, automatically removing redundant traffic generated by network fluctuations, retransmissions, and disconnections / reconnections to ensure data uniqueness. Then, anomalies such as missing structures, misaligned fields, illegal characters, and incorrect formatting are corrected using techniques like field completion, regular expression correction, and nested expansion to repair and correct non-standard data. Based on this, useless fields, placeholder content without practical business meaning, and test parameters left over from development are removed, eliminating impurities, reducing data redundancy, and improving data purity and analysis efficiency. During the data cleaning process, any suspected errors or potential risks are recorded and marked for manual review or machine learning feedback for optimization, continuously improving data quality. After the cleaning process is complete, sensitive fields in the cleaned API data are tokenized. Based on a sensitive information detection model, the system automatically locates privacy fields such as user identifiers, login credentials, mobile phone numbers, email addresses, and bank card numbers, and encrypts and replaces these sensitive information using a high-strength irreversible hash algorithm (such as SHA256 or a dedicated token mapping service). Each replaced sensitive field is replaced with a unique token, and a token mapping table is maintained to maintain the correspondence between the original fields and tokens. This mapping table is only stored in a secure and trusted environment. This step yields privacy-protected API data. The privacy-protected API data then undergoes field standardization processing to obtain field-standardized API data. Based on a unified data dictionary and standard field templates, the field names, types, and value ranges of all API data are renamed, normalized, and type-validated.For example, fields with the same meaning but different names in different team interfaces (such as "userid", "user_id", "userId") are uniformly mapped to "user_id", and numeric, boolean, and timestamp fields are converted according to unified rules to eliminate type confusion and value ambiguity caused by inconsistent development specifications. At the same time, special cases such as nested structures, array elements, and optional parameters are standardized and expanded to ensure that fields at any level can be accessed in a rule-based manner. Standardized API data is automatically streamed according to business needs and analytical purposes to obtain standardized API call data. Based on the data's temporal characteristics, call context, and structural content, the API data is divided into behavioral analysis streams and structural analysis streams, used for behavioral anomaly detection and structural dependency modeling, respectively. Furthermore, it is sliced ​​and grouped according to multi-dimensional tags such as business modules, user groups, endpoint interfaces, and time windows to achieve efficient batch processing and task priority scheduling.

[0033] Optionally, the feature extraction module 120 also includes: The partitioning unit is used to divide the standardized API call data into behavioral flow data and structure flow data. Behavioral flow data contains the temporal and frequency characteristics of API calls, while structure flow data contains the parameter and structural characteristics of API requests and responses. The temporal feature extraction unit is used to extract temporal features from behavioral stream data through a temporal convolutional network, thereby extracting the temporal features of API behavior. The parameter dependency processing unit is used to construct an API parameter dependency graph based on structured flow data, and process the API parameter dependency graph through a graph neural network to obtain API structural relationship features. The multi-scale feature analysis unit is used to input the temporal features of API behavior into the multi-scale receptive field structure for multi-scale feature analysis to obtain multi-scale API behavior features, and to perform message passing calculation on the API structure relationship features to obtain enhanced API structure features. The interactive fusion unit is used to interactively fuse multi-scale API behavioral features and enhanced API structural features through a feature mapping matrix to obtain API behavioral features and API structural features.

[0034] Specifically, the segmentation unit systematically deconstructs the API call data after pre-normalization. By scanning features and classifying attributes of the data content of each API call, it integrates time-related aspects of the API behavior, such as request timestamps, call order, frequency, intervals, and periodicity, into behavioral stream data. Meanwhile, it extracts the specific parameter fields, parameter values, nested structures, data types, and return structures involved in each request and response into structured stream data. The temporal and frequency characteristics of the behavioral stream data reflect the regularity, suddenness, and potential anomalies of API calls in the business process, while the parameters and structural features of the structured stream data reveal the complex relationships within the interface itself in terms of data constraints, field dependencies, and business logic. Based on this, the temporal feature extraction unit performs deep temporal modeling on the segmented behavioral stream data. This unit's core employs a temporal convolutional network, using sliding window convolution processing on the API call sequence to capture local trends in API calls while also considering complex temporal relationships such as global periodic fluctuations and long-distance dependencies. During convolution, through multi-layer stacking and variable receptive field windows, it automatically learns behavioral features at different scales. The temporal feature extraction unit outputs a high-dimensional temporal feature vector representing the dynamic behavior of API calls. Simultaneously, the parameter dependency processing unit performs structural modeling on the structured flow data. By parsing parameter fields, nesting levels, and dependency paths in API requests and responses, it maps all parameters to graph nodes and injects meta-attribute information such as parameter type, length, and value range into each node. Then, based on the reference relationships, conditional dependencies, and business logic bindings between parameters, it abstracts graph edges, forming a multi-attribute, polygonal API parameter dependency graph. This graph can accurately model the various inherent logics and dependency paths existing at the structural level of the API interface. The parameter dependency processing unit inputs the parameter dependency graph into a graph neural network architecture. Through multiple rounds of message passing and node embedding learning, the system efficiently aggregates the contextual features of nodes, captures the semantic consistency of the global structure and the sensitive relationships of local dependencies, and outputs a high-dimensional vector representation of the API structural relationships. The multi-scale feature analysis unit performs multi-dimensional enhancement and semantic refinement on both temporal and structural features. For API behavioral temporal features, the multi-scale receptive field structure, by setting different convolutional kernel sizes and layers in parallel, enables the model to simultaneously perceive behavioral patterns of short-term intense fluctuations and long-term smooth changes, thereby accurately identifying diverse risk behaviors such as high-frequency attacks, periodic anomalies, or low-frequency interleaving. For API structural relationship features, the multi-scale feature analysis unit, through multi-layer aggregation and message passing mechanisms within the graph neural network, performs global-local semantic alignment on node embeddings, enabling nodes in the parameter-dependent graph to aggregate long-distance structural information, while strengthening the identification ability of local sensitive paths, outputting an enhanced structural feature vector containing rich structural context and global dependencies. The interactive fusion unit establishes a bidirectional interaction mechanism between behavioral features and structural features through a feature mapping matrix.Multi-scale API behavioral features and enhanced API structural features are input into a feature mapping space, respectively. Through matrix mapping and learnable weight adjustment, information complementarity and fusion are achieved. For example, behavioral features dynamically adjust their weights and sensitivities based on the contextual information of structural features, enabling behavioral pattern analysis to go beyond mere temporal fluctuations and incorporate joint inferences based on structural changes. Meanwhile, structural features, combined with call frequency and abnormal timing within the behavioral flow, determine the actual activity level and risk intensity of parameter dependencies. The final output fused features possess both dynamic behavioral and static structural expressive capabilities, and exhibit attack generalization and business adaptability.

[0035] Optionally, the parameter dependency processing unit is specifically used for: Extract parameters from the structured stream data to obtain the API parameter set; Based on the API parameter set, each parameter is mapped to a uniquely identified graph node, and each node is assigned attribute information including parameter type, length limit, and value range, thus obtaining the API parameter node set; Dependency analysis is performed on the API parameter node set to obtain the API parameter edge set, and an API parameter dependency graph is constructed based on the API parameter node set and the API parameter edge set. A graph convolutional network is used to extract features from the API parameter dependency graph and perform multi-round message passing iterations to compute the API parameter node embedding representation; Graph pooling is performed on the embedded representation of API parameter nodes to merge node representations with similar structural features and generate API structural relationship features.

[0036] Specifically, parameter extraction is performed on the structured stream data, parsing the top-level fields in the API request and response bodies, and recursively expanding all nested objects, array elements, and dynamically generated parameter combinations. Through tree-like recursive traversal and pattern recognition algorithms, the complete parameter set belonging to this API interaction is extracted. This parameter set covers all input and output parameters of the API interface that could potentially be exploited or affect security logic. Based on parameter extraction, each parameter in the set is abstracted as a uniquely identified graph node. Attribute information is assigned to each node, such as the parameter's data type (integer, string, boolean, enumeration, structure, array, etc.), length or size constraints (e.g., maximum length, minimum length, array length, string constraints), range of possible values ​​(e.g., integer range, enumeration set, regular expression constraints), and security-related constraints such as whether it is required, whether it is a primary key, and whether it depends on the values ​​of other fields. This attribute information is encoded into a high-dimensional attribute vector, which, along with the node's identity, becomes the input features for subsequent graph neural network learning. Through this step, the API parameter node set is obtained. Dependency analysis is performed on the API parameter node set to obtain the API parameter edge set. Dependency analysis is based on structural declarations in API interface documentation, statistical co-occurrence relationships in actual business logs, and syntactic or business logic coupling between fields. For example, references between child and parent objects, type consistency of elements in an array, and the control of parameter B over the value range of parameter A are automatically discovered through a combination of static rule matching, data flow analysis, and machine learning-assisted induction. Each edge contains the direction, strength, or type of dependency (e.g., value range dependency, type dependency, existence dependency, conditional dependency, derived dependency, etc.), and the modeled edge set vividly expresses the structural constraints and logical connections of the entire parameter space. Based on the API parameter node set and parameter edge set, an API parameter dependency graph is constructed, reproducing the static structure of API input and output at the parameter level and mapping the business logic and security-sensitive paths between parameters, enabling the structured discovery and representation of complex structural risks and multi-step attacks. The API parameter dependency graph is then input into a graph convolutional network for deep feature extraction. The graph convolutional network, through multi-round message passing and feature aggregation mechanisms, fuses and transforms the attribute features of each parameter node with the attributes of all its neighboring nodes. In each iteration, nodes retain their original attribute information and integrate the latest features of all directly connected nodes. After multiple recursive layers, the final embedding vector of each node contains both local parameter semantics and the dependency context of the global structure, making it suitable for detecting structural anomalies such as parameter pollution, broken dependency chains, and data type mismatches. Graph convolutional networks, by introducing edge weights, hierarchical induction, and specific nonlinear activation functions, significantly enhance their ability to model complex, dynamic, and heterogeneous API parameter dependency structures. After several rounds of message passing, all parameter nodes obtain high-dimensional embedding representations that reflect their structural context.Graph pooling is performed on the API parameter node embeddings. Leveraging structural and semantic similarities among node embeddings, node representations with similar functions, consistent constraints, belonging to the same business branch, or frequently changing collaboratively are merged into aggregated nodes. Methods include clustering reduction based on the node embedding space, structural isomorphic folding (compressing recurring parameter structures into a single representation), or weighted averaging based on graph attention mechanisms to assign higher weights to key nodes. The graph-pooled node representations are then aggregated into API structural relationship features.

[0037] Optionally, module 130 is specifically used for: The encoder in the autoencoder network model is used to perform time-series reconstruction calculations on API behavior features to obtain an API behavior encoded representation. The API behavior encoding representation is input into the decoder in the autoencoder network model for sequence reconstruction, and the sequence reconstruction result is obtained. The error matrix between the API behavior features and the sequence reconstruction result is calculated to obtain the API behavior reconstruction error data. Kernel density estimation is performed on the API behavior reconstruction error data to construct a normal behavior probability distribution model for each API endpoint. Dynamic thresholds are set according to the differences in API call patterns in different time periods to obtain the API behavior safety baseline. Learn parameter syntax rules from API structural features to extract a set of API parameter constraints containing the type, value range, and dependencies of API parameters; Frequent subgraph mining is performed based on the API parameter constraint set to extract common structural patterns and dependencies between API parameters, thereby obtaining the API structural security baseline.

[0038] Specifically, in the API behavior security modeling stage, the historical behavior stream data of each API endpoint is serialized and encoded into a time series vector based on features such as timestamp, call order, and frequency. Each time slice contains multi-dimensional behavioral features of this API call, such as access time, interval, parameter size, response latency, and status code distribution. This API behavior encoding representation is input into the decoder of the autoencoder network model. The encoder part uses multi-layer nonlinear mapping to reduce the dimensionality of the original high-dimensional temporal features, compressing the complex behavior sequence into a low-dimensional latent space API behavior encoding representation. This latent encoding effectively extracts key behavioral patterns and anomaly sensitivities from the time series data and achieves adaptive learning for common business fluctuations, periodic access, and normal high concurrency scenarios through network training. The API behavior encoding output from the encoder is input into the decoder part of the autoencoder. The decoder, based on the learned feature distribution and internal parameters, restores the low-dimensional encoding to a reconstruction result consistent with the original behavior sequence. Through this process, the model actually simulates the typical behavioral trajectory and temporal changes of the API under normal business conditions. To quantify the model's reconstruction capabilities and anomaly detection, a step-by-step comparison is performed across all dimensions and time points between the original API behavior characteristics and the decoded output. An error matrix is ​​calculated, where each element represents the model's reconstruction error for a specific behavior dimension at a given time point. This error characterizes the degree of deviation between the current API behavior and the model's perceived "normal pattern." All error vectors are aggregated and kernel density estimation analysis is performed. Using nonparametric probability density modeling, the probability distribution of reconstruction errors for each API endpoint under historical normal business scenarios is fitted. This probability distribution serves as a statistical benchmark describing the fluctuation range of normal API endpoint behavior. For various scenarios such as different time periods, peak and off-peak business hours, weekdays and holidays, and day and night, the system automatically partitions and fits the error distribution, establishing a dedicated probability distribution model for each segmented business cycle. Based on the distribution analysis results, dynamic detection thresholds are set. These thresholds adaptively adjust with time periods, business pressure, and access patterns, ensuring that the security baseline not only covers the entire fluctuation range of normal API behavior but also reduces the risk of false positives and false negatives due to business adjustments or changes in the external environment. Based on the aforementioned kernel density distribution and dynamic thresholds, a dedicated API behavior security baseline is established for each API endpoint. Simultaneously, to establish a security baseline for the API structure, parameter syntax rules are learned from the API structure characteristics. All parameters involved in the interface are automatically summarized from historical structure stream data, and for each parameter, statistical distribution of type (e.g., integer, boolean, string, array, object), common value ranges (e.g., upper and lower bounds of intervals, valid enumerations, regular expressions, etc.), and dependency constraints (e.g., "if parameter A exists, B must be filled," "the value of B depends on A," etc.) are formed, creating a set of syntax rules for API parameters. This set of parameter syntax rules describes the static constraints of single parameters and systematically models the complex relationships such as combinational logic and conditional dependencies between multiple parameters.Based on a set of parameter constraints, a frequent subgraph mining algorithm is used to analyze the parameter structure in the API call history. Frequent subgraph mining automatically counts and extracts high-frequency co-occurrence, structurally repetitive, and semantically consistent parameter combinations and dependency patterns from the parameter dependency graphs of a large number of historical API request and response samples. These high-frequency structures include nested fields, composite objects, circular dependencies, or cross-request conditional references and business flow links. Through an efficient graph pattern mining algorithm, the most representative structural combinations of the interface in actual business operations are captured, automatically identifying stable interface backbones, key parameter paths, and vulnerable sensitive dependencies. This set of frequent subgraphs is further summarized, redundancy removed, and semantically aggregated to form an API structure security baseline.

[0039] Optionally, the anomaly detection module 140 is specifically used for: A multidimensional time-series feature vector is constructed based on real-time API call data, and the Mahalanobis distance between the multidimensional time-series feature vector and the historical normal pattern distribution in the API behavior safety baseline is calculated to obtain the behavior abnormality score. The parameter structure of real-time API requests and responses is recursively traversed and checked to verify whether the type, length, and value range of each parameter conform to the constraints of the structure syntax tree in the API structure security baseline, and to obtain a structure anomaly score. Based on the API type identification information and the context of the current API call, weights are assigned to the behavioral anomaly score and the structural anomaly score to obtain a comprehensive anomaly score. The overall anomaly score is graded and determined to obtain the first anomaly determination result; For API calls identified as suspicious in the first anomaly determination result, perform a deep inspection, place the current API call in the context sequence of the most recent N calls for comprehensive evaluation, apply the context-aware determination model to perform a second evaluation of the suspicious call, and obtain the second anomaly determination result; Based on the second anomaly determination result, an anomaly event record is generated, which includes the anomaly type, anomaly score, triggering rules, relevant API call context information, and timestamp.

[0040] Specifically, based on real-time API call data, preprocessing and feature engineering modules are used to map the core behavioral attributes of each API call at the current moment (including request arrival time, business operation sequence, call frequency, request interval, parameter size, status code type, average response latency, context activity, historical sequence pattern, etc.) into a set of multi-dimensional temporal feature vectors. These high-dimensional temporal feature vectors are then compared with the API behavior safety baseline previously constructed using autoencoders and kernel density estimation methods. This safety baseline stores the probability distribution and related statistical parameters of various API behavior characteristics under historical normal business cycles. To quantify the deviation of real-time behavior from the normal distribution, Mahalanobis distance is used as a multi-dimensional distance metric. Mahalanobis distance automatically eliminates dimensional differences between different feature components and fully considers the correlation between features. Through this metric, complex behavioral patterns that are not significant in a single dimension but are abnormally obvious under multi-dimensional feature combinations are identified, thus outputting a behavior anomaly score characterizing the degree of abnormality in the current API call behavior. The larger this score, the more significant the deviation of the real-time API behavior characteristics from the historical baseline. Simultaneously, a recursive parameter compliance check is performed on the structure of each real-time API call. Based on a pre-learned and modeled structure syntax tree within the API structure security baseline, a depth-first traversal is performed on each parameter field in the request and response bodies. This rigorously verifies all constraints, including parameter data type (e.g., integer, boolean, enumeration, structure, array), length limits (e.g., maximum / minimum length, number of array elements), value range (e.g., numerical intervals, regular expressions, valid enumerations), and dependencies (e.g., conditional existence, value dependence on other fields). When a field is found to violate the syntax constraints agreed upon in the structure baseline, a structural anomaly score is accumulated and weighted according to the parameter's security sensitivity level and the severity of the violation. The resulting structural anomaly score comprehensively reflects the structural integrity and business compliance of the API request. A higher structural anomaly score indicates a greater likelihood of the current call being affected by structural security threats such as parameter injection, data pollution, and dependency chain disruption. Once the system obtains behavioral and structural anomaly scores, it assigns dynamic weights to these scores based on API type identification information (such as REST, GraphQL, SOAP, etc.) and the context of the current API call (including user identity, business operation chain, operation time period, system load status, etc.). The weight allocation mechanism considers both the security sensitivity of the interface itself and its historical risk distribution, as well as the relative importance of behavioral and structural anomalies in the current business scenario. This ensures that the overall anomaly score accurately reflects the overall threat level of the API call under multi-dimensional risks. Through this mechanism, the system can dynamically adapt its detection strategy to different business peaks, changes in interface sensitivity, and frequent business operation switching, improving the accuracy and flexibility of actual protection.The comprehensive anomaly score is input into the anomaly classification and judgment module. Based on historical data distribution and dynamic business thresholds, the system categorizes all API calls into three main categories: "normal," "high-risk," and "suspicious." Anomaly calls that significantly deviate from the baseline are marked as high-risk events, triggering automated blocking, alarms, and emergency responses. For suspicious API calls in the gray area, where their safety cannot be clearly determined, the system further initiates a deep inspection process. During the deep inspection phase, the current API call is incorporated into the context sequence of the N most recent API calls. Using context-aware judgment models (such as RNNs based on sequence modeling, attention mechanisms, and causal inference), the system comprehensively analyzes the logical consistency, temporal trends, and anomaly correlations between suspicious calls and historical behavior chains. This reveals complex threats such as multi-step attacks, low-frequency bypasses, and slow penetrations that are difficult to detect with isolated calls, reducing false positive rates and improving the overall accuracy and robustness of detection. A second anomaly judgment result is output for suspicious calls through a context-enhanced judgment model. Based on the second anomaly determination result, a structured anomaly event record is automatically generated. The record includes the anomaly type (such as behavioral anomaly, structural anomaly, and combined anomaly), anomaly score, trigger determination rules, relevant API call context information (such as associated session, business chain, operation history, and triggering user), determination timestamp, and other key metadata.

[0041] Optionally, the generation module 150 is specifically used for: The abnormal event records are mapped to a bounded space interval, and random noise following a Laplace distribution is added to form perturbation data. Boundary pruning is performed on the perturbation data to obtain privacy-preserving abnormal data. Temporal correlation analysis was performed on the privacy-protection anomaly data to obtain temporal correlation results, and spatial correlation analysis was performed on the privacy-protection anomaly data based on the API dependency graph to obtain spatial correlation results. Based on the extraction of API call behavior fingerprint features from privacy protection anomaly data, attacker association results are obtained. Furthermore, by querying the vulnerability knowledge graph, the privacy protection anomaly data is matched and analyzed with known vulnerabilities to obtain vulnerability association results. The time-dimensional correlation results, spatial-dimensional correlation results, attacker correlation results, and vulnerability correlation results are input into the behavior-structure hybrid model to classify abnormal events and obtain the attack classification results. API security incident reports are generated based on the attack classification results, and corresponding defense strategies are constructed based on the attack types and risk levels in the API security incident reports.

[0042] Specifically, privacy protection processing is performed on all detected abnormal event records. The structured abnormal event feature vectors (including behavioral anomaly scores, structural anomaly scores, API endpoints, context summaries, etc.) are mapped to a preset bounded space interval according to a security policy, meaning each feature value is restricted to the interval [a, b]. Random noise following a Laplace distribution is added to each abnormal event feature component within the bounded space, introducing a controllable ε-local differential privacy mechanism. This ensures that even if any single event is maliciously inferred, its true business-sensitive content cannot be reconstructed. If the disturbed data causes features to exceed the limits due to noise introduction, a clipping operation is used to forcibly limit all out-of-limit values ​​to the range [a, b], outputting privacy-protected abnormal data. Temporal correlation analysis is performed on the privacy-protected abnormal data. Using timestamps, API call order, and business context windows in the event records, combined with time series analysis and event sliding window clustering techniques, abnormal events of the same API endpoint, the same user, or the same operation type are chained and aggregated in the time dimension to capture patterns such as short-term high-density attack outbreaks, persistent abnormal changes, and concentrated risk outbreaks during peak business periods. By aggregating and segmenting abnormal events along a timeline, time-related threats such as timed attacks, slow penetration, and periodic replays are identified, outputting time-dimensional correlation results. Simultaneously, spatial threat correlation analysis is performed based on API dependency graphs. API dependency graphs reflect business call paths, permission inheritance, and data flow relationships between interfaces. By spatially projecting API endpoints and parameter dependency chains from privacy-preserving abnormal data, and combining this with the propagation paths and distribution density of abnormal events on the API dependency graph, the attacker's lateral movement, permission jumps, and resource interconnections within the system can be accurately located. Spatial correlation analysis can effectively reveal complex attack chains achieved through step-by-step lateral penetration, link traversal, and service interconnection, providing data support for the identification and blocking of distributed attacks, and outputting spatial correlation results. Based on the aforementioned privacy-preserving data, attacker behavior fingerprints are extracted and clustered for correlation. By encoding multi-dimensional data such as API call behavior sequences, parameter patterns, context, and feature sequences, behavioral fingerprint vectors are generated. Fingerprint clustering and similarity matching algorithms are then used to group abnormal events scattered across different times, spaces, and interfaces to a single attack source, enabling cross-session and cross-terminal attacker identification and tracing. This attacker correlation analysis can identify organized attack groups such as "wool parties," "automated attacks," and "botnets," and can be used to track the long-term, covert activities of individual attackers within the system. Parameter features, operation sequences, and call paths from privacy-protected abnormal data are matched with a vulnerability knowledge graph. This knowledge graph includes common API vulnerabilities (such as SQL injection, XSS, parameter pollution, privilege escalation, IDOR, and denial-of-service) and their typical attack patterns and exploit chains.By comparing semantic patterns and matching feature rules, the system determines whether anomalies are strongly correlated with known vulnerabilities, thus outputting vulnerability association results. The time-dimensional association results, spatial-dimensional association results, attacker association results, and vulnerability association results are input into a behavior-structure hybrid model for anomaly event classification. This model integrates behavioral analysis (such as anomaly scores, fingerprint similarity, and call trends) and structural analysis (such as parameter dependencies, call chain topology, and structural pattern anomalies). Through multi-layer neural networks and feature fusion layers, it performs unified attribution, association, and discrimination of various threat features, achieving multi-dimensional and multi-granular attack classification of anomalies. The model outputs attack classification results, clearly labeling key information such as attack type (e.g., SQL injection, authentication bypass, data tampering, abuse attacks, brute-force attacks, denial of service, etc.), impact scope, associated context, propagation path, and threat level. Based on the above attack classification results, the system automatically generates a standardized API security incident report. The report includes attack type, time, location, attacker and vulnerability information, and lists the attack path, affected interfaces, risk level, event triggering rules, context link, and recommended remedial measures. Based on the attack types and risk levels identified in the report, and considering business priorities and existing defense rules, API security defense strategies are dynamically constructed and adjusted. For example, parameter purification rules can be automatically deployed for SQL injection attacks, rate limits can be dynamically adjusted for brute-force attacks, and interface access permissions can be promptly restricted or call chains can be blocked in stages for lateral movement detection. All defense measures can be enabled as needed, flexibly combined, and their effectiveness continuously evaluated. The defense results and actual effects are fed back to the security incident analysis and baseline learning module, achieving a data-driven defense closed loop and model self-evolution, thereby improving the adaptive capabilities, intelligent response efficiency, and continuous evolution level of API security protection.

[0043] In this embodiment of the invention, a dual-branch feature extraction architecture can simultaneously capture the behavioral patterns and structural features of API calls. Information sharing between the two branches is achieved through a feature mapping matrix, effectively identifying cross-domain combined attacks and complex threat patterns. A high-performance full-data acquisition and standardized preprocessing mechanism ensures the preservation of complete API interaction details, solving the problem of ambiguity in security event reconstruction. Token mapping technology balances data privacy protection and analytical value. A multi-task learning model significantly enhances feature extraction capabilities, effectively distinguishing between abnormal API call behavior and API structural vulnerabilities even under limited historical data constraints, greatly improving model generalization ability. A self-supervised security baseline learning technique eliminates the need for manually labeled anomaly samples. Through dynamic threshold adjustment of adaptive time windows and parameter syntax rule learning, a security baseline more closely aligned with actual API usage is established. A dual-dimensional anomaly detection and multi-level joint judgment mechanism, combined with context-aware evaluation, effectively reduces the false positive rate. In particular, the deep inspection process accurately determines boundary conditions, significantly improving detection accuracy. A bidirectional bounded perturbation processing mechanism ensures ε-local differential privacy while limiting noise impact to a controllable range, balancing data privacy protection and analytical accuracy, enabling security analysis to be completed in a single communication round. Multi-dimensional security event correlation analysis forms a complete attack chain view, accurately classifies attack types through a behavior-structure hybrid model, and correlates them with known vulnerability databases to generate targeted defense strategies and security hardening recommendations. A defense effectiveness verification mechanism and dynamic updates to the security baseline form a closed-loop feedback system, enabling the entire API security monitoring and analysis system to continuously evolve and effectively address ever-changing API security threats.

[0044] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the systems and units described above can be referred to the corresponding process in the aforementioned system embodiments, and will not be repeated here.

[0045] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or 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 system described in the various embodiments of this application. 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.

[0046] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. An API security monitoring and analysis system, characterized in that, include: The data acquisition module is used to preprocess the inbound and outbound traffic of the API gateway to obtain standardized API call data. The feature extraction module is used to extract API behavior features and API structure features based on the standardized API call data; A module is established to establish an API behavior security baseline and an API structure security baseline based on the API behavior characteristics and the API structure characteristics. Anomaly detection module is used to perform two-dimensional anomaly detection on the API behavior security baseline and the API structure security baseline, and generate anomaly event records; The generation module is used to perform security event correlation analysis based on the abnormal event records, and generate API security event reports and defense strategies.

2. The API security monitoring and analysis system according to claim 1, characterized in that, The acquisition module also includes: The monitoring unit is used to deploy a distributed data collector at the front end of the API gateway to monitor the communication channel of the API gateway and obtain API communication data streams. The interception unit is used to intercept data packets in the API communication data stream and extract target API interaction records containing request system, URL path, request header, request body, status code, response body, response time and client identifier. The grouping unit is used to store the target API interaction records into a temporary buffer and group them according to API endpoint, timestamp and session identifier to form the original API traffic data; The normalization unit is used to perform normalization preprocessing on the raw API traffic data to obtain normalized API call data.

3. The API security monitoring and analysis system according to claim 2, characterized in that, The normalization unit is specifically used for: The original API traffic data is formatted to obtain API type identification information including REST, GraphQL, and SOAP. Based on the API type identification information, the original API traffic data is converted into a unified format to obtain unified format API data, and the unified format API data is cleaned to obtain cleaned API data. Sensitive fields in the cleaned API data are tokenized, replacing sensitive information such as user identifiers and authentication credentials with irreversible token values, while preserving the correlation between data, resulting in privacy-protected API data. The privacy-protected API data is processed to standardize fields to obtain standardized API data, and the standardized API data is then processed for data splitting to obtain normalized API call data.

4. The API security monitoring and analysis system according to claim 1, characterized in that, The feature extraction module further includes: A partitioning unit is used to divide the standardized API call data into behavioral flow data and structural flow data. The behavioral flow data includes the temporal and frequency characteristics of API calls, and the structural flow data includes the parameter and structural characteristics of API requests and responses. The temporal feature extraction unit is used to extract temporal features from the behavior stream data through a temporal convolutional network, thereby extracting API behavior temporal features. The parameter dependency processing unit is used to construct an API parameter dependency graph based on the structured flow data, and process the API parameter dependency graph through a graph neural network to obtain API structural relationship features. The multi-scale feature analysis unit is used to input the API behavior temporal features into the multi-scale receptive field structure for multi-scale feature analysis to obtain multi-scale API behavior features, and to perform message passing calculation on the API structure relationship features to obtain enhanced API structure features. The interactive fusion unit is used to interactively fuse the multi-scale API behavior features and the enhanced API structure features through a feature mapping matrix to obtain API behavior features and API structure features.

5. The API security monitoring and analysis system according to claim 4, characterized in that, The parameter dependency processing unit is specifically used for: Parameters are extracted from the structured stream data to obtain the API parameter set; Based on the API parameter set, each parameter is mapped to a uniquely identified graph node, and each node is assigned attribute information including parameter type, length limit, and value range, thus obtaining the API parameter node set; Dependency analysis is performed on the API parameter node set to obtain the API parameter edge set, and an API parameter dependency graph is constructed based on the API parameter node set and the API parameter edge set. A graph convolutional network is used to extract features from the API parameter dependency graph and perform multiple rounds of message passing iterations to calculate the API parameter node embedding representation. The embedded representation of the API parameter nodes is subjected to graph pooling, and node representations with similar structural features are merged to generate API structural relationship features.

6. The API security monitoring and analysis system according to claim 1, characterized in that, The establishment module is specifically used for: The encoder in the autoencoder network model is used to perform time-series reconstruction calculation on the API behavior features to obtain the API behavior encoded representation. The API behavior encoding representation is input into the decoder in the autoencoder network model for sequence reconstruction to obtain the sequence reconstruction result. The error matrix between the API behavior feature and the sequence reconstruction result is calculated to obtain API behavior reconstruction error data. Kernel density estimation is performed on the API behavior reconstruction error data to construct a normal behavior probability distribution model for each API endpoint. Dynamic thresholds are set according to the differences in API call patterns in different time periods to obtain the API behavior safety baseline. The API structural features are subjected to parameter syntax rule learning to extract a set of API parameter constraints containing the type, value range and dependency relationship of API parameters; Based on the API parameter constraint set, frequent subgraph mining is performed to extract common structural patterns and dependencies between API parameters, thereby obtaining the API structural security baseline.

7. The API security monitoring and analysis system according to claim 1, characterized in that, The anomaly detection module is specifically used for: A multidimensional time-series feature vector is constructed based on real-time API call data, and the Mahalanobis distance between the multidimensional time-series feature vector and the historical normal pattern distribution in the API behavior safety baseline is calculated to obtain the behavior abnormality score. The parameter structure of real-time API requests and responses is recursively traversed and checked to verify whether the type, length, and value range of each parameter conform to the constraints of the structure syntax tree in the API structure security baseline, and a structure anomaly score is obtained. Based on the API type identification information and the context of the current API call, a weighted allocation is performed on the behavioral anomaly score and the structural anomaly score to obtain a comprehensive anomaly score; The comprehensive anomaly score is graded and determined to obtain the first anomaly determination result; A deep inspection is performed on the API calls identified as suspicious in the first anomaly determination result. The current API call is placed in the context sequence of the most recent N calls for comprehensive evaluation. The context-aware determination model is applied to perform a second evaluation on the suspicious call to obtain the second anomaly determination result. Based on the second anomaly determination result, an anomaly event record is generated that includes the anomaly type, anomaly score, triggering rules, relevant API call context information, and a timestamp.

8. The API security monitoring and analysis system according to claim 1, characterized in that, The generation module is specifically used for: The abnormal event records are mapped to a bounded space interval, and random noise following a Laplace distribution is added to form perturbation data. Boundary pruning is performed on the perturbation data to obtain privacy-preserving abnormal data. Temporal correlation analysis is performed on the privacy-protected anomaly data to obtain temporal correlation results, and spatial correlation analysis is performed on the privacy-protected anomaly data based on the API dependency graph to obtain spatial correlation results. Based on the API call behavior fingerprint features extracted from the privacy protection anomaly data, attacker association results are obtained. Furthermore, by querying the vulnerability knowledge graph, the privacy protection anomaly data is matched and analyzed with known vulnerabilities to obtain vulnerability association results. The time-dimensional correlation results, the spatial-dimensional correlation results, the attacker correlation results, and the vulnerability correlation results are input into the behavior-structure hybrid model for abnormal event classification to obtain the attack classification results. An API security incident report is generated based on the attack classification results, and a corresponding defense strategy is constructed based on the attack type and risk level in the API security incident report.

Images