An AI-driven modern web application browser client storage sensitive information intelligent detection method and system, electronic equipment and storage medium

Abstract

The application provides an AI-driven modern WEB application browser client storage sensitive information intelligent detection method and system, electronic equipment and storage medium. It belongs to the technical field of network security. The method comprises the following steps: injecting a Hook script through a no-interface browser driver based on a CDP protocol, combining a Trace ID to realize causal tracing of storage writing and business operation; adopting a double dynamic waiting strategy to guarantee data integrity, realizing full volume traversal of IndexedDB through a Promise chain encapsulation; constructing a four-layer progressive intelligent identification engine composed of key name semantic identification, field value format identification, JSON structure recursive analysis and Shannon entropy analysis to accurately identify sensitive information; calculating a risk score through a multi-dimensional weighted scoring model to generate a structured report. The application effectively solves the problems of modern SPA application storage sensitive information difficult to detect, difficult to trace and high false positive rate, and significantly improves the efficiency and accuracy of Web security automated detection.

Description

Technical Field

[0001] This invention belongs to the field of network security technology, and in particular relates to an AI-driven intelligent detection method, system, electronic device and storage medium for storing sensitive information in modern web application browser clients. Background Technology

[0002] With the widespread adoption of front-end / back-end separation architectures and Single Page Applications (SPAs), modern web applications extensively utilize browser client-side storage mechanisms to maintain user state, including localStorage, sessionStorage, cookies, and IndexedDB. Developers often write identity tokens and personal information in plaintext to client-side storage, posing serious security risks.

[0003] Existing web security testing tools (such as Burp Suite and OWASP ZAP) are essentially based on the "HTTP message level" testing paradigm. They have fundamental flaws such as being unable to detect locally stored data, being unable to trigger dynamic route writing, lacking structured semantic analysis capabilities, and completely not covering IndexedDB, thus failing to meet the security testing needs of SPA applications. Summary of the Invention

[0004] To address the aforementioned technical problems, this invention proposes an AI-driven intelligent detection method for storing sensitive information in modern web application browser clients, aiming to solve the issues of lack of storage awareness, difficulty in tracing the source, and high false alarm rate in existing tools for SPA applications.

[0005] The first aspect of this invention discloses an AI-driven intelligent detection method for storing sensitive information in modern web application browser clients; the method includes: Step S1: Real-time interception of browser driver and storage write based on CDP protocol; inject storage API proxy script before the target page is loaded, and realize accurate business traceability of high-concurrency asynchronous storage write through the traceability mechanism of globally unique Trace ID, while performing dual dynamic waiting judgment based on network quiet period and DOM stable period. Step S2: Full data collection of four types of client storage media; After the dual waiting conditions are met, full data collection is performed on localStorage, sessionStorage, Cookie and IndexedDB, and uniformly encapsulated into a standardized storage record structure; Step S3: Intelligent identification of sensitive information based on multi-level rules and statistical feature reasoning engine; perform four progressive identifications on the collected storage records in sequence: key name semantic identification, field value format identification, JSON structure recursive parsing and Shannon entropy analysis, and output the list of hit records and confidence level; Step S4: Security level assessment based on a multi-dimensional weighted scoring model; calculate the comprehensive risk score for each hit record by combining the type of sensitive information, storage location, encryption status, and identification confidence. Step S5: Generate a structured inspection report; Based on the risk score, determine the security level and generate a structured report containing de-identified data, source tracing path, and remediation suggestions.

[0006] Furthermore, in step S1, the tracing mechanism for the globally unique Trace ID includes: Before each action instruction is executed, a global Trace ID containing the operation type, sequence number, and timestamp is synchronously injected into the browser context via CDP Runtime.evaluate; When the storage agent interception script captures a write event, it synchronously reads the current Trace ID and writes it to the record as a tracing field. For asynchronous writes, an asynchronous association window with a set duration is opened, and all storage writes within the window are forcibly associated with the Trace ID that triggered the asynchronous chain.

[0007] Furthermore, in step S1, the dual dynamic waiting determination includes: Network quiet period determination: By proxying XMLHttpRequest and fetch, a global in-flight request counter is maintained. The condition is determined to be met when the counter is 0 for a consecutive set period of time. DOM stability period determination: By injecting MutationObserver to listen for DOM changes, a condition is determined when the set time threshold has been exceeded since the last change.

[0008] Furthermore, in step S2, a three-stage asynchronous traversal algorithm is used for the full collection of IndexedDB: Phase 1: Obtain the list of databases using indexedDB.databases(); Phase 2: Encapsulate a Promise request for each database to retrieve all ObjectStores; The third stage involves wrapping each ObjectStore with an openCursor cursor using a Promise and iterating through all records recursively in the onsuccess callback, thus transforming the DOM event-based callback chain into a Promise chain that can be synchronously waited for by CDP.

[0009] Furthermore, in step S3, the specific execution order and rules of the four-layer progressive identification are as follows: The first layer is key name semantic recognition: using substring matching to filter key names, and assigning an initial confidence score if a match is found. The second layer is field value format recognition: regular expression matching is performed on key values, and supplementary verification algorithms such as weighted modulo 11 check, Luhn algorithm and JWT decoding verification are introduced for specific types to update the confidence level; The third layer is the recursive parsing of the JSON structure: if the key value is in JSON format, it is deserialized and then recursively traversed in a depth-first manner. The first and second layers of identification are repeated for leaf nodes. WeakSet is used to prevent circular references and set a maximum depth limit. The recursive parsing of the JSON structure is as follows: If the key value is in JSON format, WeakSet is used during the parsing process to prevent circular references and set a maximum depth limit. The values ​​of all leaf nodes are extracted, and the first and second level checks are repeatedly performed on the value of each leaf node. The fourth layer, Shannon entropy analysis: For records that were not matched in the first three layers but whose key names are suspicious, calculate the information entropy. If the entropy value is greater than the preset threshold and the length meets the requirements, it is judged as a suspected high-strength random credential.

[0010] Furthermore, the supplementary verification algorithm specifically includes: performing weighted modulo 11 verification on suspected ID card numbers; performing Luhn algorithm verification on suspected bank card numbers; and performing Base64URL decoding and internal field structure verification on suspected JWT tokens.

[0011] Furthermore, in step S4, the formula for calculating the comprehensive risk score is: S = W_type × C_storage × C_encrypt × Conf; Where W_type is the information type weight, C_storage is the storage location coefficient, C_encrypt is the encryption state coefficient, and Conf is the identification confidence level.

[0012] A second aspect of this invention discloses an AI-driven intelligent detection system for storing sensitive information in modern web application browser clients; the system includes: Behavior simulation and interception module: used to parse behavior scripts, drive browser operations through CDP, inject Hook scripts to achieve Trace ID injection and storage interception, and perform dual dynamic wait; Full data collection module: used to read and standardize stored data from localStorage, sessionStorage, Cookie, and IndexedDB; Sensitive information identification engine module: used to perform a four-layer progressive detection including key name semantic recognition, format recognition, JSON recursive parsing, and entropy analysis; Assessment and Reporting Module: Used to calculate the overall risk score, assess the safety level, and output a structured inspection report.

[0013] A third aspect of this invention discloses an electronic device. The electronic device includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it implements the steps of the AI-driven intelligent detection method for storing sensitive information in a modern web application browser client, as described in any of the first aspects of this disclosure.

