A sensitive interface request method compliance detection method and device

Abstract

The application discloses a sensitive interface request method compliance detection method and device, relates to the technical field of software testing, and can accurately locate the interface object that needs to be detected by automatically screening sensitive interfaces based on a basic information list and a sensitive interface rule library, thereby saving the process of manually identifying one by one and improving the pertinence and accuracy of detection. By means of the basic information list and the sensitive interface rule library, the sensitive interfaces to be detected can be automatically determined, errors caused by manual identification are reduced, and the accuracy and efficiency of detection are improved. The compliance of the sensitive interfaces is detected, and different compliance states are distinguished, so that the actual use of the interfaces can be more comprehensively reflected, and judgment errors are reduced. The detection results are graded according to preset rules, so that the problems can be clearly distinguished in terms of importance, and subsequent processing work is facilitated. Corresponding disposal operations are performed in combination with the grading results, so that the interface detection and problem processing process is smoother, and the overall detection and control and disposal effect is improved.

Description

Technical Field

[0001] This application relates to the field of software testing technology, and in particular to a method and apparatus for detecting the compliance of sensitive interface request methods. Background Technology

[0002] With the rapid development of internet technology and software systems, interfaces have become the core carriers for internal data interaction, function calls, and cross-platform collaboration. Interface security is directly related to system stability, user privacy protection, and data security. In HTTP interface design specifications, the appropriate selection of request methods is a crucial aspect of ensuring interface security. This is especially true for interfaces involving sensitive operations such as password modification, user login, payment settlement, data deletion, and personal information changes. These interfaces must strictly adhere to industry security standards (such as the OWASP Security Guidelines) and network security level protection requirements, using request methods such as POST, PUT, and DELETE that allow parameters to be placed in the request body. GET requests should be prohibited to prevent sensitive information from being exposed through the URL, cached, or hijacked, thereby reducing the risk of information leakage and malicious attacks.

[0003] Current interface security testing technologies mainly focus on sensitive information leakage detection, interface access control verification, malicious request attack identification, and interface parameter legitimacy verification. These detection methods largely rely on manual interface-by-interface verification, with some using semi-automated tools. In systems with a large number of interfaces, this approach generally suffers from low efficiency, long verification cycles, and a high risk of omissions and misjudgments. Furthermore, most detection methods are deployed after system deployment for traffic backtracking and anomaly identification, making it difficult to integrate with software development and testing processes. This results in delayed problem discovery, high post-remediation costs, and difficulty in effectively managing security vulnerabilities. In addition, existing technologies lack a risk differentiation mechanism for non-standard interface request methods, resulting in weak problem-solving direction and an inability to form an effective closed loop in the overall detection and handling process, making it difficult to guarantee the completeness and efficiency of interface security testing. Summary of the Invention

[0004] To address the aforementioned issues, this application provides a method and apparatus for detecting compliance of sensitive interface request methods, comprising the following: Firstly, this application provides a method for compliance detection of sensitive interface request methods, the method comprising: Obtain a list of interfaces to be detected, and match the interfaces in the list of interfaces to be detected based on a pre-built basic information list and a sensitive interface rule base to filter out sensitive interfaces in the list of interfaces to be detected that contain sensitive operation keywords and / or sensitive parameters. The sensitive interfaces are subjected to compliance checks to obtain compliance check results, which include interfaces with compliant request methods, interfaces with non-compliant request methods, and interfaces with undefined request methods. The non-standard interface and the undefined request method interface are processed for risk classification according to the preset risk classification rules, and the risk classification results include high risk, medium risk and low risk are obtained. Based on the risk classification results, output detection identifiers, risk warnings, and handling strategies to achieve automated interface management or manual review and handling.

[0005] Optionally, after matching the interfaces to be detected in the list of interfaces to be detected based on a pre-built basic information list and a sensitive interface rule base, and filtering out sensitive interfaces in the list of interfaces to be detected that contain sensitive operation keywords and / or sensitive parameters, the method further includes: When the interface to be detected contains only sensitive operation keywords or sensitive parameters, the interface to be detected is judged as a normal priority sensitive interface; When the interface to be detected contains both sensitive operation keywords and sensitive parameters, the interface to be detected is judged as a high-priority sensitive interface.

