API interface security protection method based on anomaly detection

Abstract

The invention relates to the technical field of security protection, in particular to an API (Application Program Interface) security protection method based on anomaly detection, which comprises the following steps of: based on a received API request, analyzing the API request, extracting a request source network address and a target API calling instruction, and carrying out source authenticity verification and instruction validity judgment. According to the method, the initial security context is established by analyzing the source network address and the interface calling instruction of the API request in combination with the timestamp and the request type, so that the pre-modeling of the environment state of each request is realized, and the basic credibility of the request can be judged immediately before the request is subjected to deep business processing. On the basis, a sequence mode of the request load is combined with a parameter boundary for comparison, the behavior deviation degree is used as a reference item, interface sensitivity information in the context is introduced to complete quantitative judgment on the risk level, and a judgment result has dynamic adaptability and structural relevance.

Description

Technical Field

[0001] The present invention relates to the technical field of security protection, and particularly relates to an API interface security protection method based on anomaly detection. Background Art

[0002] The API interface security protection method is to identify and respond to abnormal or risky access requests by constructing an API request behavior feature model and combining real-time anomaly detection means, so as to realize dynamic protection management of abnormal calls, malicious attacks, token abuse and other behaviors that the API interface may suffer during operation.

[0003] Although the prior art already has the ability to intercept risks based on behavior models and anomaly detection, its processing process mostly focuses on static identification and real-time comparison of abnormal request behaviors, lacking global tracking of the API request context state, resulting in fragmentary and out-of-focus behavior judgment. Since the evolution process of the source reputation changing with time and request type cannot be recorded, it is difficult to dynamically adjust its trust level according to the historical interaction state of the requester, and thus the risk of privilege abuse is likely to accumulate during multiple medium and low-risk accesses. Therefore, improvements are needed. Summary of the Invention

[0004] The purpose of the present invention is to solve the disadvantages existing in the prior art, and to propose an API interface security protection method based on anomaly detection.

[0005] To achieve the above purpose, the present invention adopts the following technical solution, an API interface security protection method based on anomaly detection, including the following steps:

[0006] Based on the received API request, parse the API request to extract the source network address of the request and the target API interface call instruction, perform source authenticity verification and instruction validity judgment, and establish an initial API request security context for the API request in combination with the current timestamp information and request type information;

[0007] Based on the initial API request security context and the payload data of the API request, perform sequence pattern matching and request parameter boundary check, determine the difference between the current request payload data and the preset security baseline, obtain the request behavior pattern deviation degree, and based on the request behavior pattern deviation degree, in combination with the target API interface sensitivity information in the initial API request security context, perform a security protection risk operation to generate an API call risk assessment result;

[0008] Based on the API call risk assessment result and the validity period status of the current access token, calculate the remaining valid time of the access token, generate a recommended value for adjusting the token validity period, and based on the recommended value for adjusting the token validity period, decide whether to shorten or immediately revoke the current access token, and obtain a dynamic access token update instruction;

[0009] Based on the API call risk assessment result, update the reputation of the request source in the initial API request security context, and combine the criticality of the target API interface to generate an updated request source reputation status. Based on the updated request source reputation status, readjust the upper limit of the call frequency and establish adjusted API access authorization parameters.

[0010] Preferably, the step of obtaining the initial API request security context is as follows:

[0011] Based on the received API request, extract the original message content fields in the API request, parse the request source network address field and the target API interface call instruction field in the original message content fields, verify whether the request source network address field conforms to the trusted address format specification, and determine whether the target API interface call instruction field matches the registered set of valid interface instructions to obtain the request source authenticity verification result and the instruction validity judgment result;

[0012] Based on the request source authenticity verification result and the instruction validity judgment result, call the timestamp information field and the request type information field in the API request, and combine and construct a structured information unit containing the request source network address field, the target API interface call instruction field, the timestamp information field, and the request type information field to form a basic structured request element set;

[0013] Based on the basic structured request element set, combine the request source authenticity verification result and the instruction validity judgment result, integrate all structured fields into a unified format of security context data, and generate an initial API request security context.

[0014] Preferably, the step of obtaining the deviation degree of the request behavior pattern is as follows:

[0015] Based on the initial API request security context, extract all resolvable structured key-value pairs in the API request payload data field, identify the numerical type fields bound to the keys one by one, and classify and group the numerical type fields according to their respective business function paragraphs to form a structured parameter section set;

[0016] According to the set of structured parameter sections, extract the current numerical values of all fields in each parameter section as the current request parameter values, match the reference values of the corresponding fields in the historical security baseline of the target API interface, determine whether the difference between the field values and the reference values exceeds the allowable deviation range, count the number of fields with over-limit deviation values in each parameter section, record each section and the number of fields that trigger exceptions, and calculate the time difference by combining the request timestamp of this section and the most recent call time of the target API interface to form a request load boundary offset analysis set;

[0017] Based on the request load boundary offset analysis set, calculate the deviation degree of the request behavior pattern.

[0018] Preferably, the steps for obtaining the API call risk assessment result are as follows:

[0019] Based on the deviation degree of the request behavior pattern, extract the target API interface field, request timestamp field, and request type field from the initial API request security context, count the historical call times of the current target API interface within 1800 seconds before the request is sent and record them as the call frequency parameter, and generate an API interface call frequency input set;

[0020] According to the API interface call frequency input set, calculate the API call risk score;

[0021] Based on the API call risk score, perform interval matching on the API call risk score, and map it to a risk level identifier according to the defined risk level table to generate an API call risk assessment result.

[0022] Preferably, the steps for obtaining the recommended value for adjusting the token validity period are as follows:

[0023] Based on the API call risk assessment result, extract the issued time field in the access token structure and the current system time field, calculate the difference between the issued time and the current system time as the used duration, and subtract the used duration from the total duration to obtain the remaining valid duration of the access token;

[0024] Based on the remaining valid duration of the access token, combine the API call risk assessment result to calculate the recommended value for adjusting the token validity period.

[0025] Preferably, the steps for obtaining the dynamic access token update instruction are as follows:

[0026] Based on the recommended value for adjusting the token validity period, compare the difference between the recommended value for adjusting the token validity period and the current remaining valid duration of the access token. If the recommended value for adjusting the token validity period is less than the current remaining valid duration of the access token, mark that there is a risk of early expiration of the current access token, otherwise mark it as a status that does not require processing, and generate an access token shortening requirement identifier;

[0027] Based on the access token shortening requirement identifier, determine whether the revocation condition is met. If the access token shortening requirement identifier has been triggered and the recommended value for adjusting the token validity period is lower than the allowed minimum available duration threshold, mark the current access token as revoked; otherwise, mark it as only requiring shortening, and generate an access token processing policy result.

[0028] Based on the access token processing policy result, if it is in the revoked state, issue a token termination instruction; if it is in the only requiring shortening state, issue a token remaining time reduction instruction, and generate a dynamic access token update instruction.

[0029] Preferably, the step of obtaining the updated request source reputation status is as follows:

[0030] Based on the API call risk assessment result, extract the request source network address field in the initial API request security context, and determine whether there is a historical risk record for the address. If there is and the current API call risk assessment result is marked as high risk, generate a request source risk behavior identifier.

[0031] Based on the request source risk behavior identifier, extract the criticality of the target API interface in the initial API request security context, and determine whether the interface belongs to the high criticality level. If it is of the high criticality level and the request source risk behavior identifier is in the triggered state, it is determined that the request source is in a high-sensitivity interface risk interaction state, and a request source risk interaction judgment result is generated.

[0032] Based on the request source risk interaction judgment result, update the request source reputation field in the initial API request security context. If the current judgment result is the high-sensitivity interface risk interaction state, mark the request source reputation field as a low reputation state; otherwise, mark it as a normal reputation state, and generate the updated request source reputation status.

[0033] Preferably, the step of obtaining the adjusted API access authorization parameters is as follows:

[0034] Based on the updated request source reputation status, determine whether the status is marked as a low reputation state. If it is in the low reputation state, set the request source as a restricted access subject; otherwise, set it as a normal access subject, and generate a request source access subject permission category identifier.

[0035] Based on the request source access subject permission category identifier, combined with the call frequency regulation rule, retrieve the maximum call frequency limit parameter for the corresponding access subject permission category from the call frequency regulation rule, and generate a call frequency upper limit adjustment result.

