🤖 machine learning

MINES: Explainable Anomaly Detection through Web API Invariant Inference

The paper proposes MINES, an explainable anomaly detection system that infers API invariants from database schemas using LLMs and normal logs to generate runtime verification code, achieving state-of-the-art performance with high recall and near-zero false positives by overcoming the limitations of noisy log-based approaches.

Original authors: Wenjie Zhang, Yun Lin, Chun Fung Amos Kwok, Xiwen Teoh, Xiaofei Xie, Frank Liauw, Hongyu Zhang, Jin Song Dong

Published 2026-06-02

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Wenjie Zhang, Yun Lin, Chun Fung Amos Kwok, Xiwen Teoh, Xiaofei Xie, Frank Liauw, Hongyu Zhang, Jin Song Dong

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are the security guard for a massive, busy office building (a web application). Your job is to spot intruders or people doing things they shouldn't.

Most modern security guards (existing software) just watch the logbook. Every time someone walks through a door or uses an elevator, a line is written in the book. If the guard sees a pattern that looks weird compared to the past, they sound an alarm.

The Problem:
The paper explains that this "logbook only" approach has a fatal flaw.

The "Look-Alike" Trick: A criminal can walk through the door and sign the logbook in a way that looks exactly like a normal employee. The log says, "John entered the lobby at 9:00 AM." But in reality, John might be holding a stolen keycard, or the door might have been forced open. The logbook doesn't show the force, it just shows the result.
The Noise: Sometimes the logbook is messy. It might say, "John entered," but it doesn't tell you if John actually had a ticket to enter that specific room. The security guard gets confused by all the similar-looking entries and misses the real danger.

The Solution: MINES
The authors propose a new system called MINES. Instead of just staring at the logbook, MINES looks at the blueprints of the building and the rules of how the building is supposed to work.

Think of it like this:

Old Way (Log Learning): The guard learns that "John usually enters the lobby, then goes to the 3rd floor." If John enters the lobby and goes to the 3rd floor, the guard thinks, "All good."
MINES Way (Blueprint Inference): MINES looks at the blueprints and says, "Wait a minute. According to the building's design, you can only go to the 3rd floor if you have a 'Paid Ticket' in your pocket, and that ticket must be linked to a specific seat in the database."

MINES doesn't just read the log; it checks the log against the database (the building's master record of who owns what) and the environment (who is actually logged in).

How MINES Works (The 3-Step Process):

Translate the Blueprint: MINES takes the technical "blueprints" (API signatures and database tables) and turns them into a giant, connected map. It treats every API call (like "Cancel Order") as a character in a story and every database table (like "Orders") as a location.
Ask the AI Detective: It uses a smart AI (a Large Language Model) to look at this map and ask: "What must be true for this story to make sense?"
- Example: The AI might infer: "For a 'Cancel Order' event to be real, there must be a matching 'Order' in the database, and that order must be in a 'Paid' status."
- This is like the guard checking the blueprint to see if the rules make sense, rather than just guessing based on past logs.
The Reality Check: The AI might guess wrong (hallucinate). So, MINES runs these new rules against a pile of known "good" logs. If a rule says "John can't enter the lobby" but John did enter the lobby normally, MINES throws that rule out. It keeps only the rules that are 100% accurate.

The Result:
When an attack happens (like someone trying to refund a ticket twice), the old guards (LogRobust, LogFormer) miss it because the log looks normal. But MINES checks the database and says, "Wait, this order was already refunded! The database says it's 'Cancelled', but the log says 'Refunded'. That violates the blueprint!"

Why This is a Big Deal:

It's Smarter: It catches attacks that look perfect on paper but are fake in reality.
It's Clean: It doesn't get confused by messy logs. It focuses on the rules of the system.
It's Fast: It can check millions of logs per second.
It's Explainable: If it catches a criminal, it can point to the exact rule that was broken (e.g., "The database status didn't match the request"), rather than just saying "This looks weird."

In short, MINES stops trying to guess what's normal by reading a messy diary. Instead, it learns the laws of physics for the application and catches anyone who breaks them, even if they try to hide it in the logs.

Technical Summary: MINES – Explainable Anomaly Detection through Web API Invariant Inference

Problem Statement

Modern web applications, which serve as critical infrastructure for governments and enterprises, increasingly rely on exposed web APIs (e.g., RESTful, SOAP, WebSockets). These APIs are frequent targets for intentional attacks and unintended illegal access, leading to abnormal system behaviors. Existing log-based anomaly detection methods face two fundamental challenges:

Observability Beyond Logs (C1): True system normality often depends on information not captured in raw logs, such as specific database states (e.g., an order must be "paid" before cancellation) or session environmental information. Relying solely on instrumented logs misses these crucial causal factors.
True Invariants from Noisy Log Instances (C2): Comprehensive logging often introduces noise. Learning-based models trained on raw log instances may capture spurious correlations (e.g., a specific sequence of API calls) rather than causal relationships, leading to false positives or false negatives. Furthermore, existing rule-learning approaches often derive superficial rules from log patterns that fail when crucial context is missing from the logs.

