Modern applications use Application Programming Interfaces (APIs) to provide authentication, user management, object access, transactions, and other application functionality. API requests contain behavioral characteristics such as HTTP methods, request paths, parameter structures, request frequency, response status codes, and other request-level attributes that can be analyzed for security monitoring.
API abuse can occur when an attacker generates unusual requests, repeatedly accesses API resources, manipulates request parameters, or performs operations that differ from normal application behavior. Such activities may be difficult to identify when detection relies exclusively on predefined signatures or fixed rules.
In this use case, OWASP crAPI is deployed within an isolated cybersecurity laboratory. Kali Linux is used as the controlled security-testing environment, while Ubuntu Linux hosts the application and machine-learning analysis workflow.
An existing public API security dataset is used as the data source for the machine-learning stage. The available API traffic records and their associated metadata are inspected to determine whether they contain suitable normal and attack-related request information. The selected records are processed to identify features suitable for the proposed experiment.
The public dataset is processed to establish a consistent numerical representation of API-request behavior. Local Outlier Factor (LOF), implemented through Scikit-learn, is used to identify observations whose local density differs significantly from the surrounding request population. LOF measures local density deviations rather than relying solely on a global boundary.
The trained anomaly-detection workflow is then evaluated using API requests generated by normal application activity and a controlled abnormal API-call scenario against the local OWASP crAPI application. The controlled test is performed only within the authorized laboratory.
Captured API requests are processed using the same feature-extraction pipeline used during training. The LOF model analyzes compatible request features and produces an anomaly prediction and associated score. The results are compared with the known laboratory test conditions to evaluate whether the selected behavioral features help identify abnormal activity.
Application: OWASP crAPI
OWASP crAPI stands for Completely Ridiculous API. It is an intentionally vulnerable, API-driven application designed for security education, training, and testing. It provides API security scenarios that can be explored within an authorized laboratory environment.
In this use case, OWASP crAPI is deployed locally to generate normal API activity and controlled security-testing traffic.
API-driven applications may receive legitimate requests alongside unusual or potentially malicious API activity. Abnormal behavior can include unexpected request patterns, unusual parameter combinations, repeated access attempts, or request characteristics that differ from the normal application baseline.
Traditional signature-based detection may identify known patterns but can miss behavioral variations that do not match predefined signatures. Fixed thresholds can also produce false alerts when legitimate application behavior varies.
Behavioral anomaly detection provides an additional approach by learning the characteristics of a normal request population and identifying observations that differ from the local behavioral patterns.
The proposed solution uses an existing public API security dataset to prepare the training data, app lies Local Outlier Factor to suitable numerical request features, and evaluates the resulting detection workflow against normal and controlled abnormal API activity generated in the laboratory.
Specific Attack: Controlled Abnormal API-Call Attack Against OWASP crAPI
The controlled attack scenario evaluates whether unusual API-call behavior can be identified by the proposed LOF-based anomaly-detection workflow.
OWASP crAPI is deployed within the isolated laboratory environment. Kali Linux is used as the authorized security-testing system, while Ubuntu Linux hosts the application and analysis components.
The test begins with legitimate API activity to establish a baseline for the selected application operations. A controlled abnormal API-call scenario is then performed against the local application. The scenario generates requests that differ from the baseline according to selected, observable request characteristics.
The test may include an unusual sequence of requests or repeated access attempts against an authorized test endpoint. The exact test behavior is selected after the application endpoints and public dataset features have been reviewed. The experiment does not assume that every abnormal request is malicious; the known test condition is retained separately for evaluation.
The resulting API requests are captured and transformed into numerical features using the same preprocessing procedure applied to the training data.
LOF analyzes the request features and identifies observations that differ from their local behavioral neighborhood. The resulting predictions are compared with the known laboratory activity to assess detection effectiveness.
Local Outlier Factor-Based API Behavioral Anomaly Detection
The primary security concept is Behavioral Anomaly Detection Using Local Outlier Factor.
The first objective is to establish a suitable representation of API-request behavior using an existing public API security dataset. The available records are inspected to determine which request fields can be used consistently for model training and later laboratory testing.
The second objective is to apply Local Outlier Factor to the processed numerical features. LOF estimates the local density of observations and compares each observation with the local density of its nearest neighbors. An observation with substantially lower local density may be identified as an outlier.
The third objective is to validate the anomaly-detection workflow using API requests generated by the local OWASP crAPI application. The captured requests are transformed into compatible features and analyzed by the trained model.
The final objective is to compare the model output with the known test conditions and determine whether the selected features help distinguish the controlled abnormal activity from the observed normal behavior.
The security concept defines the overall security strategy.
The following are the specific defensive mechanisms implemented.
Normal API-request characteristics are processed to establish a behavioral representation of the selected request population.
LOF analyzes the local density of request-feature observations and identifies observations that differ from their nearest neighbors.
The same fitted preprocessing and feature-extraction configuration is applied to training data and compatible newly captured requests.
API requests generated during normal application activity and controlled testing are captured for analysis.
Requests identified as anomalous by LOF are marked for further security review.
The anomaly predictions are compared with the known controlled test conditions.
The results are assessed using available ground-truth information and controlled test evidence.
OWASP crAPI provides the intentionally vulnerable API environment used for controlled security testing.
Kali Linux provides the controlled security-testing environment.
Ubuntu Linux hosts the local application and/or machine-learning analysis components according to the laboratory configuration.
VirtualBox provides the isolated laboratory infrastructure.
OWASP ZAP is used to inspect HTTP requests and responses associated with the local API testing.
cURL is used to send reproducible HTTP/API requests to the authorized laboratory application.
Nmap is used to identify services exposed by the authorized laboratory environment.
Python provides the primary implementation environment for the anomaly-detection workflow.
Scikit-learn provides the Local Outlier Factor implementation.
Pandas is used to load, filter, transform, and organize the existing dataset and captured API records.
NumPy supports numerical operations during feature preparation and model processing.
An existing public API security dataset is used to obtain API-request records for the machine-learning experiment. The available records, metadata, and labels are examined to determine their suitability for normal behavioral analysis and anomaly-detection evaluation
SQLite provides local storage for captured requests and detection results.
OWASP crAPI is deployed within an isolated VirtualBox laboratory to provide a controlled environment for API security testing.
The public Cisco–Ariel University API Security Challenge dataset is obtained and inspected to determine whether its available request records and metadata support the planned anomaly-detection experiment.
Suitable normal request records are selected from the existing dataset and processed into numerical features without manually fabricating the training dataset.
The Local Outlier Factor model is trained using the selected behavioral features, establishing a baseline for identifying observations that differ from their local neighborhood.
Normal API activity generated by OWASP crAPI is captured and processed using the same feature-extraction workflow, validating whether the training and laboratory request representations are compatible.
A controlled abnormal API-call scenario is performed against the local OWASP crAPI application using Kali Linux, generating known test activity for detection validation.
The captured requests are transformed into compatible numerical features and analyzed by the trained LOF model to produce anomaly predictions and associated scores
The model predictions are compared with the known laboratory test conditions to assess whether the selected features help identify the controlled abnormal API behavior
SQLite stores the relevant request metadata, model predictions, anomaly scores, and evaluation results, providing a structured record of the experiment.
The complete workflow demonstrates public-dataset preparation, normal behavior selection, LOF training, controlled API attack simulation, request capture, behavioral feature extraction, anomaly detection, and evidence-based validation. The final assessment documents the observed detection results and limitations without claiming that LOF automatically prevents or blocks attacks.
Research Breakthrough Possible @S-Logix