[0036] Based on the adjusted result of the call frequency upper limit, update the access frequency control field in the initial API request security context to generate adjusted API access authorization parameters.

[0037] Compared with the prior art, the advantages and positive effects of the present invention are as follows:

[0038] The present invention realizes the pre-modeling of the environmental state of each request by parsing the source network address of the API request and the interface call instruction, and establishing an initial security context in combination with the time stamp and the request type, which helps to immediately determine the basic credibility of the request before it delves into business processing. On this basis, by comparing the sequence pattern and parameter boundary of the request payload, and taking the behavior deviation degree as a reference item, the interface sensitivity information in the context is introduced to complete the quantitative judgment of the risk level, making the judgment result have dynamic adaptability and structural relevance. After the risk judgment, the remaining time of the access token is used as the actual operation and maintenance control object, and dynamic compression or revocation decisions are made on its duration according to the risk level, thereby realizing the permission scaling at the precision level. In addition, by updating the reputation status of the request source and integrating the key degree of the interface, the limit strategy of the call frequency changes dynamically, so as to avoid resource occupation of the system caused by short-term attacks or repeated high-frequency accesses. It enhances the active protection ability and access control flexibility of the system. Description of the Drawings

[0039] Figure 1 It is a step schematic diagram of the present invention. Detailed Embodiments

[0040] In order to make the objectives, technical solutions and advantages of the present invention clearer and more understandable, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0041] Please refer to Figure 1 , the present invention provides a technical solution, an API interface security protection method based on anomaly detection, including the following steps:

[0042] Based on the received API request, parse the API request to extract the source network address of the request and the target API interface call instruction, perform source authenticity verification and instruction validity judgment, and establish an initial API request security context for the API request in combination with the current time stamp information and the request type information;

[0043] Based on the initial API request security context and the payload data of the API request, perform sequence pattern matching and request parameter boundary checking, determine the difference between the current request payload data and the preset security baseline, obtain the request behavior pattern deviation degree, and based on the request behavior pattern deviation degree, combined with the sensitivity information of the target API interface in the initial API request security context, perform security protection risk calculation to generate the API call risk assessment result;

[0044] Based on the API call risk assessment result and the validity period status of the current access token, calculate the remaining valid time of the access token to generate a token validity period adjustment recommendation value. Based on the token validity period adjustment recommendation value, decide whether to shorten or immediately revoke the current access token to obtain a dynamic access token update instruction;

[0045] Based on the API call risk assessment result, update the request source reputation in the initial API request security context, and combined with the criticality of the target API interface, generate the updated request source reputation status. Based on the updated request source reputation status, readjust the upper limit of the call frequency and establish the adjusted API access authorization parameters.

[0046] The steps for obtaining the initial API request security context are as follows:

[0047] Based on the received API request, extract the original message content fields in the API request, parse the request source network address field and the target API interface call instruction field in the original message content fields, verify whether the request source network address field conforms to the trusted address format specification, and determine whether the target API interface call instruction field matches the registered set of valid interface instructions to obtain the request source authenticity verification result and the instruction validity judgment result;

[0048] Based on the request source authenticity verification result and the instruction validity judgment result, call the timestamp information field and the request type information field in the API request, and combine them to construct a structured information unit containing the request source network address field, the target API interface call instruction field, the timestamp information field, and the request type information field to form a basic structured request element set;

[0049] Based on the basic structured request element set, combined with the request source authenticity verification result and the instruction validity judgment result, integrate all structured fields into security context data in a unified format to generate the initial API request security context.

[0050] Specifically, based on the received API request, first locate and extract the message content field contained in the original message of the API request, which usually refers to the request body in an HTTP request (such as JSON or XML data in a POST or PUT request) or URL query parameters (such as in a GET request). Subsequently, perform structured parsing on the extracted message content field. For example, if the message content is in JSON format, use a JSON parser to convert it into a set of key-value pairs, and accurately identify and extract the "request source network address field" (for example, the client IP address obtained from the X-Forwarded-For in the HTTP header or the direct connection TCP / IP socket information) and the "target API interface call instruction field" (for example, the URI path in the HTTP request line, such as / api / v1 / users, and the HTTP method, such as GET). Then, perform authenticity verification on the extracted "request source network address field". This verification is based on a dynamically maintained "trusted address format specification", which integrates the legality check of IP addresses. For example, check whether it is in the standard IPv4 or IPv6 format and whether it belongs to the public IP address range assigned by IANA (Internet Assigned Numbers Authority). At the same time, compare it with an internally maintained IP address blacklist, which contains known malicious IP addresses, proxy server IP addresses, and IP addresses with a history of bad behavior. For example, a preset blacklist contains the IP address 192.0.2.100. If the value of the current request source network address field is 192.0.2.100, it is determined that the source is not authentic. If the request source IP address is a reserved private address such as 192.168.1.10 and the API is deployed on the public network, it may also be marked as not authentic unless specifically configured. Also, perform validity judgment on the extracted "target API interface call instruction field" by matching it with a "valid interface instruction set" pre-registered and stored in the system. This set clearly lists all the deployed and active API interface paths and their allowed combinations of HTTP methods. For example, the valid interface instruction set contains records {path: " / api / v1 / users", method: "GET"} and {path: " / api / v1 / orders", method: "POST"}. If the current request's target API interface call instruction is GET / api / v1 / products and / api / v1 / products is not defined in the set, or the request is POST / api / v1 / users but / api / v1 / users in the set only allows the GET method, it is determined that the instruction is invalid. Finally, based on the above verification and judgment processes, generate boolean request source authenticity verification results and instruction validity judgment results respectively.

[0051] Based on the verification result of the authenticity of the request source and the judgment result of the instruction validity generated in the previous step, first judge whether both of these results are "true", that is, the request source is considered to be authentic and the called API instruction is valid. Only when this condition is met, will the subsequent operations be continued; otherwise, the current process will be interrupted and recorded as an illegal or suspicious request. On the premise of confirming that the source is authentic and the instruction is valid, extract the "timestamp information field" and the "request type information field" from the metadata of the received API request or the parsed message content. For the "timestamp information field", it is usually expected to be a Unix timestamp representing the time when the request was initiated (the number of seconds or milliseconds since January 1, 1970, UTC) or a date-time string conforming to the ISO8601 standard, such as 2025-05-15T10:20:30Z, and perform a validity check on it, such as checking whether its deviation from the current server time is within a preset reasonable range. This range is set to 300 seconds, for example. This value is based on the statistical analysis of historical network transmission delay data, taking its 99th percentile value to accommodate network jitter and slight clock desynchronization between the client and the server. If the timestamp format is incorrect or the deviation exceeds 300 seconds, this timestamp may be marked as unreliable. For the "request type information field", this information may directly exist in a certain custom header of the request or the request body parameters and is used to identify the request classification at the business level, such as "query order", "create user", "update configuration", etc. Or when there is no explicit type field, it can be inferred and classified according to the HTTP method (such as GET, POST, PUT, DELETE) combined with the business meaning of the target API interface. For example, GET / api / v1 / users / {id} may be classified as a "user information query" request. Subsequently, combine the value of the verified and extracted request source network address field (for example, 203.0.113.45), the value of the target API interface call instruction field (for example, POST / api / v1 / data), the value of the verified and converted timestamp information field (for example, converted to a unified Unix timestamp 1747304430), and the value of the request type information field (for example, "data submission operation") to jointly construct a "structured information unit" with an internally predefined structure. This unit takes these information as its independent attributes or members, thus forming a basic set of structured request elements.

[0052] Based on the basic structured request element set formed in the previous step, and combined with the obtained request source authenticity verification result (a boolean value, e.g., true indicates authenticity) and the instruction validity judgment result (a boolean value, e.g., true indicates validity), start integrating this scattered information. Specifically, first define a standardized "security context data in unified format" structure, which is designed to encapsulate all the key information required at the initial stage of security assessment for an API request. This structure is usually designed as a dictionary or object containing multiple predefined keys. For example, it may contain the following keys: source_ip (from the request source network address field), target_api (from the target API interface call instruction field), timestamp (from the timestamp information field), request_type (from the request type information field), source_ip_valid (from the request source authenticity verification result), and api_instruction_valid (from the instruction validity judgment result). Then, fill the field values in the basic structured request element set, namely the request source network address, target API interface call instruction, timestamp information, and request type information, into the corresponding key-values in this "security context data in unified format" structure one by one. At the same time, assign the boolean value of the request source authenticity verification result to the source_ip_valid key and the boolean value of the instruction validity judgment result to the api_instruction_valid key. For example, a specific instance of the "security context data in unified format" may be: {"source_ip": "203.0.113.45", "target_api": "POST / api / v1 / data", "timestamp": 1747304430, "request_type": "data submission operation", "source_ip_valid": true, "api_instruction_valid": true}. Through such integration, all relevant structured fields and the preliminary verification judgment results are gathered into a unified data object, finally generating the initial API request security context.