[0014] A fourth aspect of this invention discloses a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the AI-driven intelligent detection method for storing sensitive information in a modern web application browser client, as described in any of the first aspects of this disclosure.

[0015] In summary, the solution proposed in this invention can: 1. It breaks through the static crawling blind spots of traditional security tools and can fully perceive the complete storage write in dynamic rendering and high-concurrency asynchronous environments.

[0016] 2. The combination of the Trace ID mechanism and asynchronous windows accurately establishes the causal relationship between "business operation and stored result", improving the operability of the test report.

[0017] 3. The unique four-layer inference engine effectively avoids the bottleneck of regular expression calculation and DOM blocking issues, improving detection speed and greatly reducing false positives and false negatives. Attached Figure Description

[0018] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating an AI-driven intelligent detection method for storing sensitive information in a modern web application browser client, according to an embodiment of the present invention. Figure 2 A flowchart illustrating an AI-driven intelligent detection method for storing sensitive information in a modern web application browser client, provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of a headless browser driver and storage write interception provided in an embodiment of the present invention; Figure 4This is a flowchart of data deduplication and desensitization processing provided in an embodiment of the present invention; Figure 5 This is a diagram illustrating the architecture of a three-layer sensitive data identification mechanism provided in an embodiment of the present invention. Figure 6 A flowchart illustrating the model fine-tuning and deployment process provided in this embodiment of the invention; Figure 7 This is a diagram illustrating the intelligent alarm and evidence retention provided in an embodiment of the present invention. Figure 8 This is a schematic diagram of the overall system architecture provided for an embodiment of the present invention; Figure 9 This is an example diagram of a business traceability link provided in an embodiment of the present invention; Figure 10 This is a schematic diagram showing the comparison of detection results provided in an embodiment of the present invention; Figure 11 This is a structural diagram of an AI-driven intelligent detection system for storing sensitive information in a modern web application browser client, according to an embodiment of the present invention. Figure 12 This is a structural diagram of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] The first aspect of this invention discloses an AI-driven intelligent detection method for storing sensitive information in modern web application browser clients, particularly relating to storage data acquisition technology based on a headless browser, a recognition algorithm based on a multi-level rule and statistical feature hybrid inference engine, and a multi-dimensional scoring method.

[0022] The core solution of this invention includes: 1. CDP-driven and precise causal tracing: Based on the CDP protocol of a headless browser, Hook scripts are injected. By injecting a global Trace ID and using an asynchronous associated window mechanism, precise causal tracing of storage write events and business operations can be achieved.

[0023] 2. Dual Dynamic Waiting and Full Data Collection: Dual dynamic waiting conditions are constructed by proxying network requests and listening to the DOM; combined with Promise chain encapsulation technology, the problem of asynchronous traversal of IndexedDB based on DOM event callbacks is overcome, and standardized full data collection of four types of media is achieved.

[0024] 3. Four-layer intelligent recognition engine: Construct a sequential and progressive recognition architecture that executes in the order of "key name semantic coarse screening → field value format fine judgment (regular expression and algorithm verification) → JSON recursive parsing → entropy value fallback analysis", which reduces the false alarm rate while reducing computing power overhead.

[0025] 4. Multidimensional weighted risk assessment: Calculates risk scores from four dimensions: information type, storage location, encryption status, and confidence level, and outputs an executable security report.

[0026] Example 1: Figure 1 This is a flowchart illustrating an AI-driven intelligent detection method for storing sensitive information in a modern web application browser client, according to an embodiment of the present invention. Figure 1 As shown, the method includes: Step S1: Real-time interception of browser driver and storage write based on CDP protocol; inject storage API proxy script before the target page is loaded, and realize accurate business traceability of high-concurrency asynchronous storage write through the traceability mechanism of globally unique Trace ID, while performing dual dynamic waiting judgment based on network quiet period and DOM stable period. The tracing mechanism for the globally unique Trace ID includes: Before each action instruction is executed, a global Trace ID containing the operation type, sequence number, and timestamp is synchronously injected into the browser context via CDP Runtime.evaluate; When the storage agent interception script captures a write event, it synchronously reads the current Trace ID and writes it to the record as a tracing field. For asynchronous writes, an asynchronous association window with a set duration is opened, and all storage writes within the window are forcibly associated with the Trace ID that triggered the asynchronous chain.

[0027] The dual dynamic waiting determination includes: Network quiet period determination: By proxying XMLHttpRequest and fetch, a global in-flight request counter is maintained. The condition is determined to be met when the counter is 0 for a consecutive set period of time. DOM stability period determination: By injecting MutationObserver to listen for DOM changes, a condition is determined when the set time threshold has been exceeded since the last change.

[0028] Step S2: Full data collection of four types of client storage media; After the dual waiting conditions are met, full data collection is performed on localStorage, sessionStorage, Cookie and IndexedDB, and uniformly encapsulated into a standardized storage record structure; A three-stage asynchronous traversal algorithm is used for the full data collection of IndexedDB: Phase 1: Obtain the list of databases using indexedDB.databases(); Phase 2: Encapsulate a Promise request for each database to retrieve all ObjectStores; The third stage involves wrapping each ObjectStore with an openCursor cursor using a Promise and iterating through all records recursively in the onsuccess callback, thus transforming the DOM event-based callback chain into a Promise chain that can be synchronously waited for by CDP.

[0029] Step S3: Intelligent identification of sensitive information based on multi-level rules and statistical feature reasoning engine; perform four progressive identifications on the collected storage records in sequence: key name semantic identification, field value format identification, JSON structure recursive parsing and Shannon entropy analysis, and output the list of hit records and confidence level; The specific execution order and rules of the four-layer progressive identification are as follows: The first layer is key name semantic recognition: using substring matching to filter key names, and assigning an initial confidence score if a match is found. The second layer is field value format recognition: regular expression matching is performed on key values, and supplementary verification algorithms such as weighted modulo 11 check, Luhn algorithm and JWT decoding verification are introduced for specific types to update the confidence level; The third layer is the recursive parsing of the JSON structure: if the key value is in JSON format, it is deserialized and then recursively traversed in a depth-first manner. The first and second layers of identification are repeated for leaf nodes. WeakSet is used to prevent circular references and set a maximum depth limit. The recursive parsing of the JSON structure is as follows: If the key value is in JSON format, WeakSet is used during the parsing process to prevent circular references and set a maximum depth limit. The values ​​of all leaf nodes are extracted, and the first and second level checks are repeatedly performed on the value of each leaf node. The fourth layer, Shannon entropy analysis: For records that were not matched in the first three layers but whose key names are suspicious, calculate the information entropy. If the entropy value is greater than the preset threshold and the length meets the requirements, it is judged as a suspected high-strength random credential.

[0030] The supplementary verification algorithm specifically includes: performing weighted modulo 11 verification on suspected ID card numbers; performing Luhn algorithm verification on suspected bank card numbers; and performing Base64URL decoding and internal field structure verification on suspected JWT tokens.

[0031] Step S4: Security level assessment based on a multi-dimensional weighted scoring model; calculate the comprehensive risk score for each hit record by combining the type of sensitive information, storage location, encryption status, and identification confidence. The formula for calculating the comprehensive risk score is as follows: S = W_type × C_storage × C_encrypt × Conf; Where W_type is the information type weight, C_storage is the storage location coefficient, C_encrypt is the encryption state coefficient, and Conf is the identification confidence level.