[0006] Optionally, the compliance check on the sensitive interface to obtain the compliance check result includes: If the request method of a sensitive interface is GET, then the interface is determined to be an interface with an incorrect request method. If the request method of a sensitive interface is a standard request method specified in the sensitive interface rule base, then the interface is determined to be a request method specification interface; If the request method of a sensitive interface is a method not explicitly defined in the sensitive interface rule base, it is determined that the request method is an interface that is not defined.

[0007] Optionally, the step of performing risk classification processing on the non-standard interface and the undefined request method interface according to preset risk classification rules to obtain risk classification results including high risk, medium risk, and low risk includes: When a high-priority sensitive interface uses a GET request and carries sensitive parameters, it is directly judged as high-risk. When a high-priority sensitive interface uses a GET request without carrying sensitive parameters, or when a normal-priority sensitive interface uses a GET request with carrying sensitive parameters, it is judged as medium risk. When a sensitive interface uses a request method not explicitly specified in the sensitive interface rule base and does not use a GET request, it is determined to be low risk.

[0008] Optionally, the handling strategy includes: High-risk interfaces are given priority for handling; medium-risk interfaces are subject to handling within a specified time limit; and low-risk interfaces are subject to manual confirmation to determine whether to handle them.

[0009] Optionally, before obtaining the list of interfaces to be detected, the method further includes: Basic interface information is obtained from the system gateway, interface documentation, service registry, and interface access logs. This basic interface information includes the interface URL, request method, request parameter name and type, interface function description, and the service module to which the interface belongs. The basic information of the interface is standardized and then used as the basic information list. Construct a sensitive interface rule base, which includes a set of sensitive operation keywords, a set of sensitive parameters, and a set of request method specifications.

[0010] Optionally, the method can be applied to testing scenarios such as smoke testing, automated testing, pre-deployment checks, and continuous monitoring.

[0011] Secondly, this application provides a compliance detection device for sensitive interface request methods, the device comprising: The acquisition unit is used to acquire a list of interfaces to be detected. The filtering unit is used to match the interfaces to be detected in the list of interfaces to be detected based on a pre-built basic information list and a sensitive interface rule base, and to filter out the sensitive interfaces in the list of interfaces to be detected that contain sensitive operation keywords and / or sensitive parameters. A compliance detection unit is used to perform compliance detection on the sensitive interfaces and obtain compliance detection results. The compliance detection results include interfaces with compliant request methods, interfaces with non-compliant request methods, and interfaces with undefined request methods. The risk grading unit is used to perform risk grading processing on the non-standard interface and the undefined request method interface according to the preset risk grading rules, and obtain risk grading results including high risk, medium risk and low risk. The processing unit is used to output detection identifiers, risk warnings and processing strategies based on the risk classification results, so as to realize automated control or manual review and processing of the interface.

[0012] Optionally, the device further includes a judgment unit, which is used to judge the interface to be detected as a normal priority sensitive interface when the interface to be detected only contains sensitive operation keywords or sensitive parameters. When the interface to be detected contains both sensitive operation keywords and sensitive parameters, the interface to be detected is judged as a high-priority sensitive interface.

[0013] Optionally, the compliance detection unit is specifically used to determine that if the request method of a sensitive interface is GET, the interface is an interface with a non-standard request method. If the request method of a sensitive interface is a standard request method specified in the sensitive interface rule base, then the interface is determined to be a request method specification interface; If the request method of a sensitive interface is a method not explicitly defined in the sensitive interface rule base, it is determined that the request method is an interface that is not defined.

[0014] Optionally, the risk classification unit is specifically used to directly determine a high-risk interface when it uses a GET request and carries sensitive parameters. When a high-priority sensitive interface uses a GET request without carrying sensitive parameters, or when a normal-priority sensitive interface uses a GET request with carrying sensitive parameters, it is judged as medium risk. When a sensitive interface uses a request method not explicitly specified in the sensitive interface rule base and does not use a GET request, it is determined to be low risk.

[0015] Optionally, the processing unit is specifically used to prioritize processing high-risk interfaces; process medium-risk interfaces within a specified time limit; and determine whether to process low-risk interfaces after manual confirmation.

[0016] Optionally, the device further includes a construction unit for obtaining basic interface information from the system gateway, interface documentation, service registry, and interface access logs. The basic interface information includes the interface URL, request method, request parameter name and type, interface function description, and the service module to which the interface belongs. The basic information of the interface is standardized and then used as the basic information list. Construct a sensitive interface rule base, which includes a set of sensitive operation keywords, a set of sensitive parameters, and a set of request method specifications.