[0053] The steps to obtain the deviation degree of the request behavior pattern are as follows:

[0054] Based on the initial API request security context, extract all the resolvable structured key-value pairs in the API request payload data field, identify the numerical type fields bound to the keys one by one, classify and group the numerical type fields according to the business function paragraphs they belong to, and form a structured parameter section set;

[0055] According to the set of structured parameter sections, extract the current numerical values of all fields in each parameter section as the current request parameter values, match the reference values of the corresponding fields in the historical security baseline of the target API interface, determine whether the difference between the field value and the reference value exceeds the allowable deviation range, count the number of fields with over-limit deviation values in each parameter section, record each section and the number of fields that trigger exceptions, and calculate the time difference by combining the request timestamp of this section and the most recent call time of the target API interface to form a request payload boundary offset analysis set;

[0056] Based on the request payload boundary offset analysis set, calculate the deviation degree of the request behavior pattern. The calculation formula is:

[0057] ;

[0058] Among them, is the deviation degree of the request behavior pattern, is the number of sections participating in the effective deviation calculation in the set of structured parameter sections, is the actual numerical value of the current request parameter field in the th parameter section, is the reference value of the corresponding field of this field in the historical security baseline, is the total number of fields that trigger exceptions in theth parameter section, is the time difference between the time when this request is sent corresponding to this section and the most recent valid request of the target API interface,

[0059] Specifically, based on the initial API request security context, first extract the payload data field of the API request from the original message or parsed data included in this context. This payload data is usually in the form of a JSON object, XML document, form parameters, etc. Subsequently, perform a deep parse on the extracted payload data field to identify and extract all key-value pairs that can be structurally understood. For example, for a JSON-formatted payload data {"user_info": {"id": 101, "age": 30, "status": "active"}, "order_details": {"item_id": "A789", "quantity": 2, "price_per_item": 50.00}}, after parsing, key-value pairs such as "user_info.id": 101, "user_info.age": 30, "order_details.quantity": 2, "order_details.price_per_item": 50.00 will be obtained. Then, review these extracted key-value pairs one by one. By checking the data type of the value corresponding to each key, filter out the fields whose values are numerical types. For example, 101 (integer), 30 (integer), 2 (integer), 50.00 (floating point number) all belong to numerical type fields, while "active" (string) and "A789" (string) do not. After identifying all numerical type fields, classify and group these numerical type fields according to the functional categories they belong to in the business logic. The "business function paragraphs" here are pre-divided according to the business purpose of the API interface design. For example, for the API in the above e-commerce scenario, it may pre-define a "user information parameter section" (including fields such as age, login_attempts, etc.) and an "order transaction parameter section" (including fields such as quantity, price_per_item, total_amount, etc.). The system will maintain a mapping rule to map the specific numerical type field name (such as age) or its path (such as user_info.age) to the corresponding business function paragraph name (such as "user information parameter section"). Through this classification and grouping operation, finally, a structured parameter section set is formed, where each element represents a business function paragraph and contains all the identified numerical type fields belonging to this paragraph and their values in the current request.

[0060] Based on the set of structured parameter sections formed in the previous step, for each parameter section in the set, extract the specific values of all numerical type fields contained therein in the current API request as the current request parameter values. Subsequently, match and compare these current request parameter values one by one with the reference values corresponding to them in the "historical security baseline" pre-built for the target API interface. The "historical security baseline" is a set of benchmark data established for each monitored parameter field of each API interface by statistically analyzing the historical values of this parameter over a relatively long stable operation period in the past (for example, continuously monitoring and collecting all API request data marked as normal in the past 30 days) (such as calculating its average value, median, standard deviation, common value range, etc.). For example, for the quantity field in the "order transaction parameter section", its historical security baseline may record that its average value is 2, the standard deviation is 1, and the allowed normal value range is 1 to 5. Then, determine whether the difference between the current value of each field and its baseline reference value exceeds the preset "allowed deviation range". The setting method of the "allowed deviation range" is: for a certain parameter field, its allowed deviation range can be set as the average value in the historical security baseline of this field plus or minus times its historical standard deviation, that is , where is the baseline average value, is the baseline standard deviation, and the coefficient is an empirical value dynamically adjusted according to the business sensitivity of this parameter and the acceptable false alarm rate. For example, for the critical payment amount field, takes the value of 2.5, and for the general query parameter paging size, takes the value of 3.5. If the current value of a certain field falls outside the calculated interval, it is determined that the deviation value of this field is over-limit. For example, if the current request parameter value of the quantity field is 10, its baseline average value is 2, and the standard deviation is 1, is set to 3, then the allowed deviation range is , that is , considering that the actual quantity cannot be negative, it is adjusted to . The current value 10 exceeds this range and is thus marked as over-limit. Then, count and record the total number of fields with over-limit deviation values in each parameter section. At the same time, combine the timestamp of the current API request corresponding to this section (obtained from the initial API request security context) with the timestamp of the last effective call of this target API interface recorded in the system, and calculate the time difference between the two. Finally, integrate the identifier of each parameter section, the number of fields that trigger an exception (i.e., over-limit deviation values) in this section, and the calculated time difference to form a request load boundary offset analysis set.

[0061] Formula: , the advantage of the formula is that by comprehensively evaluating the deviations of multiple parameter sections in the API request and combining the number of abnormal parameters and the time behavior characteristics of the request, it realizes the accurate quantification of the deviation degree of the request behavior pattern. This formula not only considers the statistical differences between individual parameter values and their historical baselines, but also magnifies the impact of multiple concurrent exceptions by introducing the square root of the abnormal field count , and at the same time uses the time difference and the average call interval ratio to adjust the contribution weight of the request time behavior to the deviation degree. This multi-dimensional and fine-grained quantification method can capture complex and hidden abnormal request patterns more comprehensively. For example, for requests where the deviation of a single parameter is not significant but the combination of multiple parameters shows abnormalities, or the call timing is different from the normal pattern, this formula can effectively improve the accuracy and sensitivity of identification. Compared with the traditional single-point threshold-based detection method, this formula reduces the possibility of missed reports and false alarms through the collaborative operation of each parameter, providing a more reliable risk measurement input for subsequent API security protection strategies (such as dynamic token adjustment, reputation rating);

[0062] Parameter The acquisition steps are as follows: represents the number of sections actually participating in the effective deviation calculation in the structured parameter section set. This value is obtained by counting the number of independent parameter sections included in the "request payload boundary offset analysis set" generated in the previous step. For example, if the payload data of an API request is divided into three business function sections: "user authentication parameter section", "order details parameter section", and "payment information parameter section", and valid numerical parameters are extracted from all three sections and participate in the boundary check, then The value of is 3. The acquisition of this parameter does not involve complex calculations and directly comes from the counting operation of the processed data set. For example, after the system analyzes an API request and identifies two parameter sections, "transaction amount section" and "product quantity section", both of which participate in the deviation calculation, then .

[0063] Parameter The acquisition steps are as follows: represents the actual measured value of a specific numerical parameter field of the current API request in the th parameter section. This value is directly extracted from the payload data of the API request. After parsing the API request payload and classifying it by business function section, is the current value of the parameter selected for deviation calculation within a specific section. For example, in the "order details parameter section" (assumed to be the 1st section, i.e., ), if the field "order_amount" (total order amount) is concerned and the value of this field in the current request is 1250.75 yuan, then .

[0064] Parameter is obtained as follows: represents the th parameter section, and the reference value of the specific numerical parameter field corresponding to parameter in its historical security baseline is its historical average value. This historical security baseline is obtained by statistically analyzing the values of this specific parameter field in all requests identified as normal during a past stable operation period (e.g., the most recent 60 days) of this API interface. For example, for the "order details parameter section" field "order_amount", the values of this field in 20,000 normal requests were collected in the past 60 days, and the sum of these values is 18,000,000 yuan. Then its historical average reference value yuan.