[0032] The automatic determination of the C_encrypt encryption state coefficient is performed according to the following priority: Strong encryption: The entropy value meets a set high threshold and is not a pure hexadecimal character set; Weak encryption / hash value: fixed length and a pure hexadecimal character set; Base64 encoding: conforms to the Base64 regular expression and has a length that is a multiple of 4; Plain text: If the above conditions are not met, the character set is ordinary printable characters and the entropy value is low.

[0033] Step S5: Generate a structured inspection report; Based on the risk score, determine the security level and generate a structured report containing de-identified data, source tracing path, and remediation suggestions.

[0034] Example 2: This embodiment provides an AI-driven intelligent detection method for storing sensitive information in modern web application browser clients. The method is as follows: Combination Figure 2 As shown, in step S1, the browser driver and storage write are intercepted in real time through the CDP protocol; the storage API proxy script is injected before the target page is loaded, and the source tracing mechanism of the globally unique Trace ID is used to achieve accurate business tracing of high-concurrency asynchronous storage write, while the dual dynamic waiting judgment is based on the network silent period and the DOM stable period. Programmatic control of a headless browser is achieved through the Chrome DevTools Protocol (CDP). Before the target page loads, the system uses the CDP's `Page.addScriptToEvaluateOnNewDocument` interface to inject a storage API proxy script (Storage API Hook Script) into the page. This intercepts the native storage interface before the page's own scripts execute, ensuring that no storage write operations are missed. The hook interception principle is as follows... Figure 2 As shown.

[0035] The interception mechanism of the storage API proxy script is as follows: For localStorage and sessionStorage, the property descriptor of Storage.prototype.setItem is redefined using the Object.defineProperty method, and the original setItem method is wrapped with a Proxy object. When the page script calls setItem(key, value), the proxy layer synchronously records the key name, key value, current timestamp, and call stack information (obtained through new Error().stack) before calling the original method, and stores the records in the global monitoring buffer. For cookies, the setter descriptor of the document.cookie property is intercepted using Object.defineProperty, capturing the string content written each time a cookie is written. The above interception does not affect the normal execution of the original storage function and is completely transparent to the target page.

[0036] User behavior simulation sequences are described using JSON-formatted behavior scripts. Each instruction includes the operation type (navigate, click, fill, wait), the target CSS selector, and parameter fields. The system parses and executes the behavior scripts sequentially, driving the browser to complete core business operations such as login, viewing personal information, and submitting forms, thereby triggering a complete storage write operation.

[0037] To achieve a precise causal relationship between write events and business operations, and addressing the challenge of tracing high-concurrency asynchronous storage writes in modern web applications (e.g., writing to localStorage only 2 seconds after clicking the submit button), the system employs a Trace ID injection scheme to achieve accurate causal correlation, rather than relying on unreliable timestamp range estimation. The specific implementation is as follows: During the Hook script initialization phase, the system synchronously injects a global event tracker (EventTracer) via CDP Page.addScriptToEvaluateOnNewDocument. Before each action instruction (navigate / click / fill) is executed, the tracker writes a unique identifier for the current operation, window.__opTraceId, to the window object, in the format of "operation type_serial number_timestamp" (e.g., "click_003_1713200000123").

[0038] The Storage proxy interception script (the Proxy handler for Storage.prototype.setItem) synchronously reads the current value of window.__opTraceId and writes it as the origin_op_trace field to StorageRecord each time a write event is captured.

[0039] Associative accuracy guarantee: (a) The JavaScript engine is single-threaded, and synchronous operations within the same event loop tick will necessarily carry the same opTraceId; (b) For asynchronous writes triggered by the micro-task queue (Promise.then / async-await), the system opens a configurable asynchronous association window (default 3000 milliseconds) after the action instruction is executed. All writes within the window are automatically associated with the business operation node that triggered the asynchronous chain, realizing a precise causal relationship between "storage write 2 seconds later" and "triggering business operation".

[0040] To achieve accurate cross-process transmission of Trace ID between the Python backend process and the browser JS context, the system uses the CDP Runtime.evaluate interface to synchronously inject the Trace ID before each DOM operation, ensuring that the Hook script reads the current operation identifier when capturing and writing.

[0041] The JSON behavior script instructions in the BehaviorDriver module are executed strictly serially. This means that the system only executes the next behavior instruction after the asynchronous associated window of the current instruction (default 3000 milliseconds) has closed and completed a double dynamic wait check. This mechanism ensures that there is only one active operation Trace ID at any given time, completely eliminating Trace ID ambiguity caused by concurrent operations and providing a robust logical loop for this technology.

[0042] Existing Storage Hook technology can only record "when and what data was written", but cannot answer "which user action triggered the write". This technical bias is particularly prominent in SPA applications - due to the asynchronous state management of the framework layer (Vuex actions / Pinia async actions / Redux thunks), after the user clicks the "commit" button, the storage write may not actually occur until hundreds to thousands of milliseconds later through multiple layers of asynchronous call chains, and the event and the result are completely separated in both time and call stack dimensions.

[0043] This invention overcomes the aforementioned technical biases by using a global Trace ID + asynchronous time window forced binding mechanism: it generates a globally unique operation identifier (Trace ID) for each automated action, injects the browser JS context before DOM operations using CDPRuntime.evaluate, and sets a configurable asynchronous association window (default 3000 milliseconds), forcibly associating all asynchronous storage write events intercepted by Hook within this window with the Trace ID.

[0044] This mechanism, based on the JavaScript single-threaded event loop model, achieves precise causal tracing of "operation behavior → stored result" in a high-concurrency asynchronous environment, solving the long-standing technical challenge of "spatiotemporal separation of events and stored results" in SPA application security testing. Those skilled in the art typically use timestamp range estimation (e.g., "all writes within 5 seconds of a click") for correlation, but this method can lead to serious ambiguity when multiple operations are executed rapidly and continuously. This invention fundamentally eliminates ambiguity and achieves deterministic causal tracing through deterministic transmission of Trace IDs (rather than probabilistic estimation of timestamps) and serialized instruction execution (ensuring only one active Trace ID at any given time).

[0045] To ensure that dynamically rendered page content and asynchronous storage operations are fully captured, the system adopts a dual dynamic waiting strategy: first, it waits for a network quiet period (no new XHR / Fetch requests within 500 milliseconds); second, it listens for DOM changes through MutationObserver, and only executes the next operation after the DOM stabilizes (no structural changes within 300 milliseconds).

[0046] The specific implementation details of the dual dynamic wait strategy are as follows: (1) Specific implementation of network quiet period monitoring: The system uses CDP Page.addScriptToEvaluateOnNewDocument to proxy and encapsulate window.XMLHttpRequest and window.fetch during page initialization, and maintains a global in-flight request counter window.__inflightCount. The counter is incremented by 1 each time XHR calls open / send; the counter is decremented by 1 each time XHR triggers a loadend or error event; for fetch, the counter is counted using Promise.resolve(originalFetch(...)).finally(() =>inflightCount--).

[0047] The key design points of the above implementation are: (a) The Fetch proxy uses the async / await syntax to maintain the same Promise semantics as the original fetch, making it transparent to the caller; (b) Use try...finally to ensure that the counter decrements correctly even under abnormal paths (network errors, request timeouts, response parsing failures), to prevent counter leakage from causing the network silent period determination to fail permanently; (c) The XHR proxy listens for both loadend and error events, covering both success and exception paths. The two proxies share a global counter window.__inflightCount, which the CDP backend periodically polls using Runtime.evaluate to determine the network inactivity period.

