US20220321587A1

US20220321587A1 - Automatic anomaly detection based on api sessions

Info

Publication number: US20220321587A1
Application number: US17/339,951
Authority: US
Inventors: Ravindra Guntar; Ranaji Krishna
Original assignee: Traceable Inc
Current assignee: Traceable Inc
Priority date: 2021-03-30
Filing date: 2021-06-05
Publication date: 2022-10-06
Also published as: US20220318618A1; US20220318081A1; US20220318332A1; US20220318378A1

Abstract

A system identifies sessions of API behavior and uses the identified behavior to detect anomalous API requests. A session of API behavior is detected as two or more API requests that are typically received in a chronological order. The APIs in a session occur in a particular order, and have a particular API request or response that follows and/or precedes each other API request or response. Once APIs in a session are learned, incoming API requests typically associated with a session can be compared to the session to determine if they appear in an expected sequence based on the session. If an API request is not received in the sequence or chronological order according to an API session, the received request can be tagged as an anomaly. Similarly, if the received request does not include information from a previous response or request, the received API request may be an anomaly.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

The present application claims the priority benefit of U.S. provisional patent application 63/167,649, filed on Mar. 30, 2021, titled “INTELLIGENT APPLICATION PROTECTION,” the disclosure of which is incorporated herein by reference.

BACKGROUND

When analyzing, tracking, or monitoring a system, it is often important to know the specification of the system, including application program interface (API) specifications. In some systems, a common method for attacking is for an attacker to submit an API request and attempt to get information from the system. Can be difficult to detect whether these API requests from attackers are legitimate or not. What is needed is an improved mechanism for detecting illegitimate and API requests from unauthorized requesters.

SUMMARY

The present technology, roughly described, identifies sessions of API behavior and uses the identified behavior to detect anomalous API requests. A session of API behavior is detected as two or more API requests that are typically received in order. For example, for an e-commerce service, a session may include an API request to select a product, followed by an API response with a URL for viewing the product, an API request to place the product in the user's cart, followed by an API response with a URL for displaying the items in the user's cart, followed by an API request to perform checkout, and finally followed by an API response with a URL for providing a checkout page to the user. The APIs in a session occur in a particular order, and have a particular API request or response that follows and/or precedes each other API request or response.
Once APIs in a session are learned, incoming API requests that are typically associated with a session can be compared to the session to see if they appear in the expected sequence based on the session. If an API request is not received in the sequence according to an API session, the received request can be tagged as an anomaly. Similarly, if the received request does not include information from a previous response or request, the received API request can be tagged as an anomaly.
In some instances, a method automatically detects an anomaly based on a session of APIs received for a web service. The method begins with receiving, by a server from an agent stored on a remote server, an API request sent from a user device to a server API, the requests intercepted by the agent on the remote server. The received API request is compared to a set of APIs having a preset chronological order. The system then detects that the received API request is not received in an expected chronological order defined by the present chronological order. The received API request is identified as an anomaly based on the unexpected chronological order of the receive API request.
In some instances, a non-transitory computer readable storage medium has embodied thereon a program that is executable by a processor to perform a method. The method automatically detects an anomaly based on a session of APIs received for a web service. The method begins with receiving, by a server from an agent stored on a remote server, an API request sent from a user device to a server API, the requests intercepted by the agent on the remote server. The received API request is compared to a set of APIs having a preset chronological order. The system then detects that the received API request is not received in an expected chronological order defined by the present chronological order. The received API request is identified as an anomaly based on the unexpected chronological order of the receive API request.
In embodiments, a system can include a server, memory and one or more processors. One or more modules may be stored in memory and executed by the processors to receive, by a server from an agent stored on a remote server, an API request sent from a user device to a server API, the requests intercepted by the agent on the remote server, compare the received API request to a set of APIs having a preset chronological order, detect that the received API request is not received in an expected chronological order defined by the present chronological order, and identify the received API request as an anomaly based on the unexpected chronological order of the receive API request.

BRIEF DESCRIPTION OF FIGURES

FIG. 1 is a block diagram of a system for intelligently monitoring API sessions.

FIG. 2 is a block diagram of an application that automatically monitors API sessions.

FIG. 3 is a method that automatically monitors API sessions.

FIG. 4 is a method for identifying API requests related to an API response.

FIG. 5 is a method for identifying API requests related to previously intercepted API responses.