[0065] Parameter is obtained as follows: represents the th parameter section, and the standard deviation characteristic scale value recorded in the historical security baseline of the specific numerical parameter field corresponding to parameter . It reflects the degree of fluctuation of the historical normal values of this parameter around its average value . For example, continuing with the example of the "order_amount" field, based on the above 20,000 normal request data and its average value of 900.00 yuan, the sum of the squared differences between each observed value and the average value is calculated to be 80,000,000 yuan. Then its historical standard deviation yuan.

[0066] Parameter is obtained as follows: indicates in the In a parameter section, the total number of numerical parameter fields for which the current API request triggered an exception (i.e., their values exceeded the preset allowable deviation range). This value is derived from the statistical result of the previous step, "Request Payload Boundary Offset Analysis Set". When forming this analysis set, deviation checks were performed one by one on all numerical fields within each parameter section, and the number of fields exceeding the allowable deviation range was counted. For example, if the "Order Details Parameter Section" (the 1st section) contains three monitored numerical fields: order_amount, item_quantity, and discount_applied, and after inspection, it is found that the values of item_quantity and discount_applied in the current request both exceed their respective allowable deviation ranges, while order_amount is within the limit, then .

[0067] Parameter is obtained as follows: represents the time difference in seconds between the timestamp of the current API request corresponding to the th parameter section and the timestamp of the most recently recorded valid request of the target API interface. The timestamp of the current API request is directly obtained from the request metadata (such as the timestamp field in the HTTP header or the time when the system received the request), and the timestamp of the most recently valid request of the target API interface is recorded and updated by the system after processing each valid API call. For example, if the current request is received at 2025-05-15 17:30:05 UTC, and the time of the previous valid request record of this API interface is 2025-05-15 17:29:45 UTC, then seconds.

[0068] Parameter is obtained as follows: represents the average call interval time in seconds of the target API interface pointed to by the current API request within a fixed historical period in the past (e.g., the past 24 hours). The calculation method of this value is: first, count the total number of valid calls of this API interface within this fixed period and the time intervals between each call (where ), and then calculate the average of these time intervals. For example, an API interface was validly called 1199 times within the past 24 hours (a total of 86400 seconds), forming 1198 call intervals, and the sum of these intervals is 86000 seconds, then seconds.

[0069] Calculation process: Set the number of sections participating in the calculation .

[0070] Section 1: "Order Details Parameter Section" (Current order amount), (Historical average order amount), (Standard deviation of historical order amounts), (2 fields in this section trigger an exception), (Time difference between the current request and the previous request is 20 seconds), (Average call interval for this API interface is 71.79 seconds);

[0071] Calculate the deviation contribution term for Section 1 :

[0072] ;

[0073] ;

[0074] ;

[0075] ;

[0076] ;

[0077] Section 2: "User Behavior Parameter Section", for example, the parameter session_duration (session duration, in seconds), (The current session lasts for 30 minutes), (The historical average session duration is 10 minutes), (Standard deviation of historical session durations is 2.5 minutes), (Only the session_duration field in this section triggers an exception), (Same as above), (Same as above);

[0078] Calculate the deviation contribution term for Section 2 :

[0079] ;

[0080] ;

[0081] ;

[0082] ;

[0083] ;

[0084] Calculate the final deviation degree of the request behavior pattern :

[0085] ;

[0086] ;

[0087] ;

[0088] ;

[0089] The result shows that the deviation degree of the current API request behavior pattern has a calculated value of 13.076. This value comprehensively reflects the degree to which each parameter section in the request deviates from the historical normal behavior. It is a dimensionless relative indicator. The larger the value, the greater the difference between the current request and the historical security baseline, and the higher the potential risk. Specifically, the deviation degree value of 13.076 will be used as a key input for the subsequent API call risk assessment. The system can preset different deviation degree thresholds to divide the risk levels. For example, if 0 - 5 is preset as low deviation, 5 - 10 as medium deviation, and above 10 as high deviation, then the current will be identified as a high - deviation behavior.

[0090] The steps to obtain the API call risk assessment result are as follows:

[0091] Based on the request behavior pattern deviation degree, extract the target API interface field, request timestamp field, and request type field from the initial API request security context. Statistically record the historical call times of the current target API interface within 1800 seconds before the request is sent as the call frequency parameter, and generate an API interface call frequency input set;

[0092] According to the API interface call frequency input set, calculate the API call risk score. The calculation formula is:

[0093] ;

[0094] where, is the API call risk score, is the request behavior pattern deviation degree, is the th call frequency (unit: Hz) of the target API interface within 1800 seconds before the th request,

[0095] is the API call frequency reference benchmark (unit: Hz);

[0096] Specifically, based on the deviation degree of the request behavior pattern calculated in the previous steps, first, extract the core metadata information related to the current API request from the "initial API request security context" constructed and passed in the early stage of the call process. Specifically, it includes: "target API interface field", for example, its value is a string representing a specific API endpoint, such as / commerce / orders / v1 / create; "request timestamp field", its value is a Unix timestamp accurate to seconds or milliseconds, such as 1747364825, representing the moment when the system receives this API request; and "request type field", its value is a classification identifier describing the business nature of the request, such as "create order request" or "user login verification". After obtaining these basic information, the system will query the historical call records within a consecutive 1800 - second (i.e., 30 - minute) time window immediately before the current "request timestamp field" for the API interface identified by the "target API interface field". This query operation usually accesses a log system or in - memory database that continuously records all API call activities. The system stores key information such as the interface name and call time of each API call. By filtering all historical call records within this time window that match the current "target API interface field" and counting the qualified records, a specific value, namely the "historical call count", is obtained. This value is then recorded as a temporary "call frequency parameter". Finally, the previously extracted "target API interface field", "request timestamp field", "request type field", together with this newly calculated "call frequency parameter", are jointly combined and encapsulated into a structured data unit to form an API interface call frequency input set to support subsequent API call risk score calculation.

[0097] Formula: , The benefit of the formula is that it comprehensively combines the static deviation of the request content and the dynamic abnormality of the request frequency in a non - linear manner, so as to more accurately evaluate the potential risk of API calls. Specifically, by adding to 1, it ensures that even if the content is completely normal ( ), there is a basic consideration; the frequency deviation term uses a square operation to amplify the impact of high - frequency calls or calls far below the normal frequency, making the contribution of extreme abnormalities in frequency to the risk score more prominent; after adding 1 to the entire product term and taking the natural logarithm (ln), on the one hand, it makes the risk score It increases monotonically with the increase of each risk factor. On the other hand, the logarithmic function is used to smooth and compress the score value, so that it is distributed in a more manageable and interpretable numerical range, avoiding extreme jumps in the scoring results caused by individual factors being too large. This design enables the risk score to more stably and comprehensively reflect the overall risk level of API call behavior, providing a reliable quantitative basis for subsequent refined risk control strategies. For example, it can effectively identify those exploratory attacks with seemingly minor abnormal content but extremely high call frequencies, or potential business function failures or abuse situations of interfaces with normal content but call frequencies far lower than expected.

[0098] The parameter is obtained as follows: is the "request behavior pattern deviation degree" calculated in the previous step. For example, in the previous step, by analyzing and calculating multiple parameter sections of an API request, the request behavior pattern deviation degree is obtained, and this value will be directly used as an input to this formula.

[0099] The parameter is obtained as follows: represents the actual call frequency of the target API interface pointed to by this request within a specific time window (1800 seconds here) before the th API request occurs, with the unit of hertz (Hz). Its calculation method is as follows: First, obtain the "call frequency parameter" recorded from the "API interface call frequency input set" generated in the previous step, that is, the total number of historical calls of the target API interface within 1800 seconds before the request is sent, and then divide this total number by the number of seconds in the time window (1800 seconds). For example, if the "API interface call frequency input set" shows that the target API interface of the current request has been called 540 times in the past 1800 seconds, then its actual call frequency .

