Skip to content
Open access

BSM: A Browser-Resident Framework for Real-Time Detection of JavaScript API Abuse and Prompt Injection Attacks

2026 · IEEE Access · Vol 14, pp. 108287-108311 · 0 citations · 52 references
Computer Science

TL;DR

Browser Security Monitor (BSM), a browser-resident framework that instruments sensitive window object APIs to intercept and analyze dynamic JavaScript execution in real time, is presented, a precision-first, low-overhead client-side filter that complements rather than replaces server-side and model-internal defenses.

Abstract

As web applications embed both dynamic JavaScript and AI services, they expose browser APIs to two runtime threats that are rarely addressed together: JavaScript code injection and prompt injection. This paper presents Browser Security Monitor (BSM), a browser-resident framework that instruments sensitive window object APIs to intercept and analyze dynamic JavaScript execution in real time. BSM integrates weighted behavioral pattern matching using Deterministic Finite Automata (DFA) with empirically derived risk scores and a lightweight keyword and linguistic feature filter for direct prompt injection. We evaluate BSM across production deployment, static malware analysis, and prompt injection detection. Field deployment across 47 production websites monitored 50,732 API events (6,559 fetch and 44,173 eval() invocations) with zero false positives. Static evaluation on 1,109 samples (1,061 malicious from the Petrak collection and 48 benign production libraries) reports 98.4% precision, 59.6% recall, and 79.2% specificity at the browser-deployment threshold $T=40$ , with an AUROC of 0.60 reflecting a discrete weighted scoring design that trades ranking quality for sub-millisecond latency; a Random Forest baseline on the same features reaches AUC-ROC 0.98 but a 52.0% false-positive rate unusable for browser deployment. Applied to the static evaluation, a SHA-256 content-hash access list over canonical CDN library versions raises specificity to 100.0% with no measurable change in malicious-sample recall. On 1,695 labeled prompts, the prompt injection module yields 45.9% recall, 92.5% precision, 96.8% specificity, and F1 = 0.614, while detecting 0 of 20 paraphrased attacks, an explicit keyword evasion boundary. An adversarial robustness evaluation across five transformation families shows 90% evasion once the literal eval() token is stripped, quantifying the rule-based detection ceiling. BSM does not address indirect prompt injection, binary-payload malware, or polymorphic JavaScript outside the nine-pattern set. Detection latency stays within 0.3 to 0.8 ms and memory within 25 to 35 MB. BSM’s contribution is integrative rather than algorithmic: no individual technique is novel in isolation, and the value lies in combining JavaScript API-abuse detection and direct prompt injection detection in a single browser-resident, sub-millisecond, low-memory extension validated on 47 live production sites. BSM is a precision-first, low-overhead client-side filter that complements rather than replaces server-side and model-internal defenses.

Read PDF

Similar papers

Review Sep 2026

An Empirical Analysis of CodeQL False Positives and Query Refinements for Java Vulnerabilities

Static application security testing (SAST) tools help developers find vulnerabilities before deployment, but false positives create substantial triage effort. We study whether CodeQL false positives in Java security analysis form recurring, explainable patterns that can be reduced by refining the analysis. We run CodeQL's Java security query suite on 167 CVE instances from 110 projects, focusing on the ten queries with the highest false positive rates. We manually review 500 sampled false positive paths and locations and construct a source-level taxonomy. The five categories are Missed Path Constraint or Sanitization (36.6%), Benign Execution Context (29.4%), Missing Trust Boundary Modeling (27.6%), Imprecise Concurrency Modeling (5%), and Imprecise Sink Modeling (1.4%). Guided by these findings, we implement CodeQL refinements that detect and filter recurring false positive patterns at the query level. The refinements remove 81.8% of reviewed false positives. Across the full selected-query dataset, they remove 15.8% of reported paths and locations while retaining 7 of 8 true positives. This shows that many false positives can be reduced in the analysis, although fixed refinements often depend on project-specific context. To address this generalization gap, we evaluate whether agentic coding tools can adapt refinement patterns to new projects. Given our patterns as templates, the two tools succeed on 56% and 62% of tasks, with query compile-pass rates above 90%. Without this guidance, both succeed on only 28%, while compile rates fall to 30-36%. These results support a refinement-oriented SAST workflow in which recurring false positives are modeled in CodeQL queries and automatically adapted to different project contexts, reducing repeated triage.

Amirali Sajadi, Saikat Dutta, Preetha Chatterjee · 0 citations
Conference Jul 2026

Commit-Message-Augmented Static Analysis of Cross-Site Scripting Fixes in Java Web Applications