[0017] Optionally, the device can be applied to testing scenarios such as smoke testing, automated testing, pre-deployment inspection, and continuous monitoring.

[0018] Thirdly, this application provides an apparatus comprising a memory and a processor, the memory for storing instructions or code, and the processor for executing the instructions or code to cause the apparatus to perform the sensitive interface request method compliance detection method described in any implementation of the first aspect.

[0019] Fourthly, this application provides a computer-readable storage medium storing code, wherein when the code is executed, a device running the code implements the sensitive interface request method compliance detection method described in any of the implementations of the first aspect.

[0020] This application provides a method for compliance detection of sensitive interface request methods. When executing the method, a list of interfaces to be detected is first obtained. Based on a pre-built basic information list and a sensitive interface rule base, the interfaces in the list are matched to filter out sensitive interfaces containing sensitive operation keywords and / or sensitive parameters. Then, compliance detection is performed on these sensitive interfaces to obtain compliance detection results. These results include interfaces with compliant request methods, interfaces with non-compliant request methods, and interfaces with undefined request methods. Next, the non-compliant interfaces and the interfaces with undefined request methods are classified according to preset risk classification rules to obtain risk classification results including high risk, medium risk, and low risk. Finally, based on the risk classification results, a detection identifier, risk warning, and handling strategy are output to achieve automated interface management or manual review and handling.

[0021] Thus, by leveraging a basic information list and a sensitive interface rule base, sensitive interfaces to be detected can be automatically identified, reducing errors caused by manual identification and improving the accuracy and efficiency of detection. Conducting compliance checks on sensitive interfaces and differentiating between different compliance statuses can more comprehensively reflect the actual usage of the interfaces, reducing judgment errors. Classifying the detection results according to preset rules clearly distinguishes the severity and urgency of issues, facilitating subsequent processing. Executing corresponding actions based on the classification results makes the interface detection and problem handling process smoother, improving the overall detection and control effectiveness. Attached Figure Description

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

[0023] Figure 1 A flowchart illustrating a compliance detection method for a sensitive interface request method provided in this application embodiment; Figure 2 This is a schematic diagram of a compliance detection device for a sensitive interface request method provided in an embodiment of this application. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0025] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0026] Figure 1 This is a flowchart illustrating a compliance detection method for a sensitive interface request method provided in an embodiment of this application. (Combined with...) Figure 1 As shown, the compliance detection method for sensitive interface request methods provided in this application embodiment may include: S101. Obtain the list of interfaces to be tested.

[0027] The list of interfaces to be detected is a collection of interfaces used for data interaction and function calls in a software system, which serves as a unified detection object for subsequent sensitive interface identification.

[0028] Before obtaining the list of interfaces to be detected, it is necessary to first collect and organize the basic information of the interfaces and build and configure the sensitive interface rule base.

[0029] Basic interface information is automatically collected through a multi-source linkage approach. Collection sources include system gateways (such as Nginx and Spring Cloud Gateway), interface documentation (such as Swagger and ApiDoc), service registries (such as Nacos and Eureka), and interface access logs (such as Tomcat logs and gateway logs). System gateways forward interface requests, interface documentation records interface standard definitions, service registries manage online services and interfaces, and interface access logs record data of actually invoked interfaces. Multi-source collection avoids missing actual running interfaces not yet documented, ensuring the completeness of interface information. The basic interface information obtained from these data sources includes the interface URL, request method (GET / POST / PUT / DELETE, etc.), request parameter names and types, interface function description, and the service module to which the interface belongs. The interface URL uniquely identifies the interface access path, the request method characterizes the way the interface is invoked, the request parameter names and types characterize the data format transmitted by the interface, the interface function description explains the business role the interface plays, and the service module to which the interface belongs distinguishes the business unit to which the interface belongs. After collecting the above-mentioned basic interface information, the collected basic interface information needs to be deduplicated, cleaned, and standardized in format to form a standardized list of basic information, which will facilitate accurate matching and detection in the future.

