Web Application API Protection via Transaction Sequence Analysis

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing cybersecurity systems are inefficient in detecting and preventing web application and API-based attacks, particularly zero-day attacks, due to reliance on manual configuration of security policies and inability to analyze transaction sequences holistically.

Innovation Solution

A protection system that employs artificial intelligence and machine learning to analyze sequences of layer 7 transactions using a scoring model that integrates inputs from anomaly and attack models, enabling real-time detection and mitigation of malicious transactions.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If manual configuration of WAAP policies is used, then security coverage for known attack patterns is achieved, but configuration time and complexity increase significantly

Engineering Contradiction:
Improvesecurity coverageVSAvoidconfiguration time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system performs self-configuration by automatically crawling the web application, analyzing its structure and behavior, and generating security policies without requiring manual intervention. The WAAP autonomously identifies attack paths and configures protection rules based on its own analysis of the application's HTTP requests, responses, and transaction sequences.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The system performs preliminary crawling and analysis of the web application before actual attacks occur. By proactively mapping the application structure, identifying vulnerable paths, and pre-configuring security policies, the system prepares protection measures in advance rather than reacting to threats after they manifest.

Inventive Principle:
Principle #10Preliminary action

2Reliability

If manual configuration of WAAP policies is used, then security coverage for known attack patterns is achieved, but the quality of configuration is prone to human error

Engineering Contradiction:
Improvesecurity coverageVSAvoidconfiguration quality
Core Design Contradiction:
ReliabilityVSManufacturing precision

Solution Approach 1:

The system performs self-configuration by automatically crawling the web application, analyzing its structure and behavior, and generating security policies without requiring manual intervention. The WAAP autonomously identifies attack paths and configures protection rules based on its own analysis of the application's HTTP requests, responses, and transaction sequences.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The patent replaces manual mechanical configuration processes with automated computer-based analysis. Instead of human operators manually defining security rules, the system uses automated crawling, parsing, and machine learning algorithms to generate precise configuration rules based on actual application behavior data.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

3Stability of the object's composition

If static WAAP policies are enforced, then configuration stability is maintained, but adaptability to dynamic application changes is lost

Engineering Contradiction:
Improvepolicy stabilityVSAvoidadaptability to changes
Core Design Contradiction:
Stability of the object's compositionVSAdaptability or versatility

Solution Approach 1:

The system transitions from static to dynamic policy enforcement by continuously monitoring application changes and automatically updating security configurations. The WAAP re-crawls the application periodically or upon detecting changes, analyzes new transaction patterns, and adapts security policies in real-time to match the current application state.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The system implements feedback mechanisms where the WAAP monitors application behavior, attack attempts, and configuration effectiveness, then uses this information to continuously improve and update security policies. The feedback loop enables the system to learn from actual usage patterns and refine its protection strategies over time.

Inventive Principle:
Principle #23Feedback

4Speed

If individual transaction analysis is performed, then processing speed is maintained, but detection capability for complex attack sequences is insufficient

Engineering Contradiction:
Improveprocessing speedVSAvoidattack detection capability
Core Design Contradiction:
SpeedVSDifficulty of detecting and measuring

Solution Approach 1:

The system merges multiple analysis dimensions by combining individual transaction evaluation with sequence-level pattern recognition. The WAAP analyzes not only single requests but also the temporal and contextual relationships between multiple transactions, integrating them into a unified security assessment that captures attack patterns across request sequences.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The patent adds a temporal and contextual dimension to transaction analysis by examining sequences of requests rather than isolated individual transactions. This dimensional expansion allows the system to detect attack patterns that unfold across multiple time steps and contextual states while maintaining efficient processing through structured analysis frameworks.

Inventive Principle:
Principle #17Another dimension (Dimensionality change)

Data Source

PatentUS20250141901A1Web application and application programming interface (API) protection
Publication Date: 2025.05.01 RADWARE LTD
  • US20250141901A1 patent drawing
  • US20250141901A1 patent drawing
  • US20250141901A1 patent drawing

AI summary

Apparatus for filtering transactions transmitted from a source to a protected entity, comprising: a transaction filter enforcer which receives a layer 7 transaction destined for a protected application prior to the transaction possibly being supplied to the protected entity; and an evaluator receiving the transaction from the enforcer; the enforcer routing the transaction to the protected entity when the transaction does not receive a determination as being malicious from the evaluator; the evaluator including at least a model that determines a score indicative of the maliciousness of the transaction based on input from at least one trained model, the transaction being supplied to each of the at least one trained model, each of which is a model from a set of model types, the model types including an anomaly model and an attack model; the enforcer operating in real-time and the evaluator operating in at least near real-time.