[0048] The CDP backend calls Runtime.evaluate every 50 milliseconds to read window.__inflightCount. When the value is continuously 0 for 500 milliseconds, it is determined that the network silent period has been reached (equivalent to the CDP layer's Network.requestWillBeSent / loadingFinished event count implementation).

[0049] (2) Specific implementation of DOM stability period monitoring: Inject a MutationObserver into the page using CDP Runtime.evaluate to listen for changes in the child nodes and properties of document.body and all its subtrees (subtree: true). Execute window.__lastMutationTs = performance.now() each time a callback is triggered.

[0050] When the CDP backend detects that the difference between the current time and window.__lastMutationTs exceeds 800 milliseconds, it determines that DOM rendering has stabilized.

[0051] Only when both conditions are met simultaneously will the system trigger the full data acquisition process in step S2, ensuring that no storage writes are missed after asynchronous rendering is completed.

[0052] For asynchronous requests initiated via timers (setTimeout / setInterval) on the page, the system also delegates and encapsulates window.setTimeout and window.setInterval during the page initialization phase using Page.addScriptToEvaluateOnNewDocument: each time setTimeout or setInterval is called, window.__inflightCount is incremented and decremented by one before and after the internal callback function is executed, respectively, to ensure that asynchronous tasks triggered by timers are included in the in-flight request counting system in the same way as XHR / Fetch requests.

[0053] Furthermore, to avoid deadlock issues caused by continuous page polling (such as HTTP long polling, WebSocket heartbeats) or frequent DOM animations that prevent waiting conditions from being met indefinitely, the system sets a maximum waiting timeout threshold (default 30,000 milliseconds). If the network quiet period and the DOM stable period are not simultaneously achieved within this time, the system will forcibly exit the waiting state, record the timeout event, the count of unfinished requests in the current window, and the last DOM change time in the log, and directly execute the subsequent analysis process of the currently collected and stored data. This engineered timeout protection mechanism ensures the robustness and feasibility of the detection process under various complex page scenarios.

[0054] Step S2: Full data collection of four types of client storage media; After the dual waiting conditions are met, full data collection is performed on localStorage, sessionStorage, Cookie and IndexedDB, and uniformly encapsulated into a standardized storage record structure; After the behavioral simulation sequence is completed, the system injects the acquisition script into the page execution environment through the CDP's Runtime.evaluate interface, and performs a full data read on the four types of storage media. The specific acquisition methods for each media are as follows: Collection of localStorage and sessionStorage: Traverse all keys of the Storage object, iterate by index using the key(i) method, and record the name and value of each key; at the same time, read the write event sequence recorded by the proxy script in the global monitoring buffer, associate the write timing with the corresponding business operation node, and form a "storage item - business operation" mapping table. Cookie collection: Read all cookie records under the current page domain through the Network.getCookies interface of CDP, and collect the name, value, domain, path, expires, httpOnly, secure and sameSite fields. The status of the HttpOnly attribute will directly affect the subsequent security level assessment. IndexedDB data collection, i.e., cursor iteration traversal, such as... Figure 3 As shown: First, indexedDB.databases() is called to obtain a list of all database names under the current source; for each database, indexedDB.open() is called to open a read-only connection, and all object stores are enumerated through IDBDatabase.objectStoreNames; for each object store, a read-only transaction is started, and IDBObjectStore.openCursor() is called to create a cursor. In the cursor's onsuccess callback, all records are iterated recursively, and the records are serialized into JSON strings and included in the collection results.

[0055] The core mechanism of the above three stages of collection and traversal: (1) Dynamically obtain the list of databases using indexedDB.databases(); (2) Wrap the open request in a Promise for each database and convert the onsuccess / onerror callbacks into an awaitable Promise; (3) For each ObjectStore, wrap the openCursor cursor iteration with a Promise, and traverse all records recursively (cursor.continue()) in the onsuccess callback. After the traversal is complete, resolve the result array. This wrapper allows Runtime.evaluate to synchronously wait for the entire traversal to complete using the standard async / await syntax.

[0056] This invention features originality in its automated traversal of IndexedDB: IndexedDB is the most technically complex client-side storage medium in modern web applications, and its automated traversal faces three major obstacles, which are the root cause of blind spots in existing security tools: (a) API is fully asynchronous and transactional: All IndexedDB operations are based on DOM event callbacks (IDBRequest.onsuccess / onerror), rather than synchronous or Promise. CDP's Runtime.evaluate cannot directly wait for asynchronous events to complete. (b) Database name cannot be predicted: Existing security tools cannot predict the IndexedDB database name through static analysis of URL or HTML. It is necessary to dynamically query it through indexedDB.databases() (some older browsers do not support this interface. This invention provides a downgraded solution to extract the database name by analyzing the indexedDB.open() call in the page script). (c) Cursor recursive iteration: The number of records in each ObjectStore is uncertain, and it must be traversed completely by recursively iterating through IDBCursor (cursor.continue() → onsuccess recursive call), and it is impossible to pre-allocate a fixed-size result buffer.

[0057] The three-stage cursor recursive iterative algorithm designed in this invention encapsulates the aforementioned asynchronous DOM event callback chain into a Promise chain, allowing Runtime.evaluate to synchronously wait for the entire traversal to complete using the await syntax. The traversal result serializes any JavaScript object, including binary data such as Blob and ArrayBuffer, into a StorageRecord structure, achieving "unified standardized processing of heterogeneous storage media." This maintains a format completely consistent with the results collected from localStorage / Cookie, eliminating the need for subsequent four-layer recognition engines to perform differentiated processing for different storage media.

[0058] This invention systematically solves the technical challenge of asynchronous state synchronization across environments. The IndexedDB API is designed based on the DOM event model (IDBRequest.onsuccess / onerror), and its callback execution relies on the browser's event loop mechanism. When the detection system initiates a Runtime.evaluate call from the Python server via the CDP protocol, the CDP interface itself cannot directly suspend and wait for the asynchronous callback at the DOM level to complete—because the CDP's evaluate method returns the result after the JavaScript synchronous execution is complete, while the IndexedDB's onsuccess callback is only triggered in the subsequent microtask / macrotask queue. This creates a gap in asynchronous state synchronization across three environments: Python server (synchronous call semantics) → CDP protocol layer (JSON-RPC over WebSocket) → browser JS engine layer (event-driven asynchronous callback).

[0059] This invention encapsulates the event-driven DOM underlying asynchronous callback mechanism into a Promise microtask chain that can be synchronously waited for by `Runtime.evaluate`. Specifically, the `onsuccess` / `onerror` callbacks of `indexedDB.open()` are encapsulated as `new Promise((resolve, reject) => { ...})`, and the synchronous execution characteristic of the Promise constructor is used to call `resolve` in the callback, allowing `Runtime.evaluate` to synchronously wait for the settled state of the Promise via the `await` syntax. This transformation resolves the fundamental technical contradiction that "the CDP protocol layer cannot directly suspend and wait for DOM event callbacks," enabling cursor recursive traversal (`cursor.continue() → onsuccess recursion`) to be synchronously waited for to complete within the control flow on the Python side. This allows for unified and standardized processing of the traversal results of IndexedDB and the collection results from other storage media (localStorage / Cookie).

[0060] Each record in the full data collection results is uniformly encapsulated into a StorageRecord data structure, which includes the following fields: storage type (storage_type), key name (key), raw string key value (raw_value), write timestamp (write_timestamp), associated business operation (trigger_action), and security attribute set (security_attributes, applicable only to cookies), as shown in Table 1.

[0061] Table 1

[0062] Step S3: Intelligent identification of sensitive information based on a multi-level rule and statistical feature reasoning engine, such as... Figure 4 As shown, the collected storage records are subjected to a four-layer progressive identification process: key name semantic identification, field value format identification, JSON structure recursive parsing, and Shannon entropy analysis, and the list of hit records and confidence scores are output. The aforementioned four-layer hierarchical order is not arbitrary, but based on a deep understanding of the data storage structure of modern SPA applications. The technical challenge in this field lies in the fact that the stored data of SPA applications is automatically serialized by the framework, exhibiting significant characteristics such as "rich key name semantics (e.g., vuex_state, cached_timestamp), highly complex value structures (deeply nested JSON, mixed arrays and objects), and high entropy in security credentials (random tokens, session keys)." Traditional single-rule-base solutions waste a large amount of computational resources on irrelevant data, while pure regular expression solutions are ineffective for nested structures and random credentials. This invention fundamentally solves the computational bottleneck problem of full regular expression scanning by prioritizing the key name semantic matching, which has the lowest computational cost—filtering 60%-70% of irrelevant storage items (such as UI state cache, timestamps, and framework internal metadata) in milliseconds—reducing the input volume of subsequent high-cost regular expression engines and JSON parsers to less than one-third of the original.

[0063] This sequential, progressive paradigm of "first coarse screening by key name → then fine judgment of value format → then deconstruction of structure → finally, entropy value as a safety net" achieves systematic optimization in both computational resource efficiency and multi-stage false alarm rate reduction. This differs from existing single-layer parallel rule base schemes or general classifier schemes, forming the core of the recognition engine's architecture. This invention constructs a rule- and statistical feature-driven four-layer progressive intelligent recognition engine, performing the following four layers of detection sequentially on each stored record; the higher the layer, the higher the recognition accuracy.

[0064] It is important to note the detection order of the four-layer recognition engine: The sequence of key name semantic recognition (first layer) → field value format recognition (second layer) → JSON structure recursive parsing (third layer) → Shannon entropy analysis (fourth layer) constitutes the essential technical features of the claims of this invention, and this sequence is irreversible in technical logic.

[0065] The following argument will be presented from the perspective of computational complexity: Reversing the detection order (e.g., moving regular expression matching or JSON parsing to the first layer) would cause an exponential deterioration in system performance. Assume the total number of stored records is N, of which approximately 60%-70% is irrelevant data such as UI state cache. The current design filters out most irrelevant records after O(N×k) key-name string matching (k is the average key length, in microseconds), leaving only about 0.3N-0.4N records for subsequent layers. If the regular expression matching layer is moved to the first layer, the regular expression engine needs to perform matching on all N records—the worst-case time complexity of the regular expression engine can reach O(2^m) (m is the pattern length), which will lead to an order-of-magnitude increase in CPU computational power consumption in scenarios with a large N. If the JSON recursive parsing layer is moved to the first layer, a JSON.parse operation must be attempted on each record. JSON parsing itself requires building a complete object graph, allocating memory, and recursively traversing nested structures, resulting in time and space complexity far exceeding simple string matching. Performing JSON parsing on irrelevant records that are not in JSON format will cause a large amount of unnecessary computation.

[0066] In terms of specific values, let's take 500 stored records collected from a typical SPA application as an example for estimation: In the current order, the first-level key name semantic matching filters out 350 irrelevant records in about 5 milliseconds, with only 150 records entering subsequent processing; if the regular expression matching is moved to the first level, the regular expression engine matching needs to be performed on all 500 records one by one (assuming an average matching time of 0.5 milliseconds per record, the total time for regular expression matching is about 250 milliseconds), and the regular expression matching itself will also generate a certain proportion of false alarms for non-sensitive strings such as "UI state cache key name", increasing the burden of subsequent processing. More seriously, if the recursive parsing of JSON is moved to the first level, the handling of JSON.parse failure exceptions (throwing SyntaxError for non-JSON strings) itself consumes a significant number of CPU cycles; performing JSON.parse attempts on each of the 500 records one by one—even if each takes only 0.1 milliseconds—will result in 50 milliseconds of pure wasted overhead, and a large number of try-catch exception handling will trigger the JavaScript engine's deoptimization, further slowing down the execution performance of the entire page context, and in severe cases, causing the browser's main thread to block and crash.

[0067] The above analysis proves from both computational complexity theory and quantitative estimation that the current detection order of "1 key name → 2 regular expression → 3 recursion → 4 entropy value" has unexpected technical effects: it not only significantly reduces the search space and the total computational overhead, but also avoids the engineering-level problem of browser main thread blocking caused by improper detection order.

[0068] The hierarchical design of this layered inference engine has a clear technical logic: the arrangement of the four recognition engines reflects the systematic design of "optimal computational resource efficiency" and "false alarm rate control," and the order of each layer has a necessary technical logic, rather than being a simple stacking of rules. The first layer, key name semantic recognition, has an extremely low cost (hash substring matching, microsecond level), capable of filtering approximately 60%-70% of irrelevant storage items (such as UI state cache, timestamps, etc.) within milliseconds, significantly reducing the computational cost of subsequent regular expression engines and JSON parsers. If the regular expression layer is placed at the front, performing regular expression matching on the entire stored data will generate an order of magnitude higher computational overhead.

[0069] The second layer is field value format recognition: supplementary verification algorithms (weighted modulo 11 check, Luhn algorithm, JWT decoding verification) are introduced instead of simply relying on regular expressions because the cost of false positives for high-value fields (ID card number, bank card number) is extremely high. The accurate algorithm reduces the false positive rate of such fields from about 15% for regular expression matching to less than 1%.

[0070] The third layer, JSON recursive parsing, cannot be performed upfront because modern SPA frameworks (Vuex / Redux / Pinia, etc.) typically serialize the entire application state tree and store it directly in Storage. The keys for these records are usually generic words like "state" or "store," which the first layer cannot detect. However, their values ​​are deeply nested JSON objects containing dozens of fields, making direct regular expression execution on complex long strings ineffective. The first and second layers must first filter out a large amount of irrelevant data, and then perform deep expansion on a small number of "suspected state tree" records to achieve the optimal balance between efficiency and coverage, demonstrating the layered decision-making intelligence of the layered inference engine.

[0071] The fourth layer, Shannon entropy analysis, acts as a "fallback layer for garbled data": it specifically covers boundary scenarios where high-entropy random tokens (UUID, Session Key, API Secret, random salt, etc.) have unpredictable formats and cannot be pre-defined with regular expressions. These fields are typically not detected by the first three layers, but their high information entropy (H > 3.5 bits / character) indicates that the field contains non-business-related random bytes, making it highly suspicious as a security credential. Entropy analysis, as the last line of defense, provides an "effective fallback under zero-rule coverage," significantly reducing the false negative rate.

[0072] The four-layer mechanism of coarse screening → precise regularization → structural deconstruction → scrambling for fallback greatly balances detection speed and false alarm / false negative rate, which is the core innovation of the recognition engine of this invention.

[0073] First layer: Key name semantic recognition.

[0074] Semantic matching is performed on the key name fields of stored records, using a case-insensitive substring matching strategy based on a pre-defined sensitive key name list. The sensitive key name list is grouped semantically, including: authentication keys (token, access_token, refresh_token, jwt, session_id, auth, credential, api_key, secret), personal information keys (phone, mobile, idcard, id_card, realname, email, birthday), password keys (password, passwd, pwd, pass, pin), and business credential keys (openid, unionid, user_id, uid, account, appid, appkey). If a key name match is found, the record is marked as "suspected sensitive," with an initial confidence level of 0.6, and proceeds to the second layer of verification.

[0075] Second layer: Field value format recognition.

[0076] A pre-defined regular expression rule library is applied to the key-value fields for format matching, and supplementary validation algorithms are performed for specific types to improve accuracy, as shown in Table 2: Table 2

[0077] The third layer: recursive parsing of the JSON structure.

[0078] If the key-value field conforms to the JSON format (starting with "{" or "["), it is deserialized to obtain a structured JavaScript object, and then a depth-first recursive traversal is performed: the first-level key name semantic recognition is repeatedly performed on the key name of each leaf node, and the second-level format regular expression matching is repeatedly performed on the value of each leaf node. This layer is specifically used to detect complex data structures stored as a whole in JSON format (such as user information objects containing multiple sensitive fields).

[0079] The recursive parsing process employs a double anti-dead-loop mechanism: (1) The maximum depth is limited to 10 layers. When the depth threshold is exceeded, recursion will stop and a truncation log will be recorded. (2) Maintain a WeakSet to record the memory addresses of the objects that have been traversed. Before entering each nested object, check whether a reference to that object already exists in the WeakSet. If it does, it is determined to be a circular reference, and the current recursive branch is immediately exited. The introduction of the dual mechanism reflects the engineering rigor of the JavaScript object model, because depth limits alone cannot intercept cross-references between different branches at the same level (for example, field b of object A references object B, while field a of object B references object A). The reference tracking of WeakSet fundamentally eliminates the risk of stack overflow caused by any form of circular reference.

[0080] It should be noted that WeakSet is chosen instead of Set because WeakSet holds weak references, which does not prevent the tracked objects from being garbage collected by the JavaScript engine after the recursive traversal is completed, thus avoiding the risk of memory leaks. The has / add operations of WeakSet are both hash lookups with O(1) time complexity, and their impact on the overall performance of recursive traversal is negligible.

[0081] Fourth layer: Shannon entropy analysis.

[0082] For records that do not match the format rules after the first three layers but whose key names belong to the authentication or business credential categories, Shannon information entropy calculation is performed: H = -Σ p(xi) × log2p(xi), where p(xi) is the frequency of character xi in the value string. When H > 3.5 bits / character and the string length > 20, the field is determined to be a high-entropy string, identified as a suspected randomly generated key or token, and a confidence score of 0.7 is assigned. This layer can capture stored values ​​whose format does not conform to the preset rules but are essentially high-strength random credentials.

[0083] Step S4: Security level assessment based on a multidimensional weighted scoring model, such as... Figure 5 As shown; combining the type of sensitive information, storage location, encryption status, and identification confidence level, calculate the comprehensive risk score for each hit record; This invention designs a multi-dimensional weighted scoring model to calculate a comprehensive risk score for each correctly identified stored record: S = W_type × C_storage × C_encrypt × Conf, and the definitions and value rules of each parameter are shown in Table 3: Table 3

[0084] Safety level classification thresholds: S≥7.0 → High risk (immediate repair); 3.0≤S<7.0 → Medium risk (repair recommended); 1.0≤S<3.0 → Low risk (monitor recommended); S<1.0 → Information (refer to records).

[0085] The automatic determination mechanism for the encryption state coefficient is as follows: The system automatically identifies the encryption state of the stored value using the EncryptStateDetector class according to the following priority order, returning the result on the first successful detection, ensuring that each record obtains a unique encryption state marker: (1) Strong encryption (C_encrypt = 0.2): If the string satisfies Shannon entropy H ≥ 3.5 bits / character and the character set covers a variety of non-hexadecimal characters (i.e., does not meet the characteristics of a pure hexadecimal character set), it is determined to have been processed by block ciphers such as AES and RSA or asymmetric encryption, and the risk weight is reduced accordingly. High entropy value is the core statistical feature of block cipher cipher text, which is different from hash value (fixed-length hexadecimal) and Base64 (specific character set).

[0086] (2) Weak encryption / hash value (C_encrypt = 0.6): If the string length is exactly 32 characters (MD5 output), 40 characters (SHA-1 output), or 64 characters (SHA-256 output), and the character set is strictly limited to [0-9a-fA-F] (pure hexadecimal), it is determined to be a hash value or a weak encryption digest. Hash algorithms (MD5, SHA-1) are irreversible but can be attacked by rainbow tables, so they are given a medium risk weight.

[0087] (3) Base64 encoding (C_encrypt = 0.9): The string is determined to be Base64 encoded by matching the regular expression ^[A-Za-z0-9+ / ]+=*$ and the string length is an integer multiple of 4. Base64 is essentially an encoding rather than an encryption. The original plaintext can be directly decoded by anyone, so it is still treated with a high risk weight close to that of plaintext.

[0088] (4) Plaintext (C_encrypt = 1.0): If none of the above conditions are met, the character set is ordinary printable characters and the entropy value is lower than the threshold, it is judged as plaintext storage without any protection and is given the highest risk weight.

[0089] Step S5: Generate a structured inspection report; Based on the risk score, determine the security level and generate a structured report containing de-identified data, source tracing path, and remediation suggestions.

[0090] The system sorts all hit records in descending order of security level and generates a structured detection report. Each risk item includes: security level (risk_level), comprehensive risk score (score), storage medium type (storage_type), key name (key), value digest (first 8 characters + **** + last 4 characters), identified sensitive information type (sensitive_type), identification confidence level (confidence), triggering business operation (trigger_action), set of cookie security attributes (security_attributes), and corresponding remediation suggestions (remediation). The overall system architecture is shown in Table 4. Table 4

[0091] The technical problem solved by this invention—automating, ensuring traceability, and minimizing false alarms in detecting sensitive information stored on the client side in high-concurrency asynchronous Single-Page Applications (SPAs)—is a long-standing technical challenge in the field of web security. The solution relies on the invention's unique closed-loop architecture of "behavior-driven → dynamic waiting → precise data collection → layered reasoning → quantitative evaluation." The absence of any one of these five steps will lead to system failure. Without behavior-driven and Hook injection (i.e., step S1), the system cannot trigger the SPA's route rendering and dynamic storage writing, nor can it intercept write events, and the collection coverage approaches zero. Without dual dynamic waiting, data collection will be triggered before asynchronous rendering is complete, resulting in a large amount of missing stored data and unreproducible detection results. Without full data collection, i.e. step S2, especially the three-stage cursor traversal for IndexedDB, the system cannot cover the storage medium with the highest complexity and largest data volume in the modern web application technology stack, forming a serious detection blind spot. Without the hierarchical progressive recognition engine, i.e. step S3, the system cannot accurately identify sensitive information from massive heterogeneous storage data under the dual constraints of high efficiency and low false alarms. The pure regularization scheme will face orders of magnitude higher computational overhead and a false alarm rate of more than 15%. Without quantitative assessment and actionable reporting steps 4 and 5, the detection results will degenerate into a set of discrete data points without priority, making it impossible for the security team to develop an actionable remediation strategy.

[0092] The five steps described above form a tight input-output coupling relationship—the output of the preceding step is a necessary input condition for the subsequent steps, and the accuracy of the subsequent steps depends on the completeness and correctness of the preceding steps. The absence of any step will degrade the entire system's detection capability from an engineerable deployment level to a "laboratory prototype level." For clarity, let's compare it to a commonly used industry solution: if a combination of "Burp Suite crawler (HTTP message level only) + third-party Storage Hook library (only data collection, no driver capability, no Trace ID tracing mechanism)" is used to detect the same SPA application, then... (a) Because the crawler module does not execute JavaScript, it cannot trigger more than 90% of page state and storage write behaviors. (b) Although Hook libraries can capture some manually triggered writes, they cannot establish a causal relationship between write events and business operations. (c) There is no dual waiting mechanism, the collection time is random, and the data integrity is not guaranteed. This comparative scheme cannot reach the engineering level of the complete closed-loop scheme of this invention in terms of collection coverage (less than 10%), traceability accuracy (0%), and detection reproducibility.

[0093] The four-layer progressive recognition engine in this application has an irreversible technical basis in its detection order: key name semantics → format regular expression → JSON recursion → entropy analysis. (1) If the regular expression matching layer (second layer) is moved to the first layer, the regular expression engine matching must be performed on all stored records, and the computational overhead increases from O(N_filtered) to O(N_total). In the worst case (regular expression backtracking), it can reach O(N×2^m), causing an exponential increase in CPU computing power. (2) If the JSON recursive parsing layer (third layer) is moved to the first layer, JSON.parse must be tried for each record and SyntaxError exception must be caught. A large number of try-catch operations trigger the JavaScript engine to optimize (deoptimization). When the number of stored records is large (such as 500+ records), it may cause the browser main thread to be blocked and crash. (3) If Shannon entropy analysis (fourth layer) is performed first, the calculation of entropy value requires traversing the complete value string of each record to construct the character frequency distribution. The amount of calculation for calculating the entropy value of each record is much greater than the key name substring matching. Furthermore, the entropy analysis cannot provide effective discrimination information for records with business key names such as "vuex_state" and "cached_timestamp", which is an invalid calculation.

[0094] Therefore, the current detection sequence of "1→2→3→4" is not an arbitrary combination or simple patchwork of the four detection means, but a systematic optimal design based on the computational cost characteristics of various algorithms (key name matching O(k) < regular expression O(n) < JSON parsing O(n×d) < entropy calculation O(m)) and filtering efficiency (the first layer filters 60%-70% of irrelevant data). Reversing this sequence will completely lose the core technical effect of "optimal computing resource efficiency". The core differences between the four-layer recognition engine of the present invention and the existing detection solutions in this field are shown in Table 5: Comparison dimension 1, recognition architecture: Existing tools (Burp Suite, OWASP ZAP, etc.) adopt a single-layer or parallel rule base, directly perform regular matching on all stored data, without a layered filtering mechanism, structured deconstruction capability, or statistical feature fallback. The present invention adopts a sequential progressive four-layer architecture optimized for computational efficiency and false positive control: key name semantic coarse screening (filtering 60%-70% of data at the millisecond level) → value format precise judgment (regular expression + algorithm verification, false positive rate < 1%) → structured deconstruction (JSON deep recursive expansion) → statistical feature fallback (Shannon entropy analysis).

[0095] Comparison dimension 2, processing of SPA state tree: Existing tools cannot identify nested sensitive fields in complex JSON structures, and automatically serialized key names of frameworks such as vuex_state and pinia_store are regarded as ordinary strings, leading to missed detections. The third-layer JSON recursive parsing of the present invention is specially designed for the characteristics of SPA frameworks, which expands the deeply nested state tree into leaf nodes and then detects each field, with a 10-layer depth limit to ensure performance. The fourth-layer entropy analysis covers high-entropy credentials not detected by the first three layers as a fallback.

[0096] Comparison dimension 3, decision interpretability: The regular matching results of existing tools have no quantified confidence, and false positives cannot be distinguished from true hits. Each layer in the four layers of the present invention outputs interpretable decision reasons and quantified confidence (key name hit → initial confidence 0.6; format verification passed → confidence updated; entropy value > 3.5 → confidence 0.7), and each risk item in the detection result has a complete reasoning chain traceability capability.

[0097] Table 5

[0098] According to the above method, some specific embodiments are as follows: 1. Plaintext storage detection of user identity tokens on e-commerce platforms The system loads the target e-commerce platform and executes preset behavior scripts (login, form filling, redirection).

[0099] When the "Submit Login Form" is executed, the backend injects a Trace ID into the page via CDP. The page executes localStorage.setItem to save the JWT token, and the hook script intercepts this write event and binds it to its Trace ID.

[0100] After completing the dual dynamic waiting (both network requests and DOM are stable), the full data collection module acquires and stores the data.

[0101] In the recognition engine: the first-level key name matches "token"; the second-level regular expression match matches the three-part JWT format. After Base64URL decoding and structure verification, the confidence level is updated to 0.98.

[0102] The evaluation module, based on the formula S = 9 (token) × 1.5 (localStorage) × 1.0 (plaintext) × 0.98 = 13.23, determined it to be "high risk" and generated a report suggesting "switching to HttpOnly Cookie".

[0103] 2. Detection of Personal Information in Government System JSON Composite Structure In response to the real-name authentication process on the government affairs platform, the system intercepted composite JSON data containing the "userProfile" key in sessionStorage.

[0104] The first two layers cannot directly determine the long string, so the third layer, a JSON recursive parser, intervenes, using WeakSet to prevent infinite loops and setting the maximum depth to 10, expanding nodes based on depth.

[0105] Within the child nodes, "idCard" passed a weighted modulo 11 check after being matched by regular expressions in the second layer, with a confidence level of 0.99; "mobile" had a confidence level of 0.95 after being matched by regular expressions. After scoring, they were rated as "high risk" and "medium risk" respectively.

[0106] The functional modules in this application can be implemented by program instructions on a computer device (including a processor and a memory). Those skilled in the art will understand that the foregoing embodiments are merely illustrative and should not be considered as limiting the scope of protection of the claims of this invention.

[0107] In summary, the technical solution of this application is capable of: (1) Through the Storage API proxy hook mechanism, real-time interception of localStorage, sessionStorage and Cookie write events is achieved without modifying the target page code. Combined with business operation association, it ensures that dynamically written data is not missed. (2) By using the cursor iterative traversal algorithm of IndexedDB, the gap in existing tools for detecting new client database storage media is filled; (3) In the hierarchical four-layer progressive recognition engine, the introduction of ID card number weighted modulo 11 verification, bank card Luhn algorithm verification, and JWT decoding verification will reduce the false alarm rate to an extremely low level. (4) The fourth-layer intelligent recognition based on Shannon entropy can discover high-intensity random vouchers whose formats do not conform to conventional rules, covering boundary scenarios outside the rule base; (5) The multidimensional weighted scoring model outputs a quantitative risk score, making the detection results sortable and comparable, which facilitates the security team to repair according to priority.

[0108] The second aspect of this invention discloses an AI-driven intelligent detection system for storing sensitive information in modern web application browser clients. Figure 10 This is a structural diagram of an AI-driven intelligent detection system for storing sensitive information in a modern web application browser client, according to an embodiment of the present invention; Figure 10 As shown, the system 100 includes: a method for implementing any one of the first aspect embodiments 1 and 2 described above, the system comprising: Behavior simulation and interception module 101: used to parse behavior scripts, drive browser operations through CDP, inject Hook scripts to achieve Trace ID injection and storage interception, and perform dual dynamic wait; Full data collection module 102: Used to read and standardize stored data from localStorage, sessionStorage, Cookie, and IndexedDB; Sensitive information identification engine module 103: used to perform a four-layer progressive detection including key name semantic recognition, format recognition, JSON recursive parsing and entropy analysis; Assessment and Reporting Module 104: Used to calculate the overall risk score, assess the safety level, and output a structured inspection report.

[0109] A third aspect of this invention discloses an electronic device. The electronic device includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it implements the steps of the AI-driven intelligent detection method for storing sensitive information in a modern web application browser client, as disclosed in any of the first aspects of this invention.

[0110] Figure 11 This is a structural diagram of an electronic device according to an embodiment of the present invention, such as... Figure 11As shown, the electronic device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, carrier networks, Near Field Communication (NFC), or other technologies. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad mounted on the device's casing, or an external keyboard, touchpad, or mouse.

[0111] Those skilled in the art will understand that Figure 11 The structure shown is merely a structural diagram of the part related to the technical solution of this disclosure and does not constitute a limitation on the electronic device to which the solution of this application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0112] A fourth aspect of this invention discloses a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the AI-driven intelligent detection method for storing sensitive information in a modern web application browser client, as described in any of the first aspects of this invention.

