# XSShield: Defending Against Stored XSS Attacks Using LLM-Based Semantic Understanding
## 3 XSShield Design
### Data Adaptor
#### 3.2.1 PDG Generator
This implements two complementary mechanisms: constant propagation and copy propagation. Constant propagation identifies and propagates statically computable expressions in the graph, while copy propagation tracks assignment operations, optimizing variable usage by replacing copied variables with original values. These mechanisms work collaboratively to enhance code efficiency through systematic value propagation and variable optimization. Dead Code Elimination. This focuses on removing two types of redundant code: print operations used for debugging or logging, and executable but unused code segments. This systematic elimination significantly reduces PDG size while maintaining program core logic and functionality. #### 3.2.2 PDG Partitioner

We propose a novel partitioning method for PDGs of large-scale JavaScript programs, employing an optimized community detector. This method aims to decompose PDGs into logical subgraphs to simplify analysis while preserving fundamental semantic properties of the original program. To achieve this, we developed an enhanced partitioning strategy that emphasizes the distinctions between control flow and data flow dependencies. Recognizing that control flow typically contains more critical program semantics, our method assigns higher importance to control flow dependencies to better maintain functional integrity of partitioned PDGs. As shown in Algorithm 2, the method encompasses two core phases: **weighted graph construction** and **community detection**. The relevant symbols are defined as follows:

\(G=(V,E,w)\): Weighted undirected graph derived from PDG. \(w_{c},w_{d}\): Weights for control flow and data flow edges. \(\theta_{ast}\): Upper limit of AST nodes allowed in each community. \(Q\): Modularity measure for community detection. \(N_{AST}(C)\): Number of AST nodes in community \(C\). **Phase 1: Weighted Graph Constructor. ** The first phase involves transforming the input PDG into a weighted undirected graph \(G\). Edges representing control flow dependencies are assigned higher weights (\(w_{c}\)), while edges representing data flow dependencies receive lower weights (\(w_{d}\)). This weighting scheme (\(w_{c}\gg w_{d}\)) emphasizes the critical role of control flow in determining code functional structure. **Phase 2: Enhanced Community Detector. ** The second phase employs an improved variant of the Louvain algorithm, specifically adapted for JavaScript's unique characteristics. This enhanced algorithm optimizes the modularity measure \(Q\), calculated as:

\[Q=\frac{1}{2m}\sum_{i,j}\biggl{[}w_{ij}-\frac{k_{i}k_{j}}{2m}\biggr{]}\delta(c _{i},c_{j})-\lambda\sum_{C}\max(0,N_{AST}(C)-\theta_{ast}) \tag{4}\]

where \(m\) denotes the total edge weight, \(w_{ij}\) represents the weight of the edge between nodes \(i\) and \(j\), \(k_{i}\) is the weighted degree of node \(i\), and \(c_{i}\) represents the community containing node \(i\). The Kronecker delta function \(\delta\) is used to assess whether nodes \(i\) and \(j\) belong to the same community. The additional penalty term \(\lambda\sum_{C}\max(0,N_{AST}(C)-\theta_{ast})\) ensuresthat the number of AST nodes in each community remains below the predefined limit \(\theta_{ast}\), where \(\lambda\) is a penalty coefficient that controls the importance of this constraint.