Cross-Site Scripting (XSS) remains a common and high-impact web vulnerability. Detecting XSS with high precision is difficult because exploitability depends on end-to-end data flow (sources, sanitizers, and sinks), framework-specific rendering semantics, and the correctness of context-aware output encoding. Although secure development lifecycles increasingly integrate static application security testing (SAST) into CI/CD pipelines, practical adoption is often limited by false positives and incomplete modeling of project-specific sanitization and templating behavior. In parallel, machine learning (ML) approaches show promise for learning vulnerability-relevant patterns from code, but they depend on the availability of realistic labeled data. This paper studies a low-cost repository-native signal that is routinely available but underused in ML-assisted static analysis: commit messages. We propose a mining and weak-labeling pipeline for Java repositories that identifies candidate XSS-fix commits using message heuristics grounded in OWASP guidance and CWE taxonomy, aligns commit messages with pre-/post-change code contexts extracted from diffs, and trains classifiers under two feature settings: (i) code-only and (ii) code+commit-message fusion. Across three model families (Random Forest, TextCNN, and BiLSTM), commit-message fusion consistently improves F1 and AUPRC and reduces false positives, suggesting that developer intent provides a useful auxiliary signal for security triage.

Abu Alam, Qka Mirza · 0 citations
#artificial intelligence Preprint Sep 2026

Beyond Static Guarantees: Measuring the Static-Pass Dynamic-Fail Gap in Security-Sensitive and LLM-Generated Python Code

Advances in large language models (LLMs) fuel the quest for scalable methods to assess the security of generated and security-sensitive software. Static analysis is widely adopted as a scalable, reproducible, and inexpensive security gate, but cannot directly observe runtime exploit behaviour. Vulnerabilities dependent on adversarial inputs, execution context, or exploit chaining may evade static checks while remaining exploitable in practice, yet passing static analysis is often treated as evidence of secure behaviour. This paper introduces the Static-Pass Dynamic-Fail (SPDF) phenomenon and a three-stage agentic pipeline combining static scanning, LLM-driven Common Weakness Enumeration (CWE) reasoning, and autonomous exploit verification in isolated Docker containers. We evaluate 1,355 Python samples from SecurityEval, RedCode, and CyberNative datasets. Of the 654 samples producing no findings under the composite Bandit-Semgrep gate, the LLM detection stage identified 394 candidate vulnerabilities across 235 files. Dynamic verification confirmed or partially confirmed exploitability in 95 files, yielding an inclusive pipeline rate of 14.53% (roughly 1 in 7 statically clean samples). This rate represents the proportion of Bandit-Semgrep-clean samples for which the pipeline identified a candidate vulnerability and obtained runtime evidence supporting exploitability. Outcomes varied by dataset: among candidate file--CWE pairs, confirmed exploitability was 33.7% for RedCode, 28.6% for CyberNative, and 5.4% for SecurityEval. Several frequently confirmed classes, including CWE-338 and CWE-916, were flagged by neither Bandit nor Semgrep. These findings indicate that static-analysis success and runtime security are hierarchical layers of software assurance rather than interchangeable measures, and have the potential to reshape how AI-generated and security-sensitive code is evaluated.

Jessica Pourleyli, Maitreyee Das Urmi, Glaucia Melo · 0 citations
Conference Open access 2026

Static Code Analysis Output as a Proxy Indicator for Classifying JavaScript Obfuscation

: This study investigates whether the output of Static Code Analysis (SCA) tools can serve as a proxy indicator for identifying obfuscated JavaScript. Two datasets are analyzed in their original and obfuscated forms: a controlled pilot dataset focused on common malicious patterns and a larger Kaggle dataset of approximately 1900 real-world JavaScript files. Four SCA tools are applied to both datasets: SonarQube, ESLint, NodeJsScan, and JSHint. The outputs are normalized into a unified feature schema, and pre/post-obfuscation deviance is quantified through issue counts and Kernel Density Estimation (KDE) of warnings normalized by file size and line count. Results show large and consistent increases in issue counts for ESLint and JSHint, substantial rises for SonarQube, and unstable shifts for NodeJsScan. The KDE analysis strengthens the proxy indicator’s effectiveness beyond raw counts by confirming that normalized warning intensity rises after obfuscation for SonarQube and JSHint. These patterns demonstrate that SCA warnings deviate under obfuscation and provide a practical proxy indicator for distinguishing obfuscated code from human-readable code.

Alkın Alkan, Mehmet Tahir Sandikkaya · 0 citations

We use cookies to run the site and, with your consent, for analytics and to show ads. See our Cookie Policy.