An API interface security protection method based on anomaly detection

Abstract

The present invention relates to the technical field of security protection, and specifically to a security protection method for API interfaces based on anomaly detection, including the following steps: 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, and perform source authenticity verification and instruction validity judgment. 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 timestamp and the request type, the present invention realizes the pre-modeling of the environmental state of each request, which helps to immediately determine its basic credibility before the request enters the business processing in depth. On this basis, compare with the sequence pattern and parameter boundary of the request payload, and use the behavior deviation degree as a reference item, and introduce the interface sensitivity information in the context to complete the quantitative judgment of the risk level, so that the judgment result has dynamic adaptability and structural relevance.

Description

Technical Field

[0001] The present invention relates to the technical field of security protection, and in particular 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 the dynamic protection management of behaviors such as abnormal calls, malicious attacks, and token abuse 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 the static identification and real-time comparison of abnormal request behaviors, lacking the global tracking of the API request context state, resulting in fragmentary and out-of-focus behavior judgments. Since the evolution process of the source reputation changing with time and request types cannot be recorded, it is difficult to dynamically adjust its trust level according to the historical interaction state of the requester, and thus it is easy to accumulate the risk of privilege abuse 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 deficiencies 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 includes 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 checking, determine the difference between the current request payload data and the preset security baseline to obtain the request behavior pattern deviation degree, and based on the request behavior pattern deviation degree, combine the target API interface sensitivity information in the initial API request security context to 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 by the keys one by one, classify and group the numerical type fields according to the business function paragraphs to which they belong 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 payload boundary offset analysis set;

[0017] Based on the request payload 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 it 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 issue time field in the access token structure and the current system time field, calculate the difference between the issue 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 of no need to process, 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 adjusted recommended value of 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 the 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 reputation status of the request source 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 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 generate a request source risk interaction judgment result.

