State Token Security for Single Page Applications

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Single page applications (SPAs) are vulnerable to data mining and unauthorized access due to client-side API call construction and lack of effective rate limits, allowing malicious users to exploit APIs for unauthorized data retrieval and manipulation.

Innovation Solution

A Finite State Machine (FSM) based security scheme is implemented, where tokens are generated and verified by the API server to ensure that users navigate through states in a specific order, preventing orchestrated calls by malicious users and making data mining attacks more expensive or time-consuming.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Speed

If client-side API call construction is used in SPAs, then application responsiveness and loading speed are improved, but security is worsened because API methodologies become visible to malicious users

Engineering Contradiction:
Improveapplication loading speedVSAvoidAPI vulnerability to attack
Core Design Contradiction:
SpeedVSObject-affected harmful factors

Solution Approach 1:

The patent introduces a state token as an intermediary between the client and API server. The state token encodes the application state and validates API requests without exposing the actual API construction methodology. This mediator allows fast client-side rendering while preventing malicious users from exploiting visible API structures, as the state token validates requests based on encoded state rather than exposed API methodologies.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Object-affected harmful factors

If rate limits are imposed on API calls, then data mining attacks are slowed down, but legitimate user productivity is reduced due to unnecessary call restrictions

Engineering Contradiction:
Improvedata mining attack preventionVSAvoidlegitimate user API access
Core Design Contradiction:
Object-affected harmful factorsVSProductivity

Solution Approach 1:

The patent changes the validation parameter from simple rate limiting to state token verification. Instead of counting and limiting API calls, the system validates whether each request corresponds to a legitimate state transition encoded in the state token. This allows legitimate users to make unlimited API calls as needed while automatically preventing data mining attacks, as malicious requests cannot produce valid state tokens and will be rejected regardless of call frequency.

Inventive Principle:
Principle #35Parameter changes

3Reliability

If traditional server-side security is used, then API protection is improved, but application responsiveness is worsened due to continuous server validation requirements

Engineering Contradiction:
ImproveAPI securityVSAvoidapplication responsiveness
Core Design Contradiction:
ReliabilityVSSpeed

Solution Approach 1:

The patent performs security validation in advance by encoding the application state and valid transition paths into the state token before API calls are made. The state token pre-contains the authorization information needed for subsequent API requests. This eliminates the need for continuous server-side validation during API calls, as the client can validate requests locally using the pre-encoded state token, thereby maintaining both security and responsiveness.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS11381555B2State token based approach to secure web applications
Publication Date: 2022.07.05 T MOBILE US INC
  • US11381555B2 patent drawing
  • US11381555B2 patent drawing
  • US11381555B2 patent drawing

AI summary

Techniques for securing a single page application (SPA) are provided. An API server that receives an API call from an SPA to navigate a first user to a first state of the SPA navigates the first user to the first state of the SPA and generates a first token indicating that the first user has accessed the first state of the SPA. When the API server receives a request from the first user to navigate to a second state of the SPA (the request including the first token), the API server verifies that the first token indicating that the first user has accessed the first state of the SPA is valid for the second state of the SPA before navigating the first user to the second state of the SPA. Additionally, the API server expires the first token upon navigating the first user to the second state of the SPA.