[0030] The sensitive interface rule base serves as the core basis for identifying sensitive interfaces and determining the compliance of request methods. It includes a set of sensitive operation keywords, a set of sensitive parameters, and a set of request method specifications. The sensitive operation keyword set contains keywords corresponding to various sensitive operations, covering all sensitive operation scenarios, including but not limited to resetpwd, resetPassword, forgetpwd, findPwd, updatePwd, changePwd, setPwd, login, auth, register, pay, order, delete, modifyUserInfo, delUser, updatePhone, and bindCard. This includes sensitive operations such as resetting passwords, changing passwords, logging in, registering, paying, deleting data, modifying personal information, and binding bank cards. The sensitive parameter set contains various parameters used to assist in determining whether an interface is sensitive, including but not limited to password, newPwd, oldPwd, code, token, phone, idCard, bankCard, userName, and realName. The request method specification set defines the standard request methods for various sensitive operations, explicitly prohibiting the use of GET requests for sensitive operations. Specifically, the standard request methods for operations such as resetting passwords, changing passwords, logging in, registering, paying, obtaining verification codes, and changing permissions are POST or PUT; the standard request method for operations such as data deletion, user logout, and resource deletion is DELETE. GET requests are strictly prohibited for all sensitive operations. The rule base supports both manual and automatic updates to maintain timeliness and adaptability. Manual updates allow testers to add, delete, or modify sensitive keywords, sensitive parameters, and request method specifications through the front-end management interface based on the actual business scenarios of the system. Automatic updates analyze interface operation logs and test reports, using keyword extraction algorithms to identify unrecorded sensitive operation keywords, automatically sending reminder messages to testers, and automatically updating the rule base upon confirmation. By completing basic information organization and rule base construction in advance, stable and reliable data and judgment standards can be provided for subsequent detection steps, improving the smoothness and accuracy of the overall detection process.

[0031] S102. Based on the pre-built basic information list and sensitive interface rule base, match the interfaces to be detected in the list of interfaces to be detected, and filter out the sensitive interfaces in the list of interfaces to be detected that contain sensitive operation keywords and / or sensitive parameters.

[0032] Sensitive interfaces refer to interfaces that involve core business aspects such as user privacy, account security, property security, data deletion, permission changes, and personal information modification. Improper use of request methods for such interfaces can directly lead to information leakage and attack risks, and therefore should be given priority in the detection scope.

[0033] The screening process is achieved by automatically traversing and matching the URL, function description, and request parameters of the interface to be tested with the content of the rule base. No manual intervention is required throughout the process, and it can complete the full coverage comparison of all interfaces in the system.

[0034] When the interface to be tested contains only sensitive operation keywords or sensitive parameters, it is classified as a normal-priority sensitive interface. For example, an interface containing only login-related keywords or only the phone parameter can be classified as a normal-priority sensitive interface. When the interface to be tested contains both sensitive operation keywords and sensitive parameters, it is classified as a high-priority sensitive interface. For example, an interface containing both the updatePwd keyword and parameters such as password and token can be classified as a high-priority sensitive interface. Interfaces that contain neither sensitive operation keywords nor sensitive parameters are directly classified as non-sensitive interfaces and will not proceed to the next testing process.

[0035] By prioritizing sensitive interfaces, we can distinguish the risk level of the interfaces in advance, providing a basis for subsequent compliance testing and risk classification, making testing and handling more targeted and avoiding ineffective testing that wastes resources.

[0036] S103. Perform compliance testing on the sensitive interfaces to obtain compliance testing results. The compliance testing results include interfaces with compliant request methods, interfaces with non-compliant request methods, and interfaces with undefined request methods.

[0037] Compliance testing involves comparing the actual request methods used by sensitive interfaces with the standard request methods specified in the rule base to determine whether the interface conforms to security design specifications. If the request method of a sensitive interface is GET, it is considered a non-compliant interface. GET requests directly append parameters to the URL, making them vulnerable to browser caching, server log recording, or network hijacking, posing a risk of plaintext leakage of sensitive information and failing to meet the security requirements for sensitive interfaces. If the request method of a sensitive interface is a standard request method specified in the sensitive interface rule base, it is considered a compliant interface. Standard request methods include POST, PUT, and DELETE, which encapsulate parameters in the request body for transmission, effectively improving the security of sensitive data. If the request method of a sensitive interface is a method not explicitly specified in the sensitive interface rule base, it is considered an undefined interface, including less common request methods such as HEAD and OPTIONS. These methods cannot be directly determined to conform to security specifications and require further manual verification to avoid misjudgment.

[0038] S104. Perform risk classification processing on the non-standard interface and the undefined request method interface according to the preset risk classification rules to obtain risk classification results including high risk, medium risk and low risk.