[0113] Please note that the technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments have been described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification. The above embodiments only illustrate several implementation methods of this application, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the invention patent. It should be pointed out that for those skilled in the art, several modifications and improvements can be made without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. An AI-driven intelligent detection method for storing sensitive information in modern web application browser clients, characterized in that, The method includes: Step S1: Real-time interception of browser driver and storage write based on CDP protocol; inject storage API proxy script before the target page is loaded, and realize accurate business traceability of high-concurrency asynchronous storage write through the traceability mechanism of globally unique Trace ID, while performing dual dynamic waiting judgment based on network quiet period and DOM stable period. Step S2: Full data collection of four types of client storage media; After the dual waiting conditions are met, full data collection is performed on localStorage, sessionStorage, Cookie and IndexedDB, and uniformly encapsulated into a standardized storage record structure; Step S3: Intelligent identification of sensitive information based on multi-level rules and statistical feature reasoning engine; perform four progressive identifications on the collected storage records in sequence: key name semantic identification, field value format identification, JSON structure recursive parsing and Shannon entropy analysis, and output the list of hit records and confidence level; Step S4: Security level assessment based on a multi-dimensional weighted scoring model; calculate the comprehensive risk score for each hit record by combining the type of sensitive information, storage location, encryption status, and identification confidence. Step S5: Generate a structured inspection report; Based on the risk score, determine the security level and generate a structured report containing de-identified data, source tracing path, and remediation suggestions.