[0100] The parameter is obtained as follows: is a call frequency reference benchmark set for the current target API interface, with the unit of hertz (Hz). It represents the maximum call frequency expected, acceptable, or sustainable for this API interface under normal business loads. The setting of this benchmark value is usually based on long-term statistical analysis of the historical call data of this API interface and comprehensive evaluation of its business attributes and system bearing capacity. For example, for a specific API interface, by analyzing its call logs in the past 30 days, it is found that in 95% of the time, the number of calls per second does not exceed 0.5 times. Then the call frequency reference benchmark can be set to .

[0101] Calculation process: According to the aforementioned parameter acquisition steps, the specific values of each parameter are set as follows: the deviation degree of the request behavior pattern (calculated from the previous stage), the call frequency of the target API interface within 1800 seconds before the request , the reference benchmark for the call frequency of the target API interface ;

[0102] Substitute these values into the calculation formula of the API call risk score :

[0103] ;

[0104] ;

[0105] ;

[0106] ;

[0107] ;

[0108] ;

[0109] ;

[0110] Consulting the natural logarithm table or using a calculator, we can obtain:

[0111] ;

[0112] This result indicates that the risk score of this API call is approximately 3.0029. This score is a comprehensive indicator that integrates the abnormality degree of the request content itself (reflected by ) and the abnormality of the request frequency (reflected by the comparison between and ). The higher the risk score value.

[0113] Based on the API call risk score (for example, its value is 3.0029) calculated in the previous step, the system will then match this score with a pre-defined and configured "risk level table". This "risk level table" is a core policy configuration item that clearly stipulates the specific risk level identifiers corresponding to different API call risk score value intervals. The formulation of this table is usually set by the security administrator after comprehensively considering historical security event data, simulated attack test results, business risk tolerance, and response measures planned to be implemented under different risk levels. For example, an exemplary "risk level table" contains the following mapping rules: If the API call risk score In the range from 0 to less than 1.0 (i.e., ), the risk level is marked as "low risk"; if the score is in the range from 1.0 to less than 2.5 (i.e., ), it is marked as "medium risk"; if the score is in the range from 2.5 to less than 4.0 (i.e., ), it is marked as "high risk"; if the score is greater than or equal to 4.0 (i.e., ), it is marked as "extremely high risk". The specific interval boundary values (such as 1.0, 2.5, 4.0) are determined through continuous monitoring and optimization based on the statistical distribution characteristics in actual operation and the balance requirements of false positive rate and false negative rate. When performing interval matching, the system will compare the currently calculated value (such as 3.0029) with each scoring interval defined in the risk level table one by one to determine the interval it belongs to. According to the above example risk level table, since , the risk score of this API call will be mapped to the risk level mark of "high risk". Finally, the system outputs this matched risk level mark (i.e., "high risk") as the risk assessment result of this API call.

[0114] The steps to obtain the recommended value for adjusting the token validity period are as follows:

[0115] Based on the API call risk assessment result, extract the issued time field in the access token structure and the current system time field, calculate the difference between the issued time and the current system time as the used duration, and subtract the used duration from the total duration to obtain the remaining valid duration of the access token;

[0116] Based on the remaining valid duration of the access token and combined with the API call risk assessment result, calculate the recommended value for adjusting the token validity period. The calculation formula is:

[0117] ;

[0118] where, is the recommended value for adjusting the token validity period (unit: second), is the remaining valid duration of the access token (unit: second), is the API call risk score, is the proportional control constant set by the system (dimensionless), is the risk amplification index (dimensionless).

[0119] Specifically, based on the API call risk assessment results generated in the previous step, the system first needs to obtain the access token used in the current API request. This access token is usually part of the request (e.g., provided in the form of Bearer Token in the HTTP Authorization header), and its structure follows industry standards such as JSON Web Token (JWT). Next, extract the key timestamp information from the internal structure of this access token. Specifically, it is necessary to parse the payload part of the token and read the "issued at time field", which is usually the iat (Issued At) claim in JWT, and its value is a Unix timestamp representing the moment when the token was issued, such as 1747357625 (representing May 15, 2025, 16:27:05 UTC). At the same time, the system obtains the current "current system time field", that is, the current UTC timestamp accurate to the second obtained by calling the operating system kernel, such as 1747364825 (representing May 15, 2025, 18:27:05 UTC). Subsequently, calculate the difference between the two by subtracting the value of the "issued at time field" from the value of the "current system time field". This difference is the duration that the access token has been used since it was issued. For example, 1747364825 - 1747357625 = 7200 seconds, which is the used duration. Then, it is also necessary to determine the total valid duration of this access token. This can be obtained by reading the exp (Expiration Time) claim in the token payload (its value is the Unix timestamp of the token expiration moment), and then calculating the difference between the exp timestamp and the iat timestamp. Or, if the token follows a fixed validity period policy when it is issued (e.g., all tokens have a fixed validity period of 4 hours, i.e., 14400 seconds), then directly use this preset total duration. Finally, subtract the "used duration" calculated above from the "total duration" of the token to obtain the remaining valid duration of the current access token. For example, if the total duration is 14400 seconds and the used duration is 7200 seconds, then the remaining valid duration of the access token is 14400 - 7200 = 7200 seconds.

[0120] Formula: , The benefit of the formula is that it provides a dynamic and risk - adaptive mechanism to adjust the expiration period of the access token. By introducing the real - time risk score of the API call into the calculation of the token validity period, it realizes automatically shortening the available time of the token when the risk increases, thereby reducing the loss window that potential security threats (such as token theft) may cause. The proportional control constant and the risk amplification index It provides flexible configuration capabilities, allowing security policy makers to finely adjust the impact degree and sensitivity of risks on token lifetimes according to business characteristics and security tolerances. For example, by adjusting values, a high-risk score can have a more drastic non-linear reduction effect on the validity period, while can control the overall reduction intensity. This design not only enhances the security of the system but also takes into account the smoothness of the user experience by not overly shortening the token validity period at low risks, ensuring the intelligence of security protection and the timeliness of response.

[0121] The parameter is obtained as follows: represents the remaining valid duration of the access token used in the current API request, in seconds, without considering the current risk adjustment. It is calculated by obtaining the total valid duration of the token and subtracting the used duration since its issuance moment. For example, for a token with a total valid duration of 14,400 seconds that has been used for 7,200 seconds, the remaining valid duration of its access token seconds.

[0122] The parameter is obtained as follows: represents the risk score calculated for the current API call behavior. For example, in the aforementioned API call risk assessment process, the calculated API call risk score .

[0123] The parameter is obtained as follows: is a dimensionless proportional control constant preset by the system, used to adjust the basic intensity or sensitivity of the API call risk score on the reduction of the token validity period. The value of this constant is configured by the system security administrator according to the overall security policy, business scenario characteristics, and expected risk response level. When setting values, the amplitude of the desired reduction of the token validity period at a specific risk score level will be considered. For example, by simulating values in different risk scenarios, observing and adjusting to achieve the expected reduction effect. If a more aggressive and drastic response to risks by the system is desired, then can be set larger; otherwise, smaller. A specific setting process is as follows: Set the goal. When the risk score reaches a certain medium level (e.g., 2.0) and the risk amplification factor , and it is desired that the token validity period be reduced by approximately 20%, then the equation can be listed, and the solution is . After actual testing and effect evaluation, for example, finally set 。

[0124] Parameter The obtaining steps are as follows: is a dimensionless risk amplification index preset by the system and is used to control the API call risk score The degree of non-linear influence in the token validity period reduction calculation. When is the case, a higher risk score will be disproportionately amplified, resulting in a greater reduction in the validity period, thereby imposing a stronger restraint on high-risk behaviors. When is the case, the influence is linear (relative to itself); when is the case, the marginal influence of the high-risk score will weaken. The setting of this index is based on how the system expects to differentially adjust the token validity period according to the risk level. For example, if the policy requires a much greater response to extremely high risks than to medium-high risks, a larger value will be selected. This value is usually determined by analyzing the risk-validity period reduction curves under different values and combining the balance of security requirements and user experience. For example, after multiple simulation tests and comparing the influence curves on in different intervals, in order to ensure that high risks can be effectively curbed while the influence of medium and low risks is controllable, is selected and set.

[0125] Calculation process: According to the aforementioned parameter obtaining steps, the specific values of each parameter are set as follows: The remaining valid duration of the access token seconds, the API call risk score , the proportional control constant set by the system, the risk amplification index ;

[0126] Substitute these values into the calculation formula of the recommended value for adjusting the token validity period:

[0127] ;

[0128] ;