[0039] Risk grading is a process that classifies non-standard interfaces and interfaces with undefined request methods into corresponding risk levels based on their request methods, parameter carrying, and interface priority. This clarifies the order and intensity of problem handling. The risk grading process, performed according to preset risk grading rules, yields risk grading results including high-risk, medium-risk, and low-risk. Specifically: when a high-priority sensitive interface uses a GET request and carries sensitive parameters, it is directly classified as high-risk. Such interfaces pose a direct risk of plaintext leakage of sensitive information and are easily exploited, requiring priority handling. When a high-priority sensitive interface uses a GET request without carrying sensitive parameters, or when a normal-priority sensitive interface uses a GET request with sensitive parameters, it is classified as medium-risk. While these interfaces do not directly leak core sensitive information, they still pose potential security risks such as URL tampering and operation hijacking. When a sensitive interface uses a request method not explicitly defined in the sensitive interface rule base and does not use a GET request, it is classified as low-risk. The overall risk level of these interfaces is low, and the final handling method can be determined through manual review. After risk classification is completed, the system generates a report including a detection overview (total number of detected interfaces, total number of sensitive interfaces, total number of non-compliant interfaces, and number of interfaces at each risk level), detailed information on non-compliant interfaces (interface URL, request method, module, sensitive keywords / parameters, risk level), suggestions for standardized request methods, handling priorities, and handling deadlines. It supports exporting to PDF, Excel, and other formats, facilitating testers to submit test reports and developers to view handling requirements. The system also supports real-time display of detection results on the front-end interface. By refining risk classification standards and providing corresponding detection reports, the system ensures a high degree of alignment between detection results and actual security risks, providing clear priority guidance for subsequent handling and improving the efficiency of problem resolution.

[0040] S105. Output detection identifiers, risk warnings, and handling strategies based on the risk classification results to achieve automated interface management or manual review and handling.

[0041] The system comprises several components: a detection identifier to mark non-compliant interfaces and interfaces with undefined request methods; a risk warning to visually reflect the security risk level and type of the corresponding interface; and a handling strategy to clarify the handling methods and execution requirements for interfaces with different risk levels. Automated interface management involves automatically blocking, disabling, or restricting calls to interfaces based on the handling strategy. Manual review and handling involves administrators reviewing and confirming the handling strategy in conjunction with the business scenario before executing the corresponding handling operations. Based on these handling operations, non-compliant interfaces and interfaces with undefined request methods are addressed in a targeted manner to eliminate security risks, standardize the use of interface request methods, and form a complete security closed loop of detection, classification, handling, and verification.

[0042] This application sets differentiated handling rules for interfaces with different risk levels: High-risk interfaces are given priority handling, as they involve a direct threat of sensitive information leakage, and priority handling can quickly reduce the overall system security risk; medium-risk interfaces are subject to time-limited handling, which allows for the reasonable allocation of development and testing resources, balancing security assurance and project progress, while ensuring the elimination of core risks; low-risk interfaces are subject to manual confirmation before handling is determined. Manual confirmation can assess whether the interface poses a real risk based on the actual business scenario and calling logic, avoiding unnecessary modifications.

[0043] The aforementioned detection methods can be integrated into the entire software testing process, adapting to various testing scenarios and automating and normalizing the detection process to ensure continuous and controllable compliance of interface request methods. During the smoke testing phase, core sensitive interfaces of the system are rapidly tested to ensure compliance of core interface request methods and avoid fundamental security vulnerabilities in core functions. During the automated testing phase, this detection method is automatically triggered after each round of automated testing, tracking the handling effect of non-compliant interfaces and ensuring that non-compliant issues do not recur after handling. During the pre-deployment inspection phase, all sensitive interfaces within the system undergo full-coverage testing, ensuring that all non-compliant interfaces are handled before the system is allowed to go live, intercepting security risks at the source. During the continuous testing phase, scheduled continuous testing is supported, monitoring changes to interface request methods in real time to promptly identify non-compliant issues arising from new interfaces or interface changes, making the interface detection and handling process coherent and complete, continuously ensuring interface security. By fully integrating detection capabilities into the entire testing process, problems can be identified and resolved before system deployment, significantly reducing post-deployment security risks and handling costs, and improving the overall efficiency and quality of interface security testing.