FIG. 6 is a method for detecting anomalous API requests based on API sessions.

FIG. 7 is a block diagram of a system for implementing machines that implement the present technology.

DETAILED DESCRIPTION

The present system identifies sessions of API behavior and uses the identified behavior to detect anomalous API requests. A session of API behavior is detected as two or more API requests that are typically received in order. For example, for an e-commerce service, a session may include an API request to select a product, followed by an API response with a URL for viewing the product, an API request to place the product in the user's cart, followed by an API response with a URL for displaying the items in the user's cart, followed by an API request to perform checkout, and finally followed by an API response with a URL for providing a checkout page to the user. The APIs in a session occur in a particular order, and have a particular API request or response that follows and/or precedes each other API request or response.
Once APIs in a session are learned, incoming API requests that are typically associated with a session can be compared to the session to see if they appear in the expected sequence based on the session. If an API request is not received in the sequence according to an API session, the received request can be tagged as an anomaly. Similarly, if the received request does not include information from a previous response or request, the received API request can be tagged as an anomaly.
FIG. 1 is a block diagram 100 of a system for intelligently monitoring API sessions. The block diagram 100 of FIG. 1 includes client devices 110-140, customer server 150, network 160, Application server 170, and data store 180.
Client devices 110-140 may send API requests to and receive API responses from customer server 150. The client devices may be any device which can access the service, network page, webpage, or other content provided by customer server 150. Client devices 110-140 may send a request to customer server 150, for example to an API provided by customer server 150, and customer server 150 may send a response to the devices based on the request. The request may be sent to a particular URL provided by customer server 150 and the response may be sent from the server to the device in response to the request. Though only for four client devices are shown, a typical system may handle requests from a larger number of clients, for example, dozens, hundreds, or thousands, and any number of client devices may be used to interact with customer server 150.
Customer server 150 may provide a service to client devices 110-140. The service may be accessible through APIs provided by customer server 150. Agent 152 on customer server 150 may monitor the communication between customer server 150 and client devices 110-140 and intercept traffic transmitted between the server and the devices. Upon intercepting the traffic, agent 152 may forward the traffic to application 172 on application server 170. In some instances, one or more agents may be installed on customer server 150, which may be implemented by one or more physical or logical machines. In some instances, server 150 may actually be implemented by multiple servers in different locations, providing a distributed service for devices 110-140. In any case, one or more agents 152 may be installed to intercept API requests and responses between devices 110-140 and customer server 150, in some instances may aggregate the traffic by API request and response data, and may transmit request and response data to application 172 on server 170.
Network 140 may include one or more private networks, public networks, intranets, the Internet, an intranet, wide-area networks, local area networks, cellular networks, radio-frequency networks, Wi-Fi networks, any other network which may be used to transmit data, and any combination of these networks. Client devices 110-140, customer server 150, Application server 170, and data store 180 may all communicate over network 160 (whether or not labeled so in FIG. 1).
Application server 170 may be implemented as one or more physical or logical machines that provide application functionality as described herein. In some instances, application server may include one or more applications 172. The application 172 may be stored on one or more application servers 170 and be executed to perform functionality as described herein. Application server and application 172 may both communicate over network 160 and data store 180.
Data store 180 may be accessible by application server 170 and application 172. In some instance, data store 180 may include one or more APIs, API descriptions, and other data.
FIG. 2 is a block diagram of an application that automatically monitors API sessions. Application 172 of FIG. 2 provides more detail for application 172 of the system of FIG. 1. Application 172 includes API parsing engine 210, API analyzing module 220, API session generator module 230, and anomaly alert 240. API parsing engine 210 may access and detect components of API requests. The engine 210 may detect path parameters, query parameters, request header content, request body content, response API headers and bodies, and other content within a URL, request, or response associated with an API. The parsed API components may be used to identify sessions of API requests.
API parsing engine can also detect portions of each component as they are detected by a remote agent. For example, each API parsing engine can detect component parameters, sensitivity, character distributions, and other data. Component parameters may include a variable type, such as an integer string, or float. Component sensitivity can include private information, such as credit card information, password information, security question information, email data, and other data that users may prefer to keep quiet or may be used to compromise their account, their finances, or other personal details. Character distribution identification and/or tracking may include detecting the location and number of occurrences of a particular character, for example in a URL, API request header or body, or API response body. The characters may include special characters colon, semicolon, slash, question marks, exclamation marks, asterisks, parenthesis, and other nun-numeric and non-alphabet characters.
API analyzing module 220 may determine if a received and parsed API matches an expected API as part of a session. In some instances, as an API request is received, it may be parsed and compared to an expected API or API template that is identified within a session of APIs. The expected API request may be the next API request in a series of requests that comprise an API session. API analyzing module 220 may retrieve a next expected API within a session, or all APIs within a session, from API session generator 230. If a detected API does not match an expected API, API analyzing may send a signal to anomaly alert 240.
API session generator 230 may identify sessions that consists of two or more APIs requests received in succession. For example, an API session generator may determine that a session includes APIs associated with selecting a product, adding a product to a cart, and then performing a checkout. APIs associated with the three actions may be associated with a session, and stored as a session by API session generator 230. API session generator 230 may provide API data to API analyzing module 220. The provider data may include APIs in a session, an indicator if a detected API is in any session, or other data associated with APIs within a session.
Anomaly alert 240 can generate an alert for an administrator, in a dashboard, or otherwise generate an alert in a system regarding the detection of an anomaly or some other status of interest. The alerts can be generated, for example, via message, email, through an interface, in a dashboard, or in some other way that communicates the occurrence of the anomaly.
FIG. 3 is a method that automatically monitors API sessions. First, an agent may be installed in a customer system to intercept live traffic at step 310. The installation may include one or more agents, as needed, to intercept API requests and responses. The live API traffic consisting of requests and responses may then be intercepted between user computing devices and servers at step 315. The live URL traffic, including API requests, API responses, and other communications between a server and a client device, may be forwarded to an application on a remote server at step 320. The traffic may be forwarded periodically or in response to a push, pull, or another event. In some instances, the API requests and responses may be aggregated before being reported by an agent to a remote application.
A determination is made as to whether an API request input is based at least in part on previous API response output at step 325. If the response from the remote server application is used to a subsequent request, it is possible that the request and related response are part of a session. A session of related, consecutive API requests and responses may form part of a transaction that achieves a particular goal, such as purchasing a product, making an airline reservation or a hotel reservation, or other goal. More detail for determining whether an API request input is based at least in part on a previous API response output is discussed with respect to the method of FIG. 4.
If the request input is based on the response output, the method of FIG. 3 continues to step 340, where the API request input and API response output are added to a new or existing session. The session is then stored and/or updated at step 350 with the new connection between the API request input and API response output.
If the request input is not based on the response output, the method of FIG. 3 continues to step 340, API requests and responses continue to be intercepted by one or more agents and forwarded to an application on a remote sever at step 330.
A determination is made as to whether an API request input is based at least in part on previous API request input at step 335. A first API request and a second API request may be related to each other, and part of a session, regardless of the API response received from the first request. In some instances, a subsequent API request can be related to a previous API request as part of an overall business transaction (such as making a reservation, purchasing a product, and so forth). More details for determining whether an API request input is based at least in part on previous API request input is discussed with respect to the method of FIG. 5.
If a current API request input is based at least in part on a previous API request input, then the API requests are added to a session at step 340. The session may include just the two related requests, or additional requests and/or responses that are determined to be related to one of the requests. The related API requests are stored as a session based on the connection they share at step 345. The method of FIGURE continues to operate, for example from steps 315-350, as more traffic is intercepted and API requests and responses are analyzed to determine if they are part of a new or pre-existing session. If determined to be part of a session, the requests and/or responses may be added to an existing session or form a new session, as appropriate.
If the API request input is not based at all on the previous API request input and not based at all on a previous API response output, the current API request is determined to not be associated with a session at step 350.
identified by one or more agents installed within a customer system. In some instances, determining if an API request is related to a previous intercepted API response can include comparing parameters of requests to parameters of the response. If input parameters of a requests are related to output parameters of response, the API request and response may be related. More details for identifying whether a subsequent API request is related to an intercepted API response is discussed with respect to the method of FIG. 4.
Subsequent API responses may be intercepted from the survey API to a user device at step 330. API responses from server API to user device may be intercepted by one or more agents installed at the server. In some instances, intercepted API responses may be grouped together or analyzed individually. In any case, there analyzed to determine their parameters and components for comparison purposes.
An API request from a user to a server API may be intercepted at step 335. The intercepted API requests may be intercepted by one or more agents on one or more servers, and may be analyzed by an application 172.
The most recent API requests that are related to previous intercepted API responses are identified at step 340. In some instances, to help determine if the request and response are related to each other, aspects of the request and response may be compared to each other. For example, input parameters in a request may match output parameters in a response. The input parameters and output parameters may be in a URL, header, body, in any of several different formats. By comparing the components of a request in response, API requests that are related to API responses can be identified. More information for identifying the most recent API requests related to a previous intercepted API response is discussed in more detail with respect to the method of FIG. 5.
Related APIs are stored in order as a session based on connected requests and responses at step 345. A particular API request is related to an API response, the two API portions may be part of a session. If a subsequent API request utilizes information in a previously received API response, those portions may be connected as well, and the subsequent API request may be part of the session. Related APIs may be stored as a session based on the connected requests and responses at step 345.
FIG. 4 is a method for identifying API requests related to an API response. The method of FIG. 4 provides more detail for step 325 of the method of FIG. 3. Inputs for a current API requests are accessed at step 410. Inputs may be express as queries, or other data within the URL, header, or body of the request. Outputs for previously intercepted API responses are accessed at step 420. The outputs may include data in the API response URL, header, body, or otherwise stored as data within the API response.
The API request input is compared to the API response output at step 430. A determination is made as to whether the API request input is based at least in part on the API request output at step 440. If the API request input is based on some part on API request output, the detected API request is determined to have a connection with, and be based at least in part on, on the API response at step 450. For example, if an input of the API request includes a particular product identifier that is also included in the API response, the API request is determined to be based at least in part on the API request.
If the API request input is not based at least in part on API request output, the detected API request is determined to not have a connection with the intercepted API response at step 460. As such, the request and response are determined to not be a part of a particular session.
FIG. 5 is a method for determining if an API request is based at least in part on a previous API request. The method of FIG. 5 provides more detail for step 335 of the method of FIG. 3. Inputs for a current API request are accessed at step 510. Inputs may be express as queries, or other data within the URL, header, or body of the request. Outputs for previously intercepted API responses are accessed at step 520. The outputs may include data in the API response URL, header, body, or otherwise stored as data within the API response.
The API request input is compared to the API response output at step 530. A determination is made as to whether the API request input is based at least in part on the API request output at step 540. If the API request input is based on some part on API request output, the detected API request is determined to have a connection with, and be based at least in part on, on the API response at step 550. For example, if an input of the API request includes a particular product identifier that is also included in the API response, the API request is determined to be based at least in part on the API request.
If the API request input is not based at least in part on API request output, the detected API request is determined to not have a connection with the intercepted API response at step 560. As such, the request and response are determined to not be a part of a particular session.
FIG. 6 is a method for detecting anomalous API requests based on API sessions. An API request associated with a session is detected at step 610. In some instances, each intercepted API request can be compared to a set of APIs associated with a session to determine whether the intercepted API request matches a request associated with a session.
The received API request is analyzed with respect to APIs in the session at step 620. The received API request may be analyzed to determine if the request should have a particular API request or API response precede it. Analyzing the received API request can include comparing the received API request to the set of APIs in one or more sessions to determine if any API requests should come before the received API. For example, if the received API request is a checkout request, the received API request may be expected to be preceded by a “view cart” request.
A determination is made as to whether the detected API request is expected to be preceded by a different API request in the current session at step 630. Sessions have two or more APIs that are expected to be received in a particular order. Other than the first API request in the session, each API request is preceded by a particular API within the session. As such, the determination at step 630 determines whether the received API request is received in an expected chronological order of API requests. If an API request is not preceded by an expected API, and the API request is not the first API request in the session, there may be an issue with the detected API request. If the API request that was detected was expected to be preceded by a particular API request as indicated in a stored session of APIs, but was actually preceded by a different API request, then the API request is considered an anomaly at step 650. In some instances, the API request which is not preceded by the expected API request within the current session may be an attack on the system, or just an error request. An alert can be generated for an administrator based on the determination API request is an anomaly, and the request can be analyzed further to determine if it is a mistake or an attack.
If the detected API requests is preceded by the expected API request in the current session, a subsequent API request is eventually detected at step 640. A determination is then made as to whether the subsequent API request matches an expected subsequent API in the current session at step 650. The determination at step 650 determines whether the received API request is received in an expected chronological order of API requests. If the subsequent API request does not match the expected subsequent API in the current session, the API request is labeled as an anomaly at step 650. If the API request does match the expected request within the session, a determination is made as to whether any additional APIs are expected in the current session at step 660. If additional APIs are expected, the method of FIG. 6 returns to step 640 to process subsequent API requests. If additional APIs are not expected, then the API session is determined to not be an anomaly at step 660.
FIG. 7 is a block diagram of a system for implementing machines that implement the present technology. System 700 of FIG. 7 may be implemented in the contexts of the likes of machines that implement client devices 110-140, customer server 150, Application server 170, and data store 180. The computing system 700 of FIG. 7 includes one or more processors 710 and memory 720. Main memory 720 stores, in part, instructions and data for execution by processor 710. Main memory 720 can store the executable code when in operation. The system 700 of FIG. 7 further includes a mass storage device 730, portable storage medium drive(s) 740, output devices 750, user input devices 760, a graphics display 770, and peripheral devices 780.
The components shown in FIG. 7 are depicted as being connected via a single bus 790. However, the components may be connected through one or more data transport means. For example, processor unit 710 and main memory 720 may be connected via a local microprocessor bus, and the mass storage device 730, peripheral device(s) 780, portable storage device 740, and display system 770 may be connected via one or more input/output (I/O) buses.
Mass storage device 730, which may be implemented with a magnetic disk drive, an optical disk drive, a flash drive, or other device, is a non-volatile storage device for storing data and instructions for use by processor unit 710. Mass storage device 730 can store the system software for implementing embodiments of the present invention for purposes of loading that software into main memory 720.
Portable storage device 740 operates in conjunction with a portable non-volatile storage medium, such as a floppy disk, compact disk or Digital video disc, USB drive, memory card or stick, or other portable or removable memory, to input and output data and code to and from the computer system 700 of FIG. 7. The system software for implementing embodiments of the present invention may be stored on such a portable medium and input to the computer system 700 via the portable storage device 740.
Input devices 760 provide a portion of a user interface. Input devices 760 may include an alpha-numeric keypad, such as a keyboard, for inputting alpha-numeric and other information, a pointing device such as a mouse, a trackball, stylus, cursor direction keys, microphone, touch-screen, accelerometer, and other input devices. Additionally, the system 700 as shown in FIG. 7 includes output devices 750. Examples of suitable output devices include speakers, printers, network interfaces, and monitors.
Display system 770 may include a liquid crystal display (LCD) or other suitable display device. Display system 770 receives textual and graphical information and processes the information for output to the display device. Display system 770 may also receive input as a touch-screen.
Peripherals 780 may include any type of computer support device to add additional functionality to the computer system. For example, peripheral device(s) 780 may include a modem or a router, printer, and other device.
The system of 700 may also include, in some implementations, antennas, radio transmitters and radio receivers 790. The antennas and radios may be implemented in devices such as smart phones, tablets, and other devices that may communicate wirelessly. The one or more antennas may operate at one or more radio frequencies suitable to send and receive data over cellular networks, Wi-Fi networks, commercial device networks such as a Bluetooth device, and other radio frequency networks. The devices may include one or more radio transmitters and receivers for processing signals sent and received using the antennas.
The components contained in the computer system 700 of FIG. 7 are those typically found in computer systems that may be suitable for use with embodiments of the present invention and are intended to represent a broad category of such computer components that are well known in the art. Thus, the computer system 700 of FIG. 7 can be a personal computer, handheld computing device, smart phone, mobile computing device, workstation, server, minicomputer, mainframe computer, or any other computing device. The computer can also include different bus configurations, networked platforms, multi-processor platforms, etc. Various operating systems can be used including Unix, Linux, Windows, Macintosh OS, Android, as well as languages including Java, .NET, C, C++, Node.JS, and other suitable languages.
The foregoing detailed description of the technology herein has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the technology to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. The described embodiments were chosen to best explain the principles of the technology and its practical application to thereby enable others skilled in the art to best utilize the technology in various embodiments and with various modifications as are suited to the particular use contemplated. It is intended that the scope of the technology be defined by the claims appended hereto.