2. The AI-driven intelligent detection method for storing sensitive information in a modern web application browser client according to claim 1, characterized in that, In step S1, the tracing mechanism for the globally unique Trace ID includes: Before each action instruction is executed, a global Trace ID containing the operation type, sequence number, and timestamp is synchronously injected into the browser context via CDP Runtime.evaluate; When the storage agent interception script captures a write event, it synchronously reads the current Trace ID and writes it to the record as a tracing field. For asynchronous writes, an asynchronous association window with a set duration is opened, and all storage writes within the window are forcibly associated with the Trace ID that triggered the asynchronous chain.

3. The AI-driven intelligent detection method for storing sensitive information in a modern web application browser client according to claim 2, characterized in that, In step S1, the dual dynamic waiting determination includes: Network quiet period determination: By proxying XMLHttpRequest and fetch, a global in-flight request counter is maintained. The condition is determined to be met when the counter is 0 for a consecutive set period of time. DOM stability period determination: By injecting MutationObserver to listen for DOM changes, a condition is determined when the set time threshold has been exceeded since the last change.

4. The AI-driven intelligent detection method for storing sensitive information in a modern web application browser client according to claim 3, characterized in that, In step S2, a three-stage asynchronous traversal algorithm is used to collect the full data of IndexedDB: Phase 1: Obtain the list of databases using indexedDB.databases(); Phase 2: Encapsulate a Promise request for each database to retrieve all ObjectStores; The third stage involves wrapping each ObjectStore with an openCursor cursor using a Promise and iterating through all records recursively in the onsuccess callback, thus transforming the DOM event-based callback chain into a Promise chain that can be synchronously waited for by CDP.