[0044] The above are some specific implementations of a compliance detection method for sensitive interface requests provided in the embodiments of this application. Based on this, this application also provides a corresponding apparatus. The apparatus provided in the embodiments of this application will be described below from the perspective of functional modularity.

[0045] Figure 2 This is a schematic diagram of a compliance detection device for a sensitive interface request method provided in an embodiment of this application. (Combined with...) Figure 2 As shown in the embodiment of this application, the sensitive interface request method compliance detection device 200 includes: Acquisition unit 210 is used to acquire a list of interfaces to be detected; The filtering unit 220 is used to match the interfaces to be detected in the list of interfaces to be detected based on a pre-built basic information list and a sensitive interface rule base, and to filter out the sensitive interfaces in the list of interfaces to be detected that contain sensitive operation keywords and / or sensitive parameters. The compliance detection unit 230 is used to perform compliance detection on the sensitive interface and obtain the compliance detection result. The compliance detection result includes the request method compliant interface, the request method non-compliant interface, and the request method undefined interface. Risk classification unit 240 is used to perform risk classification processing on the non-standard interface and the undefined request method interface according to preset risk classification rules, and obtain risk classification results including high risk, medium risk and low risk. The processing unit 250 is used to output detection identifiers, risk warnings and processing strategies based on the risk classification results, so as to realize automated control or manual review and processing of the interface.

[0046] In one implementation of this application, the device further includes a judgment unit, which is used to judge the interface to be detected as a normal priority sensitive interface when the interface to be detected only contains sensitive operation keywords or sensitive parameters. When the interface to be detected contains both sensitive operation keywords and sensitive parameters, the interface to be detected is judged as a high-priority sensitive interface.

[0047] In one implementation of this application, the compliance detection unit is specifically used to determine that if the request method of a sensitive interface is GET, the interface is an interface with an irregular request method. If the request method of a sensitive interface is a standard request method specified in the sensitive interface rule base, then the interface is determined to be a request method specification interface; If the request method of a sensitive interface is a method not explicitly defined in the sensitive interface rule base, it is determined that the request method is an interface that is not defined.

[0048] In one implementation of this application, the risk classification unit is specifically used to directly determine a high-risk interface when it uses a GET request and carries sensitive parameters. When a high-priority sensitive interface uses a GET request without carrying sensitive parameters, or when a normal-priority sensitive interface uses a GET request with carrying sensitive parameters, it is judged as medium risk. When a sensitive interface uses a request method not explicitly specified in the sensitive interface rule base and does not use a GET request, it is determined to be low risk.

[0049] In one implementation of this application, the processing unit is specifically used to perform priority processing on high-risk interfaces; perform time-limited processing on medium-risk interfaces; and determine whether to process low-risk interfaces after manual confirmation.

[0050] In one implementation of this application, the apparatus further includes a construction unit, configured to obtain basic interface information from a system gateway, interface documentation, service registry, and interface access logs. The basic interface information includes the interface URL, request method, request parameter name and type, interface function description, and the service module to which the interface belongs. The basic information of the interface is standardized and then used as the basic information list. Construct a sensitive interface rule base, which includes a set of sensitive operation keywords, a set of sensitive parameters, and a set of request method specifications.

[0051] In one implementation of this application, the device is applied to testing scenarios such as smoke testing, automated testing, pre-deployment inspection, and continuous monitoring.

[0052] This application also provides corresponding devices and computer storage media for implementing the solutions provided in this application.

[0053] The device includes a memory and a processor. The memory stores instructions or code, and the processor executes the instructions or code to cause the device to perform the method described in any embodiment of this application.

[0054] The computer storage medium stores code, and when the code is run, the device running the code implements the method described in any embodiment of this application.

[0055] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that all or part of the steps in the methods of the above embodiments can be implemented by means of software plus a general-purpose hardware platform. Based on this understanding, the technical solution of this application can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as a read-only memory (ROM) / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, a server, or a network communication device such as a router) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0056] It is understood that in the specific embodiments of this application, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved need to obtain user permission or consent when the above embodiments of this application are applied to specific products or technologies, and the collection, use and processing of related data need to comply with the relevant laws, regulations and standards of relevant countries and regions.

