## 4 Results and Discussion
### Rq1
This principle, interpreted in programming languages based on an object-oriented paradigm, emphasizes that instead of managing multiple similar operations, services should be responsible for handling a single, well-defined resource. For example, it was a common phenomenon in selected projects that all database operations, regardless of the tables or collections manipulated, were performed by a single service, which could then make a single ill-parameterized or insufficiently tested function call to attempt to retrieve data that a significant proportion of users would not have had access to on a relatively unprotected interface. Another part of our research team has demonstrated, through the development of a library [48], how a more precise, resource-based allocation can have additional productivity benefits. Such a lack of resource isolation is in fact a direct practical implementation of the CWE-653 vulnerability, as illustrated by the fact that the insufficient detection count for GPT-4 and GPT-3.5 is almost identical. The three most common development practices that led to errors during the evaluation were the following. * **Injection Circumvention**: Although Angular formally documents the exact role and intended use of services, a recurring problem in debugging has been that developers have circumvented the development pattern of injecting and then invoking methods. There were cases where services saved sensitive data in localStorage and the components of the application later read it from there, and one case where services used EventEmitters to pass sensitive values. This resulted in missing information cases in which the presence of services was detected but not their precise identities because they were not used in a conventional manner. Detecting and handling such cases is not easy. The prompt of the step to detect sensitive data and services will be extended in the later evaluations with an additional element to tag sensitive data from the EventEmitter, but because of the similarities (subscribe operation), they can easily be confused with observables, and thus, when detecting such cases, it is necessary to analyze the service code to see if the transmitted event is from inside or outside the application and if sensitive data are transmitted as a payload. * **Monolith Service**: The most common issue was the lack of isolation mentioned above, a textbook example of the CWE-653 vulnerability, where services are not organized around a resource but around a type of operation. For example, there is an entity called DbService, which is responsible for the database operations of registration, login, shopping, commenting, and private messaging at the same time. This flaw led to very high insufficient detection count values, where the service was identified either as sensitive or not, depending on which of the many resources it was currently managing. In the future, this can be resolved so that at the end of the detection, each service is assigned the highest sensitivity value that was encountered during the detection. * **Delegated Responsibility**: This issue refers to instances in which a service was initially used correctly, but then the data it handles was stored and transmitted in the application differently, such as by passing parameters between parent and child components or by creating a separate component or other object that acted as a session database. We expect that this will only be fully resolved if we can further develop our methodology as we plan and track accurate navigations and calls between application components. In the meantime, since the sensitivity detection prompt also tries to interpret what happens to sensitive data after it is first retrieved from the service, in the next round of analyses we will tag those that were derived from a sensitive service and, at the end of the detection, we will attempt to recover sensitivity levels based on these tags for data retrieved from local storages as well.