Claims

What is claimed is:

1. A method for automatically detecting an anomaly based on a session of APIs received for a web service, the method comprising:

receiving, by a server from an agent stored on a remote server, an API request sent from a user device to a server API, the requests intercepted by the agent on the remote server;

comparing the received API request to a set of APIs having a preset chronological order;

detecting that the received API request is not received in an expected chronological order defined by the present chronological order; and

identifying the received API request as an anomaly based on the unexpected chronological order of the receive API request.

2. The method of claim 1, wherein detecting that the received API request is not received in an expected chronological order includes detecting that the received API request is not preceded by an expected preceding API request as specified in the preset chronological order.

3. The method of claim 1, further comprising:

receiving, by a server from an agent stored on a remote server, a subsequent API request sent from a user device to a server API; and

detecting that the received API request and the subsequent API request are not received in an expected chronological order defined by the present chronological order.

4. The method of claim 3, wherein the expected chronological order includes an API request that differs from the subsequent API request.

5. The method of claim 1, wherein the set of APIs having a preset chronological order have a first API with an output that is taken as the input of subsequent API in the set of APIs.

6. A method for automatically detecting an anomaly based on a session of APIs received for a web service, the method comprising:

receiving, by a remote server from an agent on a server, API requests received from a remote device to the server and API responses sent to the remote devices from the server;