[0057] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0058] It should also be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the device and apparatus embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The device and apparatus embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components indicated as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the solution in this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0059] The above description is merely one specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for compliance detection of sensitive interface request methods, characterized in that, The method includes: Obtain a list of interfaces to be detected, and match the interfaces in the list of interfaces to be detected based on a pre-built basic information list and a sensitive interface rule base to filter out sensitive interfaces in the list of interfaces to be detected that contain sensitive operation keywords and / or sensitive parameters. The sensitive interfaces are subjected to compliance checks to obtain compliance check results, which include interfaces with compliant request methods, interfaces with non-compliant request methods, and interfaces with undefined request methods. The non-standard interface and the undefined request method interface are processed for risk classification according to the preset risk classification rules, and the risk classification results include high risk, medium risk and low risk are obtained. Based on the risk classification results, output detection identifiers, risk warnings, and handling strategies to achieve automated interface management or manual review and handling.

2. The method according to claim 1, characterized in that, The method further includes matching the interfaces to be detected in the list of interfaces to be detected based on a pre-built basic information list and a sensitive interface rule base, and filtering out sensitive interfaces in the list of interfaces to be detected that contain sensitive operation keywords and / or sensitive parameters. When the interface to be detected contains only sensitive operation keywords or sensitive parameters, the interface to be detected is judged as a normal priority sensitive interface; When the interface to be detected contains both sensitive operation keywords and sensitive parameters, the interface to be detected is judged as a high-priority sensitive interface.

3. The method according to claim 1, characterized in that, The compliance check on the sensitive interface, and the resulting compliance check results, include: If the request method of a sensitive interface is GET, then the interface is determined to be an interface with an incorrect request method. If the request method of a sensitive interface is a standard request method specified in the sensitive interface rule base, then the interface is determined to be a request method specification interface; If the request method of a sensitive interface is a method not explicitly defined in the sensitive interface rule base, it is determined that the request method is an interface that is not defined.

4. The method according to claim 2, characterized in that, The risk classification process for the non-standard interface and the undefined request method interface according to the preset risk classification rules yields risk classification results including high risk, medium risk, and low risk, including: When a high-priority sensitive interface uses a GET request and carries sensitive parameters, it is directly judged as high-risk. When a high-priority sensitive interface uses a GET request without carrying sensitive parameters, or when a normal-priority sensitive interface uses a GET request with carrying sensitive parameters, it is judged as medium risk. When a sensitive interface uses a request method not explicitly specified in the sensitive interface rule base and does not use a GET request, it is determined to be low risk.

5. The method according to claim 1, characterized in that, The handling strategy includes: High-risk interfaces are given priority for handling; medium-risk interfaces are subject to handling within a specified time limit; and low-risk interfaces are subject to manual confirmation to determine whether to handle them.

6. The method according to claim 1, characterized in that, Before obtaining the list of interfaces to be detected, the method further includes: Basic interface information is obtained from the system gateway, interface documentation, service registry, and interface access logs. This basic interface information includes the interface URL, request method, request parameter name and type, interface function description, and the service module to which the interface belongs. The basic information of the interface is standardized and then used as the basic information list. Construct a sensitive interface rule base, which includes a set of sensitive operation keywords, a set of sensitive parameters, and a set of request method specifications.

7. The method according to claim 1, characterized in that, The method is applicable to testing scenarios such as smoke testing, automated testing, pre-deployment checks, and continuous monitoring.

8. A compliance detection device for sensitive interface request methods, characterized in that, The device includes: The acquisition unit is used to acquire a list of interfaces to be detected. The filtering unit is used to match the interfaces to be detected in the list of interfaces to be detected based on a pre-built basic information list and a sensitive interface rule base, and to filter out the sensitive interfaces in the list of interfaces to be detected that contain sensitive operation keywords and / or sensitive parameters. A compliance detection unit is used to perform compliance detection on the sensitive interfaces and obtain compliance detection results. The compliance detection results include interfaces with compliant request methods, interfaces with non-compliant request methods, and interfaces with undefined request methods. The risk grading unit is used to perform risk grading processing on the non-standard interface and the undefined request method interface according to the preset risk grading rules, and obtain risk grading results including high risk, medium risk and low risk. The processing unit outputs detection identifiers, risk warnings, and processing strategies based on the risk classification results to achieve automated interface management or manual review and processing.

9. A computing device, characterized in that, The computing device includes: a memory and a processor; The memory is used to store computer programs; The processor is configured to implement the steps of the method as described in any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method as described in any one of claims 1 to 7.

Images