[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 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 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, 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, in combination 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 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 timestamp and the request type, which helps to immediately determine the basic credibility of the request before it delves deep 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 risk judgment, taking the remaining time of the access token as the actual operation and maintenance control object, making a dynamic compression or revocation decision on its duration according to the risk level, and then realizing 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 restriction 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 Embodiment

[0040] In order to make the purpose, technical solution and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the 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 timestamp 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 target API interface sensitivity information 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 status of the current access token, calculate the remaining valid time of the access token to generate a token validity adjustment recommendation value, and based on the token validity adjustment recommendation value, decide whether to shorten or immediately invalidate 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, and based on the updated request source reputation status, readjust the upper limit of the call frequency to 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 judge whether the target API interface call instruction field matches the registered valid interface instruction set 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 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;

[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. This 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 a 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 a 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, whether it belongs to the public IP address range assigned by IANA (Internet Assigned Numbers Authority), and at the same time compare it with an internally maintained IP address blacklist, which contains known malicious IP addresses, proxy server IP addresses, and historical bad behavior IP addresses. 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. At the same time, perform a validity judgment on the extracted "target API interface call instruction field", and match 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 a boolean request source authenticity verification result and an instruction validity judgment result respectively.

[0051] Based on the request source authenticity verification result and instruction validity judgment result 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 invoked 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 "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 request initiation time (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 and takes its 99th percentile value to account for 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 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 request source network address field after verification and extraction (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 timestamp information field after verification and conversion (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 structured request element set.

[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, for example, true indicates authenticity) and the instruction validity judgment result (a boolean value, for example, 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, that is, the request source network address, the target API interface call instruction, the timestamp information, and the 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 assign the boolean value of the instruction validity judgment result to the api_instruction_valid key. For example, a specific instance of "security context data in unified format" may be shown as: {"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 and judgment results are gathered into a unified data object, and finally the initial API request security context is generated.

[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 by 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 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;

[0056] Based on the request load 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 of numeric type. For example, 101 (integer), 30 (integer), 2 (integer), 50.00 (floating point number) all belong to numeric type fields, while "active" (string) and "A789" (string) do not. After identifying all numeric type fields, classify and group these numeric 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 numeric 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, a structured parameter section set is finally formed, where each element represents a business function paragraph and contains all the identified numeric type fields belonging to this paragraph and their values in the current request.

[0060] Based on the set of structured parameter segments formed in the previous step, for each parameter segment in the set, extract the specific numerical 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-constructed 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 the parameter over a relatively long stable operation period in the past (e.g., continuously monitoring and collecting all API request data marked as normal in the past 30 days) (e.g., calculating its average value, median, standard deviation, common value range, etc.). For example, for the quantity field in the "order transaction parameter segment", its historical security baseline may record that its average value is 2, the standard deviation is 1, and the allowed normal value range is from 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 as follows: for a certain parameter field, its allowed deviation range can be set as the average value in the historical security baseline of the 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 the parameter and the acceptable false alarm rate. For example, for the critical payment amount field, takes a value of 2.5, while for the general query parameter paging size, takes a 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 the field is over the 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 of 10 exceeds this range and is thus marked as over the limit. Then, count and record the total number of fields with over-limit deviation values in each parameter segment. At the same time, combine the timestamp of the current API request corresponding to this segment (obtained from the initial API request security context) with the timestamp of the last effective call of the target API interface recorded in the system, and calculate the time difference between the two. Finally, integrate the identifier of each parameter segment, the number of fields that trigger an exception (i.e., over-limit deviation values) within the segment, and the calculated time difference to form a request load boundary offset analysis set.

[0061] Formula: , the benefit of the formula is that by comprehensively evaluating the deviations of multiple parameter segments 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 more comprehensively capture complex and hidden abnormal request patterns. For example, for requests where the deviation of a single parameter is not significant but the combination of multiple parameters presents an anomaly, 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 segments actually participating in the effective deviation calculation in the structured parameter segment set. This value is obtained by counting the number of independent parameter segments 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 segments: "user authentication parameter segment", "order details parameter segment", and "payment information parameter segment", and valid numerical parameters are extracted from all three segments 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 segments: "transaction amount segment" and "commodity quantity segment", 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 segment. This value is directly extracted from the payload data of the API request. After parsing the API request payload and classifying it according to the business function segments, is the current value of the parameter selected for deviation degree calculation within a specific segment. For example, in the "order details parameter segment" (assumed to be the 1st segment, i.e., ), if we focus on the "order_amount" (total order amount) field 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 numeric 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 last 60 days) of this API interface. For example, for the "order_amount" field in the "order details parameter section", the values of this field for 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 numeric 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., its value 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 for 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 for 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 for 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 past historical period (e.g., the past 24 hours). The value is calculated as follows: First, count the total number of valid calls to 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, if 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", e.g., parameter session_duration (session duration, in seconds), (Current session duration is 30 minutes), (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 behavior pattern of the current API request 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 index. 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 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. Statistically record 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 to generate the 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 deviation degree of the request behavior pattern, 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 requested 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", whose 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", whose 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 continuous 1800 seconds (i.e., 30 minutes) 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 the subsequent calculation of API call risk scores.

[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 characteristics of the logarithmic function are 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 score result 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 probing 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 obtained request behavior pattern deviation degree This value will be directly used as an input to this formula.

[0099] The parameter is obtained as follows: represents the actual frequency of the target API interface being called within a specific time window (1800 seconds here) before the th API request. The unit is Hertz (Hz). Its calculation method is: 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 load. 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] Refer to the natural logarithm table or use a calculator to 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 incorporates 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 perform interval matching of this score with a pre-defined and configured "risk level table". This "risk level table" is a core policy configuration item that clearly defines 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 comprehensive consideration of historical security incident data, simulated attack test results, business risk tolerance, and response measures planned for 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 labeled as "low risk"; if the score is in the range from 1.0 to less than 2.5 (i.e., ), it is labeled as "medium risk"; if the score is in the range from 2.5 to less than 4.0 (i.e., ), it is labeled as "high risk"; if the score is greater than or equal to 4.0 (i.e., ), it is labeled as "extremely high risk". The specific interval boundary values (such as 1.0, 2.5, 4.0) are determined by continuous monitoring and optimization according to the statistical distribution characteristics in actual operation and the balance requirements of false alarm rate and miss 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 label of "high risk". Finally, the system outputs this matched risk level label (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 issue time field in the access token structure and the current system time field, calculate the difference between the issue 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 precise 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, that is, 14400 seconds), then directly use this preset total duration. Finally, subtract the "used duration" calculated previously 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 validity 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 may be caused by potential security threats (such as token theft). The proportional control constant and the risk amplification exponent It provides flexible configuration capabilities, allowing security policy makers to finely adjust the impact degree and sensitivity of risks on the token lifetime 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 time. 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 is considered. For example, by simulating values in different risk scenarios, observing and adjusting to achieve the expected reduction effect. If a more active and drastic response to risks by the system is desired, can be set larger; otherwise, it can be set smaller. A specific setting process is as follows: Set the goal that when the risk score reaches a certain medium level (e.g., 2.0) and the risk amplification index , it is expected that the token validity period will be reduced by approximately 20%. Then, the equation can be listed and solved to obtain . After actual testing and effect evaluation, for example, finally set 。

[0124] Parameter The steps for obtaining it 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 amplified disproportionately, 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 stronger 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, and 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, based on the risk assessment result of the current API call, it is recommended to adjust the remaining valid time of the access token to approximately 4735.68 seconds. The original remaining valid duration was 7200 seconds. Due to certain API call risks (risk score: 3.0029), the recommended validity period calculated by the system was shortened by approximately 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 threshold of the minimum available duration allowed, mark the current access token as in the revoked state; 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 that does not require 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 determine whether a more severe revocation operation needs to be performed on the access token. This determination 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, it still retains a sufficiently short but still usable 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, a total of 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 flag" is "needs shortening" but the "suggested value for adjusting the token validity period" is not less than (for example, ), the system will mark the status of the current access token as "only needs shortening status". Finally, based on this comprehensive judgment, the system generates an "access token processing 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 processing 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 processing 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 it suggests is already 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 (for example, the authorization server of OAuth2.0 or the centralized session management service) to request the removal of this specific access token (usually located by its unique identifier such as JTI) from the set of valid tokens, or add it to the global token revocation list (TokenRevocationList, TRL) to ensure that any subsequent requests using this token will be rejected; if the "access token processing policy result" indicates that the current access token is in the "only needs shortening status", this means that the risk of the token is still within the controllable range and the remaining validity period it suggests 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. Its effect is to adjust the actual expiration time point of this access token to the current system time plus the "suggested value for adjusting the token validity period" calculated in the previous step ( , for example, about 4735.68 seconds). For stateful tokens centrally managed by the server, the expiration time attribute stored on the server side 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 the 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 and 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 a "dynamic access token update instruction", indicating that the dynamic adjustment of the current access token's life cycle has been completed.

[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 list of global network addresses that have 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 criterion (e.g., a score within the interval 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 Indicator" 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 interface may cause to the business if 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 Indicator" 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 a corresponding "Request Source Risk Interaction Judgment Result" accordingly. If either condition is not met, a judgment result such as "Normal Interaction" or a 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 with 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 that is not the "High - sensitive Interface Risk Interaction Status", then 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 has not touched 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 serve as an important basis for subsequent access control decisions (such as call frequency limit adjustment).

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

[0151] Based on the updated request source reputation status, judge 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, 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;

[0153] 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.

[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 kind of permission-level entity 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 entity", which means that its subsequent API access behaviors will be subject to stricter control. Conversely, if the "updated request source reputation status" is "normal reputation status" or any other non-"low reputation" good status, the system will set this request source as a "normal access entity", 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 entity 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, the identifier SUBJECT_CATEGORY_RESTRICTED represents a restricted access subject), and combined with a pre-configured "call frequency regulation rule", the system starts 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 original default settings for the access_frequency_policy field for a normal access entity were {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, It includes the following steps: 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; 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 to 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; 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, and 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; Based on the API call risk assessment result, update the reputation of the request source in the initial API request security context, and in combination with the criticality of the target API interface, generate an updated request source reputation status, and based on the updated request source reputation status, readjust the upper limit of the call frequency to establish adjusted API access authorization parameters; The steps for obtaining the API call risk assessment result are as follows: 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, 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 to generate an API interface call frequency input set; According to the API interface call frequency input set, calculate the API call risk score, and the calculation formula is: ； Among them, is the API call risk score, is the deviation degree of the request behavior pattern, is the call frequency of the target API interface within 1800 seconds before the th request, and is the API call frequency reference benchmark; 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.

2. The API interface security protection method based on anomaly detection according to claim 1, characterized in that The steps for obtaining the initial API request security context are as follows: 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, and judge whether the target API interface call instruction field matches the registered valid interface instruction set to obtain the request source authenticity verification result and the instruction validity judgment result; 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; Based on the above-mentioned basic structured request element set, combining the verification result of the authenticity of the request source and the judgment result of the instruction validity, all structured fields are integrated into security context data in a unified format to generate an initial API request security context.

3. The API interface security protection method based on anomaly detection according to claim 1, characterized in that The steps for obtaining the deviation degree of the request behavior pattern are as follows: Based on the above-mentioned initial API request security context, all resolvable structured key-value pairs in the API request payload data field are extracted. Each numerical type field bound by the key is identified item by item, and the numerical type fields are classified and grouped according to the business function paragraphs to which they belong to form a set of structured parameter sections. According to the above-mentioned set of structured parameter sections, the current value of all fields in each parameter section is extracted as the current request parameter value, and the reference value in the historical security baseline of the target API interface corresponding to the field is matched. It is judged whether the difference between the field value and the reference value exceeds the allowable deviation range, and the number of fields with over-limit deviation values in each parameter section is counted. The number of fields in each section and the number of fields triggering exceptions are recorded, and the time difference is calculated 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. Based on the above-mentioned request payload boundary offset analysis set, the deviation degree of the request behavior pattern is calculated.

4. The API interface security protection method based on anomaly detection according to claim 1, characterized in that The steps for obtaining the recommended value for adjusting the token validity period are as follows: Based on the above-mentioned API call risk assessment result, the issued time field in the access token structure and the current system time field are extracted, and the difference between the issued time and the current system time is calculated as the used duration. The remaining valid duration of the access token is obtained by subtracting the used duration from the total duration. Based on the above-mentioned remaining valid duration of the access token, combined with the above-mentioned API call risk assessment result, the recommended value for adjusting the token validity period is calculated.

5. The API interface security protection method based on anomaly detection according to claim 1, characterized in that The steps for obtaining the dynamic access token update instruction are as follows: Based on the above-mentioned recommended value for adjusting the token validity period, the difference between the recommended value for adjusting the token validity period and the current remaining valid duration of the access token is compared. If the recommended value for adjusting the token validity period is less than the current remaining valid duration of the access token, it is marked that there is a risk of early expiration of the current access token, otherwise it is marked as a status that does not need to be processed, and an access token shortening requirement identifier is generated. Based on the above-mentioned access token shortening requirement identifier, it is judged 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, the current access token is marked as a revoked status, otherwise it is marked as a status that only needs to be shortened, and an access token processing policy result is generated. Based on the above-mentioned access token processing policy result, if it is in the revoked status, a token termination instruction is issued. If it is in the status that only needs to be shortened, a token remaining time reduction instruction is issued to generate a dynamic access token update instruction.

6. The API interface security protection method based on anomaly detection according to claim 1, wherein The steps for obtaining the updated reputation status of the request source are as follows: Based on the above-mentioned API call risk assessment result, the request source network address field in the initial API request security context is extracted, and it is judged 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, a request source risk behavior identifier is generated. 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 the 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.

7. The API interface security protection method based on anomaly detection according to claim 1, wherein 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 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; 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