receiving, by the remote server from the agent on the server, subsequent API requests received from a remote device to the server;

determining, by an application on the remote server, that the subsequent API requests are related to the API responses sent to the remote devices from the server;

storing the subsequent API request and the API response as a set of APIs having a preset chronological order; and

automatically identifying subsequent requests as anomalies based on a comparison of the subsequent requests with the set of APIs having a preset chronological order.

7. The method of claim 6, wherein determining includes detecting that the input of the subsequent API request is based on output of the API response.

8. The method of claim 7, wherein a query in the input of the subsequent API request matches a parameter in the output of the API response.

9. The method of claim 6, wherein the set of APIs having a preset chronological order form a business transaction provided by a web service.

10. A non-transitory computer readable storage medium having embodied thereon a program, the program being executable by a processor to perform a method for automatically detecting an anomaly based on a session of APIs received for a web service, the method comprising:

11. The non-transitory computer readable storage medium of claim 10, wherein detecting that the received API request is not received in an expected chronological order includes detecting that the received API request is not preceded by an expected preceding API request as specified in the preset chronological order.

12. The non-transitory computer readable storage medium of claim 10, the method further comprising:

13. The non-transitory computer readable storage medium of claim 12, wherein the expected chronological order includes an API request that differs from the subsequent API request.