[0129] First, calculate : Then substitute it back into the calculation of :

[0130] ;

[0131] ;

[0132] ;

[0133] ;

[0134] ;

[0135] The result shows that according to the risk assessment result of the current API call, it is recommended to adjust the remaining valid time of the access token to about 4735.68 seconds. The original remaining valid duration was 7200 seconds. Due to certain API call risks (risk score: 3.0029), the recommended valid period calculated by the system was shortened by about seconds (about 41 minutes).

[0136] The steps to obtain the dynamic access token update instruction are as follows:

[0137] Based on the recommended value for adjusting the token validity period, compare the difference between the recommended value for adjusting the token validity period and the remaining valid duration of the current access token. If the recommended value for adjusting the token validity period is less than the remaining valid duration of the current access token, mark that there is a risk of early expiration for the current access token; otherwise, mark it as a state that does not require processing, and generate an access token shortening requirement identifier;

[0138] Based on the access token shortening requirement identifier, determine whether the revocation condition is met. If the access token shortening requirement identifier has been triggered and the recommended value for adjusting the token validity period is lower than the allowed minimum available duration threshold, mark the current access token as revoked; otherwise, mark it as a state that only requires shortening, and generate an access token processing policy result;

[0139] Based on the access token processing policy result, if it is in the revoked state, issue a token termination instruction; if it is in the state that only requires shortening, issue a token remaining time reduction instruction, and generate a dynamic access token update instruction.

[0140] Specifically, based on the recommended value for adjusting the token validity period calculated in the previous step (for example, seconds), the system first needs to obtain the actual remaining valid duration of the access token used in the current API request before adjustment (for example, seconds). This "remaining valid duration of the current access token" is calculated by parsing the token's issuance time, expiration time, and comparing with the current system time at the start of this round of risk assessment. Then, the system compares the "recommended value for adjusting the token validity period" with the "remaining valid duration of the current access token" in a direct numerical comparison. This is a core judgment step to determine whether to intervene in the token's lifecycle. The specific logic is: If the calculated "recommended value for adjusting the token validity period" is less than the "remaining valid duration of the current access token" (For example, ), it indicates that due to the high risk of the current API call, the system recommends shortening the validity period of the token to . In this case, the system will mark that there is a risk of the current access token having an earlier expiration time due to risk assessment and generate a corresponding internal status identifier; conversely, if the "suggested value for adjusting the token validity period" is greater than or equal to the "remaining valid duration of the current access token" , it means that the current risk level is not sufficient to make the suggested validity period shorter than the natural remaining life of the token, or the token itself has little remaining time and no intervention is required. At this time, the system will mark the access token as a status of not requiring processing. Finally, based on the result of this comparison and judgment, the system will generate a clear "identifier for shortening the access token". For example, if , then this identifier is set to "needs to be shortened", and if , then the identifier is "does not require processing".

[0141] Based on the "identifier for shortening the access token" generated in the previous step, the system continues to judge whether it is necessary to perform a more severe revocation operation on this access token. This judgment includes two chained conditions: The first condition is that the "identifier for shortening the access token" must have been triggered and marked as "needs to be shortened", indicating that there is indeed a need to shorten the token validity period based on risk assessment; the second condition is that on the premise that the first condition is met, further compare the "suggested value for adjusting the token validity period" calculated in the previous step (for example, seconds) with a "threshold for the minimum available duration allowed" preset by the system. This "threshold for the minimum available duration allowed" is part of the system security policy, aiming to ensure that even if the user token is shortened due to risk, there is at least a sufficiently short but still available time to complete the most basic operations or give an appropriate session end prompt, avoiding abruptly interrupting the user activity. The setting of this threshold is a process combining experience and analysis. For example, the system administrator analyzes the average time taken by users to complete a typical atomic operation (such as submitting a form, saving a draft), which is 45 seconds. Considering network fluctuations and operation differences, twice this average time, that is, 90 seconds, plus a fixed buffer time such as 30 seconds, totaling 120 seconds, is used as the "threshold for the minimum available duration allowed", that is, seconds. The specific judgment logic is: If the "identifier for shortening the access token" is "needs to be shortened" and the "suggested value for adjusting the token validity period" is less than (for example, if seconds, then ), the system will mark the status of the current access token as "revoked status", meaning the token should immediately become invalid; if the "Access Token Shortening Requirement Indicator" is "Needs to be shortened" but the "Suggested Token Validity Period Adjustment Value" is not less than (e.g., ), the system will mark the status of the current access token as "Only needs to be shortened status". Finally, based on this comprehensive judgment, the system generates an "Access Token Handling Policy Result" that clearly indicates the specific measures to be taken for this token subsequently, whether to "revoke" or "only shorten the validity period".

[0142] Based on the "Access Token Handling Policy Result" generated in the previous step, the system will make a decision and execute specific token management operations according to this result. If the "Access Token Handling Policy Result" indicates that the current access token is in the "revoked status", this means that the risk associated with this token is too high and the remaining validity period recommended is lower than the minimum acceptable by the system. Therefore, the system will immediately issue a "Token Termination Instruction", which will be sent to the token issuing authority or the token verification center (e.g., the authorization server of OAuth2.0 or the centralized session management service) to request that this specific access token (usually located by its unique identifier such as JTI) be removed from the set of valid tokens or added to the global token revocation list (TokenRevocationList, TRL) to ensure that any subsequent requests using this token will be rejected; if the "Access Token Handling Policy Result" indicates that the current access token is in the "Only needs to be shortened status", this means that the risk of the token is still within the controllable range and the remaining validity period recommended still has practical use value. At this time, the system will issue a "Token Remaining Time Reduction Instruction", which also acts on the token management system. The effect is to adjust the actual expiration time point of this access token to the current system time plus the "Suggested Token Validity Period Adjustment Value" calculated in the previous step ( , e.g., about 4735.68 seconds). For stateful tokens centrally managed by the server, the expiration time attribute stored on the server can be directly modified. For stateless tokens such as JWT, if the token itself is immutable, this instruction may mean that when the API gateway or resource server verifies this JWT, in addition to checking its original exp claim, it will also query a dynamic validity period record bound to this token (or its associated session), which has been updated to a new, shorter validity period. Finally, whether a "Token Termination Instruction" or a "Token Remaining Time Reduction Instruction" is issued, this specific instruction itself or the record of its execution status constitutes the "Dynamic Access Token Update Instruction", marking the completion of the dynamic adjustment of the current access token's life cycle.

[0143] The steps to obtain the updated reputation status of the request source are as follows:

[0144] Based on the API call risk assessment result, extract the request source network address field in the initial API request security context, and determine whether there is a historical risk record for the address. If there is and the current API call risk assessment result is marked as high risk, generate a request source risk behavior identifier.

[0145] Based on the request source risk behavior identifier, extract the criticality of the target API interface in the initial API request security context, and determine whether the interface belongs to the high criticality level. If it is at the high criticality level and the request source risk behavior identifier is in the triggered state, it is determined that the request source is in a high-sensitivity interface risk interaction state, and a request source risk interaction judgment result is generated.

[0146] Based on the request source risk interaction judgment result, update the request source reputation field in the initial API request security context. If the current judgment result is in the high-sensitivity interface risk interaction state, mark the request source reputation field as a low reputation state; otherwise, mark it as a normal reputation state, and generate the updated request source reputation state.

[0147] Specifically, based on the API call risk assessment result obtained in the previous step (for example, a specific risk level identifier such as "high risk", "medium risk", or "low risk"), the system first extracts the "request source network address field" used to identify the network location of the request initiator from the "initial API request security context" data structure established early in the current API request processing flow. This field is usually an IPv4 or IPv6 address, such as 203.0.113.75. Then, the system uses this extracted network address to query an internally maintained "historical risk record" repository. This repository continuously aggregates and updates the global network address list that has been identified as participating in malicious activities (such as distributed denial-of-service attacks, scanning and probing, malware propagation, etc.) or marked as high risk by authoritative third-party threat intelligence sources (for example, public malicious IP address databases, commercial threat intelligence subscription services), as well as the address records that have triggered high-risk security events multiple times in the system's history. The process of determining whether the current "request source network address field" exists in this "historical risk record" library usually involves an exact match or network segment match query of the current IP address with the records in the library. If the query result shows that there is a matching risk entry for the address, it is determined that the address has a historical risk background. Subsequently, the system will make a comprehensive judgment by combining these two information points: First, whether the currently extracted "request source network address field" has a historical risk record; Second, whether the "API call risk assessment result" of this API call is marked as "high risk". Here, the "high risk" level is based on the previously calculated API call risk score. (e.g., the score value is 3.0029) is compared and matched with a predefined risk level classification standard (e.g., a score within the range is "high risk"). Only when both of these conditions are met, that is, the request source address has a historical stain record and its current API call behavior itself is also evaluated as "high risk", will the system generate a "request source risk behavior identifier" and set it to the "triggered" state. Otherwise, the identifier will be set to the "not triggered" state.