5. The AI-driven intelligent detection method for storing sensitive information in a modern web application browser client according to claim 4, characterized in that, In step S3, the specific execution order and rules of the four-layer progressive identification are as follows: The first layer is key name semantic recognition: using substring matching to filter key names, and assigning an initial confidence score if a match is found. The second layer is field value format recognition: regular expression matching is performed on key values, and supplementary verification algorithms such as weighted modulo 11 check, Luhn algorithm and JWT decoding verification are introduced for specific types to update the confidence level; The third layer is the recursive parsing of the JSON structure: if the key value is in JSON format, it is deserialized and then recursively traversed in a depth-first manner. The first and second layers of identification are repeated for leaf nodes. WeakSet is used to prevent circular references and set a maximum depth limit. The recursive parsing of the JSON structure is as follows: If the key value is in JSON format, WeakSet is used during the parsing process to prevent circular references and set a maximum depth limit. The values ​​of all leaf nodes are extracted, and the first and second level checks are repeatedly performed on the value of each leaf node. The fourth layer, Shannon entropy analysis: For records that were not matched in the first three layers but whose key names are suspicious, calculate the information entropy. If the entropy value is greater than the preset threshold and the length meets the requirements, it is judged as a suspected high-strength random credential.

6. The AI-driven intelligent detection method for storing sensitive information in a modern web application browser client according to claim 5, characterized in that, The supplementary verification algorithm specifically includes: performing weighted modulo 11 verification on suspected ID card numbers; performing Luhn algorithm verification on suspected bank card numbers; and performing Base64URL decoding and internal field structure verification on suspected JWT tokens.

