## 3 Methodology  
### Categorization of Sensitivity and Security  
Our methodology is predicated on the notion that in Angular web applications, sensitive data are centralized in services, which are accessed and utilized as singletons by Angular framework classes via their methods. In order to discover sensitivity levels and vulnerabilities in static code, our first step was the detection of elements inside the component classes that exhibit indications of sensitivity. This was accomplished by using the capabilities of contextual understanding of the GPT models. Subsequently, we proceeded to determine which of these elements are managed by services. To classify the sensitivity level of the data, we considered the attempts to categorize the data [15; 16] mentioned in the Introduction, but our primary metric was the potential harm to users if unauthorized individuals accessed the data. Based on this, we divided the sensitive data into three levels. Motivated by the need to provide a categorization whose levels build upon one another, the classification of data is based on logical reasoning. This approach allows us to debug the thought process of the large language model. We can then improve or validate it following the chain-of-thought principle. The categories are defined as follows:  
* **Level 1 (Low Sensitivity)**: The accumulation and compilation of large quantities of data at this level is required to infer confidential information and create abuse opportunities. Sensitive information includes, among other things, a user's behavior history, a list of websites visited, products and topics of interest on a website, and search history. * **Level 2 (Medium Sensitivity)**: By obtaining data at this level, it is possible to retrieve and compile potentially exploitable information. Solutions such as two-factor authentication, regular email and SMS notifications, and exhaustive logging in to affected applications can mitigate the effects of a potential breach. This is the largest and most \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Author** & **Models** & **Subject** & **Weaknesses** \\ \hline [PERSON] et al. [33] & GPT-type models & Smart contract source code & Only “acceptable” precision for larger projects like Web3 Bugs \\ \hline [PERSON] et al. [34] & GPT-3.5 and ChatGPT & CWE vulnerabilities in Java applications & Naive assumptions about GPT’s knowledge, results on part with dummy classifier \\ \hline [PERSON] and [PERSON] [35] & ChatGPT & Android bug replay & Limited by manually crafted patterns and pre-defined vocabulary lists \\ \hline \hline \end{tabular}
\end{table} 
Table 1: _Cont._extensive group. It includes data such as usernames, passwords, private records, political views, sexual orientation, IP address, physical location, and hectic schedules. * **Level 3 (High Sensitivity)**: The data at this level is sensitive in and of itself, and its acquisition or disclosure can have severe legal repercussions and cause extensive harm. Examples include health information, medical history, social security number, driver's license, and credit card information. As stated in the Introduction, this categorization, which is based on a rationale for the level of data sensitivity for large language models, is anticipated to function well in arbitrary applications but may not be ideal for all development teams. In certain instances, it may require some refinement, perhaps by providing more specific examples for each level in the prompts. However, we hope that such fine-tuning or even the use of a more specific or different sensitivity scale will not be a problem for GPT's ability if our method works and can find and classify sensitive data efficiently and with good reasoning.