Current state-of-the-art solutions, whether model-learning (e.g., LogRobust, LogFormer) or rule-learning (e.g., WebNorm), struggle to distinguish between normal and attack logs when the attack logs are textually similar to normal ones but violate underlying system invariants (e.g., database constraints).

Methodology: MINES

The authors propose MINES (Mining Invariants for aNomaly dEtection via Schema), a technique that infers explainable API invariants from the schema level (API signatures and database schemas) rather than detailed raw log instances. MINES treats anomaly detection as a specification mining problem.

Core Workflow

Schema Parsing and Augmentation:
- MINES parses API signatures, database schemas, and environmental information (e.g., session data).
- It converts API signatures into entity types where the API name is the entity and parameters/return values are attributes.
- These API entities are integrated with database tables and environmental entities to form an Augmented Entity-Relationship (ER) Diagram.
Relationship Inference (Stage 1):
- Using Large Language Models (LLMs), MINES infers relationships between the augmented entities:
  - API-DB Relationships: Foreign key constraints linking API parameters to database columns.
  - API-API Relationships: Temporal dependencies between different API calls.
  - API-Env Relationships: Links between API calls and session/environmental data.
- Heuristic rules (e.g., value overlap thresholds, Hidden Markov Models for sequence probability) are applied to filter out false relationships.
Invariant Generation (Stage 2):
- Based on the inferred relationships, MINES joins the relevant entity tables.
- LLMs are prompted to generate candidate invariants (constraints) on these joined tables. These invariants cover five categories: common-sense constraints, format constraints, database constraints, environment constraints, and related API constraints.
- The inferred constraints are translated into executable Python code.
Invariant Refinement:
- To mitigate LLM hallucinations and false positives, the generated invariants are validated against a collection of known normal logs.
- If an invariant raises a false alarm on normal data, the error is fed back to the LLM to revise or discard the invariant. This iterative loop continues until the invariant holds for all normal logs.
Runtime Verification:
- Offline Detection: The system operates in an offline manner. A log collector gathers runtime logs, and an offline checker executes the learned Python invariants against these logs.
- Binary Log Tracking: To address the challenge of dynamic database states, MINES replays database binary logs to reconstruct the historical database state at the time of each API invocation, ensuring accurate invariant evaluation.

Key Contributions

Methodology: A schema-based specification mining technique that unifies API signatures, database schemas, and session information to deduce causal invariants, addressing the limitations of log-only approaches.
Tool: A framework implementation for Java-based web applications that requires only API signatures and database schemas, facilitating real-world deployment.
Benchmark: A new web-tamper attack dataset comprising 31 types of attacks across Train-Ticket and NiceFish, featuring dynamic and replicable scripts to generate both normal and abnormal logs.
Evaluation: Extensive evaluation against state-of-the-art baselines (LogRobust, LogFormer, WebNorm) and generalization tests on popular industrial applications (Gitea, Mastodon, NextCloud).

Results

The evaluation demonstrates that MINES achieves a new state-of-the-art in web anomaly detection:

High Recall and Precision: On the Train-Ticket and NiceFish benchmarks, MINES achieved 100% precision and recalls of 94.8% and 91.7%, respectively. This represents a recall improvement of over 14% compared to LogRobust, LogFormer, and WebNorm.
Zero False Positives: The refinement process successfully eliminated false alarms, resulting in almost zero false positives.
Efficiency: MINES processes logs at a throughput of $4.0 \times 10^5$ logs/second on Train-Ticket, significantly faster than model-learning baselines.
Robustness:
- LLM Independence: The approach maintains high performance across different LLMs (GPT-4o, Claude 3.7, DeepSeek-V3), though smaller models like GPT-4o-mini showed slightly lower performance in code generation.
- Generalization: MINES successfully generalized to popular open-source applications (Gitea, Mastodon, NextCloud), achieving high precision and recall.
- Ablation Studies: Removing schema-based deduction or specific relationship types (API-DB, API-Env) significantly reduced recall, confirming the necessity of schema-level inference and contextual information.

Significance

The paper claims that MINES establishes a new state-of-the-art for operating web applications by shifting the paradigm from learning from noisy log instances to deducing specifications from abstract schemas. By leveraging the structural integrity between APIs and databases, MINES can detect anomalies that are invisible to log-only models, such as attacks that exploit database state inconsistencies. The approach offers high explainability (via executable Python code representing invariants) and high accuracy with minimal false positives, making it suitable for reliable web service maintenance. The authors note that while the method relies on meaningful naming conventions, it remains robust to common engineering practices and can be further enhanced with minimal documentation.