[0148] Based on the "Request Source Risk Behavior Identification" generated in the previous step, the system will next evaluate the sensitivity of the target interface pointed to by the current API request and whether such access constitutes a high-risk interaction behavior. First, the system extracts the "Target API Interface Field" from the "Initial API Request Security Context" again (for example, the interface path / admin / system / config / update), and queries a pre-defined and maintained "Target API Interface Criticality" configuration table based on this interface identifier. This configuration table is part of the system security policy, which details all API interfaces in the system and their corresponding criticality levels. These levels, such as "High Criticality Level", "Medium Criticality Level", and "Low Criticality Level", are determined by the importance of the data processed by the API interface (for example, whether it involves core business data, user personal identity information PII, financial data, system configuration parameters, etc.), the potential impact of the operation (for example, the permission levels of operations such as data reading, modification, deletion, system control, etc.), and the degree of loss that the business may suffer if the interface is misused, jointly evaluated and set by security architects, business owners, and data protection officers. For example, an interface that directly modifies the system core configuration, such as / admin / system / config / update, will be defined as "High Criticality Level", while an interface that is only used to query public product information, such as / public / products / list, may be defined as "Low Criticality Level". After obtaining the "Target API Interface Criticality" of the current target API interface, the system will determine whether it belongs to the "High Criticality Level". Then, two conditions are considered comprehensively: First, whether the target API interface of the current request is rated as "High Criticality Level"; Second, whether the "Request Source Risk Behavior Identification" generated in the previous step is in the "Triggered State" (that is, the request source IP has historical risks and the risk of this call is also rated as high risk). If both of these conditions are met, that is, a request source with a history of bad behavior and currently showing high risk is attempting to interact with an API interface defined as "High Criticality Level", then the system will determine that the request source is in a "High-Sensitivity Interface Risk Interaction State" and generate the corresponding "Request Source Risk Interaction Judgment Result" accordingly. If either condition is not met, a judgment result of "Normal Interaction" or a similar non-risk state will be generated.

[0149] Based on the "Request Source Risk Interaction Judgment Result" generated in the previous step (for example, the judgment result is "High - sensitive Interface Risk Interaction Status" or "Normal Interaction"), the system will dynamically update the reputation information about this request source recorded in the "Initial API Request Security Context". In the "Initial API Request Security Context", each request source network address may initially carry a default reputation rating (for example, "Medium Reputation" or an initial reputation score based on its historical interaction records), or this reputation field is initialized at the beginning of request processing. The specific update logic is as follows: The system checks the current "Request Source Risk Interaction Judgment Result". If the result clearly indicates that the request source is in the "High - sensitive Interface Risk Interaction Status", this means that a source identified as having risky behavior is operating on a highly sensitive part of the system, which constitutes a significant security threat. Therefore, the system will update and mark the value of the "Request Source Reputation Field" associated with the "Request Source Network Address Field" in the "Initial API Request Security Context" as "Low Reputation Status". This change in status indicates a significant decrease in the system's trust in this source. Conversely, if the "Request Source Risk Interaction Judgment Result" is "Normal Interaction" or any other situation other than "High - sensitive Interface Risk Interaction Status", the system will mark or maintain the "Request Source Reputation Field" in the "Normal Reputation Status" (or there may be a slight adjustment according to a more detailed reputation model, but it will not directly drop to "Low Reputation"). Here, the "Normal Reputation Status" means that there is currently no sufficient evidence indicating that this source poses a serious threat, or its risky behavior does not touch the most sensitive interfaces. Through this series of judgment and update operations, the system finally generates the "Updated Request Source Reputation Status" for the source of this API request, and this status will be used as an important basis for subsequent access control decisions (such as adjusting the call frequency limit).

[0150] The steps to obtain the adjusted API access authorization parameters are as follows:

[0151] Based on the updated request source reputation status, determine whether this status is marked as the low - reputation status. If it is the low - reputation status, set this request source as a restricted access subject; otherwise, set it as a normal access subject, and generate a request source access subject permission category identifier;

[0152] Based on the request source access subject permission category identifier and combined with the call frequency regulation rules, retrieve the maximum call frequency limit parameter under the corresponding access subject permission category from the call frequency regulation rules, and generate an adjusted call frequency upper limit result;

[0153] Based on the adjusted call frequency upper limit result, update the access frequency control field in the initial API request security context to generate the adjusted API access authorization parameters.

[0154] Specifically, based on the "updated request source reputation status" updated and generated in the previous step (for example, this status may be "low reputation status" or "normal reputation status"), the system first needs to interpret this reputation status to determine what permission level the request source should be classified as in the current API access behavior. The specific judgment logic is to directly check the marked value of the "updated request source reputation status". If this status is clearly marked as "low reputation status", it indicates that the credibility of the request source (for example, a specific IP address) has been significantly reduced due to previous risk behavior assessments (which may include historical risk records, current API call risks, and interactions with highly sensitive interfaces). Therefore, the system will set this request source as a "restricted access subject", which means that its subsequent API access behaviors will be more strictly controlled. On the contrary, if the "updated request source reputation status" is "normal reputation status" or any other good status other than "low reputation", the system will set this request source as a "normal access subject", believing that it currently does not exhibit risk characteristics that require additional restrictions and can be processed according to the standard access policy. After completing this judgment and setting process, the system will generate a clear "request source access subject permission category identifier". For example, this identifier is an enumerated value SUBJECT_CATEGORY_RESTRICTED or SUBJECT_CATEGORY_NORMAL, and this identifier will be used as the key value for selecting the applicable policy from the call frequency control rules in the subsequent steps.

[0155] Based on the "request source access subject permission category identifier" generated in the previous step (for example, an identifier of SUBJECT_CATEGORY_RESTRICTED represents a restricted access subject), and in combination with a pre-configured "call frequency regulation rule", the system begins to determine the applicable maximum API call frequency limit for the current request source. This set of "call frequency regulation rules" is a structured policy library that details the upper frequency limits that different "access subject permission categories" should follow when accessing different "target API interfaces" or API interface groups. The construction of this rule library is usually completed by security administrators in collaboration with the business team, and its content includes at least dimensions such as subject category, target API (or API group represented by wildcards), time window (for example, 1 second, 60 seconds, 3600 seconds), and the maximum number of calls allowed within the corresponding time window. For example, the rule library may contain the following entries: For a "restricted access subject" (SUBJECT_CATEGORY_RESTRICTED) accessing payment-related interfaces (such as / api / payments / **), the allowed maximum call frequency is "5 times per minute"; while for a "normal access subject" (SUBJECT_CATEGORY_NORMAL) accessing the same payment-related interfaces, "60 times per minute" is allowed. These specific frequency limit values (such as 5 times / minute, 60 times / minute) are empirical values set based on a comprehensive assessment of the normal load of the API interface, performance benchmarks, statistical analysis of historical call data (for example, analyzing the call frequency distribution of normal users for a specific interface during peak periods and taking the 95th or 99th percentile as the reference upper limit), business requirements (such as the API call frequency required for critical business processes), and the overall security risk tolerance of the system. The system will use the current "request source access subject permission category identifier" and the "target API interface field" extracted from the "initial API request security context" to query and match in this "call frequency regulation rule" library to retrieve the most precisely matching or most applicable (such as through wildcard matching) "maximum call frequency limit parameter". Finally, the system outputs this specific limit parameter obtained from the query (for example, a data structure containing the time window size and the maximum number of calls allowed within that window, such as {window_seconds: 60, max_calls: 5}) as the "call frequency upper limit adjustment result".