14. The non-transitory computer readable storage medium of claim 10, wherein the set of APIs having a preset chronological order have a first API with an output that is taken as the input of subsequent API in the set of APIs.

15. A non-transitory computer readable storage medium having embodied thereon a program, the program being executable by a processor to perform a method for automatically detecting an anomaly based on a session of APIs received for a web service, the method comprising

16. The non-transitory computer readable storage medium of claim 15, wherein determining includes detecting that the input of the subsequent API request is based on output of the API response.

17. The non-transitory computer readable storage medium of claim 16, wherein a query in the input of the subsequent API request matches a parameter in the output of the API response.

18. The non-transitory computer readable storage medium of claim 15, wherein the set of APIs having a preset chronological order form a business transaction provided by a web service.

19. A system for automatically detecting an anomaly based on a session of APIs received for a web service, comprising:

a server including a memory and a processor; and

one or more modules stored in the memory and executed by the processor to receive, by a server from an agent stored on a remote server, an API request sent from a user device to a server API, the requests intercepted by the agent on the remote server, compare the received API request to a set of APIs having a preset chronological order, detect that the received API request is not received in an expected chronological order defined by the present chronological order, and identify the received API request as an anomaly based on the unexpected chronological order of the receive API request.

20. A system for automatically detecting an anomaly based on a session of APIs received for a web service, comprising:

a server including a memory and a processor; and

one or more modules stored in the memory and executed by the processor to receive, by a remote server from an agent on a server, API requests received from a remote device to the server and API responses sent to the remote devices from the server. receive, by the remote server from the agent on the server, subsequent API requests received from a remote device to the server. determine, by an application on the remote server, that the subsequent API requests are related to the API responses sent to the remote devices from the server, store the subsequent API request and the API response as a set of APIs having a preset chronological order, and automatically identify subsequent requests as anomalies based on a comparison of the subsequent requests with the set of APIs having a preset chronological order.