7. The AI-driven intelligent detection method for storing sensitive information in a modern web application browser client according to claim 1, characterized in that, In step S4, the formula for calculating the comprehensive risk score is: S=W_type×C_storage×C_encrypt×Conf; Where W_type is the information type weight, C_storage is the storage location coefficient, C_encrypt is the encryption state coefficient, and Conf is the identification confidence level.

8. An AI-driven intelligent detection system for storing sensitive information in modern web application browser clients, characterized in that, The system for implementing the method according to any one of claims 1 to 7, the system comprising: Behavior simulation and interception module: used to parse behavior scripts, drive browser operations through CDP, inject Hook scripts to achieve Trace ID injection and storage interception, and perform dual dynamic wait; Full data collection module: used to read and standardize stored data from localStorage, sessionStorage, Cookie, and IndexedDB; Sensitive information identification engine module: used to perform a four-layer progressive detection including key name semantic recognition, format recognition, JSON recursive parsing, and entropy analysis; Assessment and Reporting Module: Used to calculate the overall risk score, assess the safety level, and output a structured inspection report.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it implements the steps of the AI-driven intelligent detection method for storing sensitive information in a modern web application browser client, as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the AI-driven intelligent detection method for storing sensitive information in a modern web application browser client, as described in any one of claims 1 to 7.

Images