[0156] Based on the "call frequency upper limit adjustment result" generated in the previous step (for example, a specific frequency limit parameter, such as a maximum of 5 calls allowed within a 60 - second time window), the system will update the "initial API request security context" data object that has been maintained throughout the current API request processing flow. Specifically, within this "initial API request security context" object, there is one or more fields for recording and managing access frequency control policies for the current request source. For example, there may be a structured field named access_frequency_policy, which contains sub - attributes such as limit_per_window (the number of calls allowed within the window period) and window_duration_seconds (the duration of the window period in seconds). The system will write the specific values (i.e., the new maximum number of calls and the corresponding time window size) obtained from the "call frequency upper limit adjustment result" into these corresponding fields of the "initial API request security context" object, replacing any default or previous frequency control settings for this request source. For example, if the default setting of the access_frequency_policy field for a normal access entity was {limit_per_window: 100, window_duration_seconds: 60}, and due to the reduced reputation status of the current request source to "low reputation", its "call frequency upper limit adjustment result" becomes {limit_per_window: 5, window_duration_seconds: 60}, then the access_frequency_policy field will be updated to this new and more restrictive limit value. This update operation is performed for the context of the current request to ensure that subsequent API gateways or traffic control components can process API calls from this request source based on this latest, dynamically adjusted frequency limit. After completing the update of these fields, a part of this "initial API request security context" that contains the latest access frequency control information, or a new data structure specifically encapsulating these adjusted frequency control parameters, constitutes the final "adjusted API access authorization parameters".

[0157] The above are only the preferred embodiments of the present invention and do not limit the present invention in other forms. Any person skilled in the relevant art may use the disclosed technical content to make changes or modifications into equivalent embodiments with equivalent changes and apply them to other fields. However, as long as it does not depart from the technical solution content of the present invention, any simple modification, equivalent change, and modification made to the above embodiments based on the technical essence of the present invention still fall within the protection scope of the technical solution of the present invention.

Claims

1. A security protection method for API interfaces based on anomaly detection, characterized in that, The following steps are involved: Based on the received API request, parse the API request to extract the request source network address and the target API interface call instruction, perform source authenticity verification and instruction validity judgment, and establish the initial API request security context for the API request in combination with the current timestamp information and request type information; Based on the initial API request security context and the payload data of the API request, perform sequence pattern matching and request parameter boundary checking, determine the difference between the current request payload data and the preset security baseline, obtain the request behavior pattern deviation, and based on the request behavior pattern deviation, perform security protection risk calculation in combination with the target API interface sensitivity information in the initial API request security context, and generate an API call risk assessment result; Based on the API call risk assessment result and the validity status of the current access token, the remaining validity time of the access token is calculated to generate a token validity adjustment recommendation value, and based on the token validity adjustment recommendation value, a decision is made whether to shorten or immediately revoke the current access token, and a dynamic access token update instruction is obtained; Based on the API call risk assessment result, the request source reputation in the initial API request security context is updated, and combined with the criticality of the target API interface, an updated request source reputation status is generated; based on the updated request source reputation status, the call frequency upper limit is readjusted, and the adjusted API access authorization parameters are established.

2. The API interface security protection method based on anomaly detection according to claim 1, wherein, The steps for obtaining the initial API request security context are: Based on the received API request, extract the original message content field in the API request, parse the request source network address field and the target API interface call instruction field in the original message content field, verify whether the request source network address field conforms to the trusted address format specification, determine whether the target API interface call instruction field matches the registered valid interface instruction set, and obtain the request source authenticity verification result and instruction validity judgment result; Based on the authenticity verification result of the request source and the instruction validity judgment result, the timestamp information field and the request type information field in the API request are called to construct a structured information unit including the request source network address field, the target API interface call instruction field, the timestamp information field and the request type information field, thereby forming a basic structured request element set; Based on the basic structured request element set, combined with the request source authenticity verification result and the instruction validity judgment result, all structured fields are integrated into security context data in a unified format to generate the initial API request security context.

3. The API interface security protection method based on anomaly detection according to claim 1, wherein The steps for obtaining the request behavior pattern deviation are: Based on the initial API request security context, extract all parseable structured key-value pairs in the API request payload data field, identify the numeric type fields bound to the keys one by one, and classify and group the numeric type fields according to the business function sections to which they belong, to form a structured parameter section set; According to the set of structured parameter sections, extract the current numerical values of all fields in each parameter section as the current request parameter values, match the reference values of the corresponding fields in the historical security baseline of the target API interface, determine whether the difference between the field values and the reference values exceeds the allowable deviation range, and count the number of fields with over-limit deviation values in each parameter section. Record each section and the number of fields that trigger exceptions, and calculate the time difference by combining the request timestamp of this section and the most recent call time of the target API interface to form a request load boundary offset analysis set; Based on the request load boundary offset analysis set, calculate the deviation degree of the request behavior pattern.

4. The API interface security protection method based on anomaly detection according to claim 1, wherein The steps for obtaining the API call risk assessment result are as follows: Based on the deviation degree of the request behavior pattern, extract the target API interface field, request timestamp field, and request type field from the initial API request security context, count the historical call times of the current target API interface within 1800 seconds before the request is sent and record it as the call frequency parameter, and generate an API interface call frequency input set; According to the API interface call frequency input set, calculate the API call risk score; Based on the API call risk score, perform interval matching on the API call risk score, and map it to a risk level identifier according to the defined risk level table to generate an API call risk assessment result.

5. The API interface security protection method based on anomaly detection according to claim 1, wherein The steps for obtaining the recommended value for adjusting the token validity period are as follows: Based on the API call risk assessment result, extract the issued time field in the access token structure and the current system time field, calculate the difference between the issued time and the current system time as the used duration, and subtract the used duration from the total duration to obtain the remaining valid duration of the access token; Based on the remaining valid duration of the access token, combine the API call risk assessment result to calculate the recommended value for adjusting the token validity period.

6. The API interface security protection method based on anomaly detection according to claim 1, wherein The steps for obtaining the dynamic access token update instruction are as follows: Based on the recommended value for adjusting the token validity period, compare the difference between the recommended value for adjusting the token validity period and the remaining valid duration of the current access token. If the recommended value for adjusting the token validity period is less than the remaining valid duration of the current access token, mark that there is a risk of early expiration of the current access token, otherwise mark it as a state that does not require processing, and generate an access token shortening requirement identifier; Based on the access token shortening requirement identifier, determine whether the revocation condition is met. If the access token shortening requirement identifier has been triggered and the recommended value for adjusting the token validity period is lower than the allowable minimum available duration threshold, mark the current access token as a revoked state, otherwise mark it as a state that only needs to be shortened, and generate an access token processing policy result; Based on the access token processing policy result, if it is in the revoked state, issue a token termination instruction, and if it is in the state that only needs to be shortened, issue a token remaining time reduction instruction to generate a dynamic access token update instruction.

7. The API interface security protection method based on anomaly detection according to claim 1, wherein, The steps for obtaining the updated request source reputation status are as follows: Based on the API call risk assessment result, extract the request source network address field in the initial API request security context, and determine whether there is a historical risk record for the address. If there is and the current API call risk assessment result is marked as high risk, generate a request source risk behavior identifier; Based on the risk behavior identifier of the request source, extract the criticality of the target API interface in the initial API request security context, and determine whether the interface belongs to the high criticality level. If it is at the high criticality level and the risk behavior identifier of the request source is in the triggered state, it is determined that the request source is in a high-sensitivity interface risk interaction state, and a request source risk interaction judgment result is generated; Based on the request source risk interaction judgment result, update the request source reputation field in the initial API request security context. If the current judgment result is the high-sensitivity interface risk interaction state, mark the request source reputation field as the low reputation state, otherwise mark it as the normal reputation state, and generate the updated request source reputation state.

8. The API interface security protection method based on anomaly detection according to claim 1, characterized in that, The steps for obtaining the adjusted API access authorization parameters are as follows: Based on the updated request source reputation state, determine whether the state is marked as the low reputation state. If it is the low reputation state, set the request source as a restricted access subject, otherwise set it as a normal access subject, and generate a request source access subject permission category identifier; Based on the request source access subject permission category identifier, combined with the call frequency regulation rule, retrieve the maximum call frequency limit parameter under the corresponding access subject permission category from the call frequency regulation rule, and generate a call frequency upper limit adjustment result; Based on the call frequency upper limit adjustment result, update the access frequency control field in the initial API request security context to generate the adjusted API access authorization parameters.

Images