Security Risks in Responsive Web Design Frameworks

Abstract

This study addresses a gap in the literature by explicitly linking responsive web design frameworks to concrete cybersecurity vulnerabilities, moving beyond traditional discussions of usability and device compatibility to incorporate security-by-design principles in contemporary frontend development. The research adopts a qualitative comparative approach and considers five widely used responsive design frameworks: Bootstrap, Tailwind CSS, Foundation, Pure CSS, and Skeleton. These frameworks were selected based on criteria such as maturity, adoption, and architectural diversity. Three research questions guide the analysis: the identification of cybersecurity risks associated with responsive design frameworks, the extent to which these risks vary across frameworks, and the mitigation strategies required to address them. The findings confirm that most critical vulnerabilities originate outside the frontend layer, reinforcing the separation between presentation and backend logic. However, the results demonstrate that frameworks significantly influence the security risk profile, particularly regarding cross-site scripting, dependency management, and configuration practices. Modern utility-first frameworks shift security concerns toward the build pipeline and toolchain, while minimalistic and abandoned frameworks introduce risks related to obsolescence and unpatched “forever-day” vulnerabilities. The study concludes that frontend security depends less on framework choice alone and more on governance, continuous maintenance, and the systematic adoption of secure development and DevSecOps practices.

1. Introduction

Software security plays a central role in contemporary digital society, as computer systems support critical processes in organizations, governments, and individuals’ daily lives. As software becomes more interconnected, distributed, and dependent on data, its exposure to threats such as cyberattacks also increases [1,2,3]. In this context, security is no longer a purely technical requirement but takes on a strategic, organizational, and ethical dimension. From a technical standpoint, software security aims to ensure confidentiality, integrity, and availability of information by protecting systems against vulnerabilities [4,5]. However, the importance of security goes beyond protecting code or infrastructure. Insecure software can compromise entire value chains and drastically affect the reputation of organizations. Software security is also becoming increasingly relevant in the regulatory and social framework. Standards and regulations, such as the General Data Protection Regulation (GDPR), reinforce the responsibility of organizations to design secure systems from the outset, promoting approaches such as security by design and privacy by design [6,7,8,9]. This involves integrating security concerns throughout the entire software development lifecycle, from requirements analysis to maintenance and continuous maintenance.

Security in the design of user interfaces is a natural and indispensable extension of software security, insofar as the interface represents the main point of contact between the system and its users. If, as mentioned above, software security must be integrated throughout the entire development lifecycle and take on a technical, strategic, and ethical dimension, interface design becomes a critical element in ensuring that these principles are put into practice in the everyday use of systems. Poorly designed interfaces can introduce significant vulnerabilities, even when the underlying software is technically robust. Problems such as ambiguous error messages, confusing authentication flows, unclear permissions, or misleading visual cues can mislead users, facilitate social engineering attacks, or lead to unsafe behaviors such as inadvertent credential sharing [10,11]. In this sense, interface security is deeply linked to usability and user experience, requiring a careful balance between protection and ease of use. Furthermore, as with software security in general, security in interface design also has an ethical and regulatory dimension. Interfaces that respect privacy, avoid manipulative patterns, and support informed decisions align with legal requirements and the social responsibility of organizations [12]. Therefore, investing in interface security is not only an aesthetic or functional concern, but an essential factor for the trust and sustainability of digital systems.

The literature on usable security clearly shows that existing research mainly explores the balance or tension between usability and security, highlighting that the application of security measures often reduces usability and that there are still no robust design guidelines that systematically integrate both dimensions. A systematic literature review developed by Di Nocera et al. [13] on usable security shows that there is still a significant gap in terms of standards, methodologies, and formal requirements that can inform development practices that are both secure and usable in real software development contexts—approaches tend to focus on system comparisons rather than specific design frameworks or practical guidelines applicable during the design process from the early stages. It is also recognized that Göktürk [14] also contributes to the literature by focusing on the evaluation of interface models in terms of usability and security perception. However, this type of approach evaluates perceptions and usability metrics without explicitly addressing how modern design frameworks (such as Bootstrap, Foundation, Tailwind, etc.) can introduce technical or architectural vulnerabilities in the context of responsive web design. In this study, the work carried out by Cosgrove [15] deserves mention, as it advocates the use of responsive web design in emergency management contexts for reasons of accessibility and usability. This study emphasizes the benefits of responsive web design in the user experience on critical platforms but does not systematically examine the security risks associated with adopting these adaptive interface approaches. Also noteworthy is the work done by Kaur [16], which focuses primarily on challenges and opportunities in multi-device compatibility, performance, and user experience. An interesting analysis is made of the technical and design requirements in view of the diversity of devices, but the discussion of emerging security risks arising from this increasing complexity of frontends is superficial or non-existent. Therefore, it can be concluded that there is no integrated analysis that: (a) identifies which security risks are introduced or amplified by responsive web design frameworks; (b) compares these risks between different frameworks; and (c) proposes mitigation strategies based on both security perspectives and responsive design requirements. This study addresses an important gap by systematically relating responsive interface design to concrete cybersecurity vulnerabilities. Rather than focusing solely on usability or device compatibility, it proposes a systematization and interpretative classification of known web security risks, combined with the identification and characterization of vulnerabilities associated with widely used frontend frameworks. By integrating these dimensions, the study moves beyond generic security discussions and embeds security-by-design principles within the specific technological context of frameworks that dominate contemporary web development. This approach enables a clearer understanding of how framework characteristics and development practices may influence the emergence, mitigation, or amplification of web security risks. Accordingly, the following research questions are established:

RQ1. What cybersecurity risks arise from the adoption of responsive design frameworks?

This question recognizes that the existing literature has not systematically mapped the types of technical and architectural risks that emerge with responsive web design, particularly because research tends to focus on usability and perception of security, not concrete vulnerabilities introduced by responsive approaches.

RQ2. Are these risks common or do they differ according to the responsive design framework chosen?

This second question is geared toward a comparison between frameworks (e.g., Bootstrap vs. Tailwind vs. Foundation), which is under-explored in the current literature, revealing a gap in how different abstractions and implementations of responsive web design affect the attack surface and protection mechanisms of an interface.

RQ3. What mitigation strategies should be implemented?

This third question is necessary because, even when risks are identified in interface security studies, there is a shortage of practical and oriented strategies that integrate both security requirements and good responsive web design practices, something that the literature on usable security has highlighted as a gap.

2. Literature Review

2.1. User Interface and User Experience

The role of User Interface (UI) and User Experience (UX) is central to the development of digital systems, as both mediate the relationship between users and technology, directly influencing the effectiveness, efficiency, and acceptance of digital solutions. Although often used interchangeably, UI and UX represent distinct, yet deeply interconnected, dimensions of the process of designing and evaluating digital products.

The UI refers to the set of visual, interactive, and structural elements through which the user interacts with a system. It includes components such as buttons, menus, typography, colors, icons, layouts, and interaction patterns. The main role of the UI is to make interaction clear, consistent, and intuitive, facilitating task execution and reducing cognitive load [17,18,19]. In this sense, UI should offer visual consistency, predictability, immediate feedback to user actions, and compliance with established design norms and standards.

In turn, UX encompasses a broader, more holistic perspective of the interaction between the user and the system over time. UX is not limited to the visible interface, but includes the user’s perceptions, emotions, expectations, motivations, and satisfaction levels before, during, and after using the product [20,21]. Its central role is to ensure that the system effectively responds to the real needs of users, providing good user experience. The characteristics of UX include usability, usefulness, credibility, accessibility, and perceived value [22,23].

Despite their differences, UI and UX share important similarities. Both are user-oriented, rely on human-centered design principles, and aim to improve the quality of interaction between people and systems. Furthermore, UI decisions directly influence UX, as visual clarity, consistency, and responsiveness of the interface shape the overall perception of the experience [24,25]. Similarly, a well-defined UX strategy guides UI choices, ensuring that visual and interactive elements serve clear functional and emotional goals [26].

2.2. Security Aspects in Web Development

As web applications take on central roles in data management and communication with users, exposure to cyber threats increases significantly. Thus, security is no longer a complementary element but has become an essential requirement for the quality, reliability, and sustainability of web systems. The importance of security in web development is manifested, first and foremost, in the protection of information [27,28,29]. Web applications often deal with sensitive data, including personal information, authentication credentials, and financial data. Therefore, security breaches can lead to data violations with serious impacts on organizations. Furthermore, security directly influences user trust, as systems perceived as insecure tend to be rejected, regardless of their functionality or usability [30].

Despite its importance, the effective implementation of security in web development faces several structural and technical challenges. One of the main challenges is related to the increasing complexity of modern web architectures. The use of frameworks, third-party libraries, APIs, and cloud services expands the attack surface and makes it difficult to maintain complete control over all system components [31,32,33,34]. Each dependency introduces potential vulnerabilities that can be exploited, especially when they are not properly maintained or updated.

Another critical challenge relates to integrating security throughout the software development cycle. In many contexts, security is treated reactively, being considered only in the final stages of development or after incidents have occurred. This approach hinders the early identification of vulnerabilities and increases correction costs. As recognized by Dutton [35] and Radanliev [36], the adoption of principles such as security by design and secure by default requires cultural and organizational changes that are not always easy to implement, especially in agile environments with high pressure for rapid delivery. In agile methodologies, priority often falls on rapid delivery of functionality and continuous iteration based on user feedback [37,38]. This fast pace can make it difficult to devote sufficient time and resources to risk analysis, security-focused code review, or the implementation of preventive controls, which often require more detailed planning and formal reviews.

Human dimensions are also a key challenge. Programming errors, inadequate configurations, and ignorance of good security practices continue to be recurring causes of incidents [39]. Even technically robust systems can be compromised if users engage in unsafe behaviors, such as reusing passwords or indiscriminately accepting permissions [40,41,42]. This factor highlights the need to align technical security with usability so as not to induce unsafe practices.

Further, the constant evolution of threats poses an ongoing challenge. Literature review studies conducted by Admass et al. [43] and Kuzior et al. [44] acknowledge that attack techniques are becoming increasingly sophisticated, exploiting logical vulnerabilities, data validation flaws, and weaknesses in session management and authentication. Web development therefore requires a dynamic approach to security, based on continuous monitoring and constant updating of protection mechanisms.

Table 1. Common security vulnerabilities.

Security Risk	Description
Exposure of Sensitive Data	Failures in protecting personal, financial, or authentication data (e.g., passwords, tokens), allowing unauthorized access or interception.
Weak Authentication and Session Management	Improper implementation of login mechanisms, password policies, tokens, or session handling, enabling unauthorized access or session hijacking.
Misconfigured Security Settings	Insecure default configurations, excessive permissions, lack of hardening, or missing updates that expose systems to exploitation.
Vulnerable Third-Party Dependencies and Libraries	Use of outdated or insecure frameworks, libraries, or APIs containing known flaws (e.g., documented CVEs).
Access Control Failures	Improper enforcement of authorization rules, allowing users to access restricted data or functions.
Insufficient Communication Security (TLS/SSL)	Lack of encryption or improper certificate configuration enabling interception during data transmission.
Negligent Input Validation and Sanitization	Failure to properly validate or sanitize user input, enabling injection or script-based exploits.
Mixed Content Issues	Loading insecure (HTTP) resources within secure (HTTPS) pages, weakening the overall security model.
Insufficient Testing	Inadequate security and cross-device testing leading to undetected vulnerabilities, particularly in complex or responsive environments.
Insecure APIs	Poorly designed or protected APIs exposing critical functions or sensitive data to unauthorized access.

and

Table 2. Common security attacks.

Security Risk	Description
Code Injection (SQL/Command Injection)	Exploits insufficient input validation to execute malicious database queries or system commands.
Cross-Site Scripting (XSS)	Injects malicious scripts into web pages viewed by other users, compromising sessions, cookies, or data.
Cross-Site Request Forgery (CSRF)	Forces authenticated users to perform unintended actions without their consent.
Denial of Service (DoS/DDoS)	Overloads servers or applications to disrupt availability for legitimate users.

present a summary of the main security vulnerabilities and attacks. Vulnerabilities are weaknesses or misconfigurations in systems, while attacks are actions performed by threat actors that exploit those weaknesses. Each risk listed reflects vulnerabilities that arise from both technical flaws and poor implementation practices, highlighting that web security depends not only on technology, but also on processes, development methodologies, and awareness among the teams involved. Among the risks highlighted are classic attacks such as code injection, Cross-Site Scripting (XSS) [45,46,47], and Cross-Site Request Forgery (CSRF) [48,49], which exploit flaws in input validation and user action control, potentially leading to data manipulation, session compromise, or malicious command execution. There are also risks related to data management and authentication, including exposure of sensitive data and poorly protected sessions, which are critical in applications that handle personal or financial information [50,51]. Moreover, risks related to incorrect configurations and external dependencies are presented, reflecting the growing complexity of modern applications that use third-party frameworks, libraries, and APIs [52,53]. Failures in access control, insecure communication, and inadequate input validation reinforce the need for robust security practices from the early stages of development [54,55]. Finally, denial-of-service attacks and API vulnerabilities illustrate how well-designed systems can still be exploited if there are no continuous monitoring and mitigation [56,57,58].

3. Materials and Methods

3.1. Materials

The selection of frameworks for a scientific study on responsive web design was based on theoretical and practical criteria. Among the criteria considered were technological maturity, diversity of approaches to responsive design, impact on performance, and suitability for different development contexts. At the practical level, adoption by the community was considered, considering its popularity for the year 2024 as recognized by the Daily.Dev community [59] and iExperto [60]. Bootstrap, Tailwind CSS, Foundation, Pure CSS, and Skeleton represent distinct and complementary paradigms, which makes them particularly relevant for robust comparative analysis.

Bootstrap is widely recognized as the most widely used CSS framework in the world. Its scientific relevance stems from its high industrial adoption, extensive documentation, and strong standardization of responsive components based on a consolidated grid system. In empirical studies, Bootstrap serves as a benchmark, allowing newer or minimalist frameworks to be compared with a mature and dominant solution.

Tailwind CSS represents a paradigm shift by adopting a utility-first approach. Its inclusion is justified by its growing popularity in modern projects and its promise of greater flexibility and customization without resorting to predefined components. From a scientific point of view, Tailwind allows us to investigate the impact of declarative design, class atomicity, and developer productivity in the context of responsive web design.

The Foundation stands out for its focus on professional projects and its strong emphasis on accessibility and advanced customization. It is particularly relevant for studies analyzing responsive web design in complex systems, as it offers greater control over responsive layouts and supports demanding business scenarios that are often overlooked in more simplified frameworks.

Pure CSS, developed by Yahoo, takes a minimalist and modular approach. Its relevance lies in its lightness and lack of JavaScript dependencies, making it ideal for studies focused on performance, loading time, and responsive efficiency in resource-limited environments, such as mobile applications or educational contexts.

Finally, Skeleton represents ultralight frameworks designed for small projects or rapid prototyping. Its inclusion is justified by the possibility of analyzing the extent to which minimal solutions can meet the fundamental principles of responsive web design, allowing comparisons with more robust frameworks in terms of scalability and maintenance.

Table 3. Comparative positioning of frameworks for responsive web design.

Framework	Approach	Main Advantages	Main Limitations
Bootstrap	Component-based; grid system	Maturity, consistency, large community	Standardized styles, lower flexibility
Tailwind CSS	Utility-first	High customization, fine-grained layout control	Learning curve, more verbose HTML
Foundation	Modular and advanced	Accessibility, advanced customization	Lower adoption than Bootstrap
Pure CSS	Minimalist and modular	Low footprint, simplicity	Limited features
Skeleton	Ultra-lightweight; basic grid	Simplicity, rapid development	Low scalability

summarizes this comparative analysis by presenting an overview of the approach taken by each framework and exploring the main advantages and limitations associated with each framework.

3.2. Methods

This study adopts a qualitative approach to perform a comparative analysis of the security risks associated with responsive web design frameworks, since these risks are not limited to measurable technical metrics, but involve development practices, architectural decisions, developers’ perceptions, and contexts of use. Unlike purely quantitative analyses that could be performed (e.g., number of reported vulnerabilities), the qualitative approach allows us to understand how and why certain risks emerge in the actual use of frameworks.

From an epistemological perspective, web framework security is a socio-technical phenomenon. Although these frameworks do not execute business logic, their use influences the attack surface through external dependencies, JavaScript integrations, customization practices, update management, and coding standards. A qualitative approach allows us to explore dimensions such as developers’ perceptions of security and decisions regarding configuration and component usage.

The qualitative comparison between the five frameworks also allows us to identify latent risks that are not easily captured by vulnerability databases, such as version obsolescence, excessive dependence on manufacturer examples, or false perceptions of security associated with the popularity of the framework. In addition, this approach favors the construction of an interpretive model that relates framework characteristics (e.g., complexity, maturity, design philosophy) to specific types of security risk.

Ensuring methodological rigor and reproducibility is paramount in security research, especially when evaluating complex software frameworks. In this comprehensive study, the meticulously structured qualitative protocol was developed to assess the security risk profiles of selected frontend frameworks. The research methodology encompassed a decade-long data collection period, spanning from 2014 to 2024. This timeframe was intentionally chosen to trace the technological evolution from traditional component-based architectures to the emergence of modern utility-first paradigms that now dominate the frontend landscape.

To achieve a nuanced understanding of security risks, the study employed a triangulated data collection strategy. Three primary sources formed the backbone of the analysis: (1) vulnerability datasets, with a focus on extracting Common Vulnerabilities and Exposures (CVEs) and security advisories from the National Vulnerability Database (NVD); (2) official framework repositories, which included an in-depth examination of GitHub V 3.15 issue trackers, pull requests, and changelogs; and (3) the peer-reviewed academic literature addressing frontend security, alongside established models such as the OWASP Top 10. This multidimensional approach enabled a robust and holistic evaluation of each framework’s security posture.

The study moved beyond a purely quantitative aggregation of CVEs. Recognizing that such an approach could unfairly disadvantage older, widely adopted frameworks like Bootstrap and might overlook nuanced, pipeline-dependent risks in newer tools such as Tailwind CSS, the research instead leveraged CVEs as qualitative empirical evidence. Each vulnerability identified was methodically mapped to the architectural features of the framework, be it dynamic DOM manipulation, build-time class generation, or the integration of third-party dependency chains. This mapping offered relevant insight into the underlying technical mechanisms that contribute to security risk.

To enhance transparency and objectivity, the empirical review protocol entailed deploying each framework in its default configuration and systematically analyzing its handling of untrusted data and management of the presentation layer. By grounding the characterization of frameworks in documented technical behavior and reproducible architectural analysis, the study ensured that its findings were both reliable and actionable. This rigorous approach not only mitigates subjectivity but also sets a replicable standard for future security evaluations in the rapidly evolving field of frontend development.

Table 4. Phases of the qualitative methodological process.

Methodological Phase	Phase Description	Objective in the Study	Associated Qualitative Techniques
Framework definition	Delimitation of the security risk concept in those frameworks	Establish comparable criteria	Narrative literature review
Case selection	Selection of the five frameworks	Ensure diversity and comparability	Theoretical sampling
Data collection	Analysis of documentation and real-world practices. Installation and use of the frameworks	Identify potential sources of risk	Document analysis, and interpretive analysis
Initial coding	Identification of risk categories	Structure qualitative data	Open coding
Thematic analysis	Grouping of patterns and themes	Compare risks across frameworks	Thematic analysis
Comparative interpretation	Linking framework characteristics and risks	Build analytical explanations	Cross-case analysis
Validation	Critical review of findings	Strengthen scientific credibility	Data triangulation

summarizes the phases of the qualitative methodological process proposed for this comparative analysis.

4. Results

4.1. Security Risks

To ensure a reproducible and non-subjective classification of the identified threats, the comparative mapping (presented in Table 5) was grounded in strict operational criteria using a Y-N-P scale. This scale was designed to capture not only the presence of a risk but its architectural dependency:

• Y (Identified): The risk is explicitly documented via CVEs, official security advisories, or consistently demonstrated in the literature as an intrinsic vulnerability of the framework’s native components or required dependencies (e.g., XSS in native JavaScript modals).
• N (Not Identified): A systematic review of the framework’s architecture, documentation, and vulnerability databases yielded no empirical evidence or logical pathway for this specific risk to materialize directly from the framework’s features.
• P (Potential): The risk’s materialization is conditional. It does not exist as a default vulnerability but can be easily introduced through specific developer configurations, dynamic build-time interpolations (e.g., arbitrary value injection in Tailwind), or the adoption of unsafe legacy practices associated with the framework’s ecosystem.

These operational definitions guarantee that the risk matrix is not based on subjective perceptions but on a traceable evaluation of each framework’s structural and operational characteristics.

Table 5 performs a comparative analysis of security risks across Bootstrap, Tailwind CSS, Foundation, Pure CSS, and Skeleton. This analysis highlights an important principle: responsive web design frameworks operate primarily at the presentation layer, and therefore most critical security vulnerabilities originate outside the frameworks themselves. Nevertheless, these tools can indirectly contribute to security risks through design patterns, dependencies, and developer practices, which justify their systematic examination.

Several high-impact risks, such as code injection, CSRF, weak authentication, insecure APIs, and insufficient communication security, are consistently not identified across all five frameworks. This outcome is theoretically coherent, as these risks are intrinsically associated with server-side logic, session handling, identity management, and infrastructure-level configurations rather than frontend styling or layout systems. The frameworks merely consume backend outputs and do not execute server-side code, reinforcing the separation of concerns between UI and application logic.

XSS emerges as a differentiating risk. Bootstrap and Foundation present a clear exposure due to their reliance on JavaScript-based interactive components, such as modals and tooltips, which historically have been associated with documented Common vulnerabilities and Exposures (CVEs). Tailwind CSS shows a potential risk, particularly when utility classes are generated dynamically or interpolated from untrusted sources during build or runtime. In contrast, Pure CSS and Skeleton, which lack JavaScript components, show no direct XSS exposure, reinforcing the security benefits of minimalism at the UI layer.

Dependency-related vulnerabilities further distinguish the frameworks. Bootstrap and Foundation, especially older versions, depend on legacy libraries such as jQuery, increasing the likelihood of inherited vulnerabilities. Tailwind CSS shifts this risk to the build pipeline, where compromised npm packages or misconfigured tooling may introduce security weaknesses. Pure CSS and Skeleton, with minimal or no dependencies, demonstrate lower exposure in this category.

Other risks, such as exposure of sensitive data, misconfigured security settings, and mixed content issues, are classified as potential across most frameworks. These risks stem from misconceptions about client-side security, particularly the mistaken belief that hiding elements with CSS equates to access control. Additionally, older or abandoned frameworks may include outdated patterns or hardcoded resources that fail to meet modern security standards.

Finally, insufficient testing is a notable concern for frameworks with declining maintenance or rapid evolution. Foundation and Skeleton face risks due to reduced testing against modern browsers, while Tailwind CSS requires rigorous visual and regression testing due to its highly dynamic and configurable nature.

Table 5. Evaluation of the security risks.

Methodological Phase	Bootstrap	Tailwind CSS	Foundation	Pure CSS	Skeleton
Code Injection (SQL/Command Injection)	N	N	N	N	N
Cross-Site Scripting (XSS)	Y	P	Y	N	N
Cross-Site Request Forgery (CSRF)	N	N	N	N	N
Exposure of Sensitive Data	P	P	P	P	P
Weak Authentication and Session Management	N	N	N	N	N
Misconfigured Security Settings	P	P	Y	P	P
Vulnerable Third-Party Dependencies and Libraries	Y	P	Y	N	N
Access Control Failures	P	N	P	N	N
Insufficient Communication Security (TLS/SSL)	N	N	N	N	N
Negligent Input Validation and Sanitization	P	N	P	N	N
Denial of Service Attacks (DoS/DDoS)	N	N	Y	N	N
Mixed Content Issues	P	N	P	P	P
Insufficient Testing	N	P	Y	P	Y
Insecure APIs	N	N	N	N	N

Table 5. Evaluation of the security risks.

Methodological Phase	Bootstrap	Tailwind CSS	Foundation	Pure CSS	Skeleton
Code Injection (SQL/Command Injection)	N	N	N	N	N
Cross-Site Scripting (XSS)	Y	P	Y	N	N
Cross-Site Request Forgery (CSRF)	N	N	N	N	N
Exposure of Sensitive Data	P	P	P	P	P
Weak Authentication and Session Management	N	N	N	N	N
Misconfigured Security Settings	P	P	Y	P	P
Vulnerable Third-Party Dependencies and Libraries	Y	P	Y	N	N
Access Control Failures	P	N	P	N	N
Insufficient Communication Security (TLS/SSL)	N	N	N	N	N
Negligent Input Validation and Sanitization	P	N	P	N	N
Denial of Service Attacks (DoS/DDoS)	N	N	Y	N	N
Mixed Content Issues	P	N	P	P	P
Insufficient Testing	N	P	Y	P	Y
Insecure APIs	N	N	N	N	N

Where applicable, specific and critical CVEs (e.g., CVE-2020-26304 for Foundation, or CVE-2019-8331 for legacy Bootstrap) are explicitly detailed in Section 4.2 to qualitatively illustrate the identified Y/P risks, rather than providing an exhaustive quantitative list.”

4.2. Mitigation Strategies

4.2.1. Comprehensive Defense-in-Depth Strategies

Before examining the specific nuances of each framework, it is imperative to establish an “immune system” for the application. Table 5 demonstrates that while most high-impact server-side risks (e.g., code injection, CSRF, weak authentication, insecure APIs, TLS failures) are consistently marked as “N” across all frameworks, several presentation-layer and configuration-dependent risks (e.g., XSS, vulnerable dependencies, misconfiguration, insufficient testing, mixed content, and CSS-based vectors) remain either “Y” or “P.”

Mitigation strategies must therefore extend beyond generic secure development practices to address the specific architectural and operational characteristics of responsive frameworks. Global HTTP- and browser-level controls remain important for these risks, but responsive frameworks introduce unique vectors that require targeted interventions. For instance, adaptive components such as collapsible menus, off-canvas navigation, modals, and dynamically loaded UI elements in Bootstrap or Foundation expand the interactive surface exposed to the browser, increasing XSS exposure in a manner that is specific to these frameworks’ dynamic DOM manipulation patterns. Similarly, utility-first frameworks like Tailwind CSS shift certain risks to the build pipeline, where dynamically generated class names can produce runtime injection opportunities if not properly constrained. These controls are particularly critical for the risks classified as “Y” and “P” in Table 5, since those risks arise from implementation practices, dependency chains, or dynamic frontend behavior rather than intrinsic backend flaws. If a specific framework flaw allows code injection, these global layers should prevent the resulting execution or data exfiltration.

Content Security Policy (CSP) can be seen as the first line of defense. As documented in the literature [61,62], CSP represents the most robust mechanism available to mitigate content injection attacks, specifically XSS. However, traditional implementation based on domain allowlists has proven fragile in modern ecosystems, where trusted CDNs can host vulnerable scripts or “gadgets” that allow malicious code execution. Contemporary analysis points to the need for a Strict CSP, which abandons trust in domains in favor of cryptographic trust.

For modern frameworks that load resources dynamically (such as bundlers used with Tailwind or Bootstrap 5 JavaScript), the recommended approach uses a nonce (a number used once). The server generates a cryptographically strong random base64 string for each HTTP response. The browser is instructed to execute only scripts that have a nonce attribute matching the value declared in the header. This is particularly relevant for Bootstrap and Foundation, where dynamic components (e.g., modals, dropdowns, tooltips) increase DOM manipulation and therefore XSS exposure.

The configuration of a Strict CSP should follow this architectural structure:

HTTP Content-Security-Policy:     object-src 'none';     script-src 'nonce-{RANDOM}' 'unsafe-inline' 'unsafe-eval' 'strict-dynamic' https: http:;     base-uri 'none';     report-uri https://seuservidor.com/csp-report

The ‘strict-dynamic’ directive is key in this context. It instructs the browser to trust any script that has been loaded by an already trusted script (one with the correct nonce). This solves the compatibility problem with package managers and frameworks that inject secondary scripts or code chunks on demand, common in applications that use Tailwind (via Webpack/Vite) or Bootstrap JavaScript components [63]. The use of ‘unsafe-inline’ in the presence of a nonce is ignored by modern browsers, serving only as a fallback for obsolete browsers, ensuring backward compatibility without sacrificing security.

While script blocking is straightforward, blocking inline styles (style-src) presents significant challenges for UI frameworks. Frameworks such as Bootstrap and Foundation often manipulate the style attribute directly in the DOM via JavaScript to calculate floating element positions (tooltips, dropdowns), collapse heights, and animations. Tailwind CSS, in its Just-In-Time (JIT) mode, can inject critical styles into the header during development or in specific runtime settings [64].

A strict style-src ‘self’ policy often breaks the functionality of these frameworks. Pragmatic mitigation involves:

1.

Nonces for Styles: If the build infrastructure allows it, inject the same nonce used for scripts into the generated <style> tags.

2.

SHA-256 Hashes: For static inline styles that do not change, compute the hash of the content and add it to the policy.

3.

Calculated Risk (unsafe-inline for styles): In many production scenarios with legacy frameworks (such as older versions of Foundation or modified Skeleton), it may be necessary to allow ‘unsafe-inline’ for style-src only. Although this allows CSS injection, the impact is generally less than JavaScript execution, limited to defacement or data exfiltration (covered in Section 4.2.5), but not total session compromise.

The reliance on Content Delivery Networks (CDNs) to host framework files (e.g., loading Bootstrap via jsDelivr or Foundation via cdnjs) introduces a critical supply chain risk. If the CDN is compromised or the file is altered in transit, the application will execute malicious code with the privileges of the application domain. SRI mitigates this risk by allowing the browser to verify the cryptographic integrity of the file before execution.

For frameworks marked as “Y” in dependency exposure (Bootstrap and Foundation), SRI should be considered mandatory. For Tailwind (“P”), SRI must be complemented with npm audit, lockfile integrity verification, and CI/CD dependency scanning due to its heavy reliance on build tooling. The integrity attribute must contain the SHA-384 hash of the expected file. An example of the SRI implementation for Bootstrap is given in

Table 6. Example SRI Implementation for Bootstrap.

Component	Recommended Implementation Code
CSS	<link href=“...” integrity=“sha384-...” crossorigin=“anonymous”>
JS	<script src=“...” integrity=“sha384-...” crossorigin=“anonymous”></script>

.

Data analysis suggests that failure to implement SRI is one of the most common vulnerabilities in quick implementations of frameworks such as PureCSS and Skeleton, which often encourage the use of CDNs in their documentation to “get started quickly.” [65]. For enterprise environments, the top recommendation is to abandon public CDNs in favor of a vendoring (self-hosting) process, where framework files are downloaded, audited, and served from the same domain, eliminating third-party dependencies at runtime.

Cross-Site Scripting (XSS) vulnerability occurs when the application renders untrusted data as executable code. Given that XSS is the only risk marked as “Y” in more than one framework (Bootstrap and Foundation) and “P” in Tailwind (Table 5), strict input sanitization and contextual encoding directly address the primary differentiating risk identified in the comparative analysis. These results also indicate that its manifestation is closely tied to the architectural and interactive features of these responsive frameworks rather than being a generic frontend risk. In Bootstrap and Foundation, dynamic components such as modals, dropdowns, and collapsible menus rely on client-side DOM manipulation, expanding the attack surface in ways that are intrinsic to the framework’s responsive and interactive design. Tailwind, while reducing runtime script execution, introduces potential XSS exposure through build-time class interpolation and dynamically generated utility classes, which is a framework-specific pipeline vulnerability.

In the context of web application security, sanitization refers to the process of cleaning, filtering, or transforming user-supplied input to remove or neutralize potentially dangerous content before it is processed or rendered by the application [66]. Sanitization is applied to any data that comes from untrusted sources, such as user input from forms, URL parameters, API calls, or uploaded files. Sanitization should be performed using robust and maintained libraries, such as DOMPurify, rather than custom regular expressions or ad hoc escape functions, which are historically prone to failure. Encoding should be contextual:

• HTML Context: Characters such as < and > must be converted to HTML entities.
• Attribute Context: Data inserted into attributes (e.g., class=“...” in Tailwind or data-bs-content in Bootstrap) must be strictly validated to prevent attribute “escape” or the injection of event handlers (such as onmouseover).
• JavaScript context: Data interpolated into script blocks must be serialized as secure JSON or encoded in Unicode.

Failure to apply strict sanitization is particularly dangerous in frameworks such as Tailwind, where dynamic class name construction (e.g., bg-[${userInput}]) can lead to arbitrary style injection or layout breakage, as detailed in the Tailwind-specific section [67]. It is important to note that using UI components to hide functionality (e.g., display: none in admin menus) does not constitute access control. Table 5 marks “Access Control Failures” as “P” in Bootstrap and Foundation, reinforcing that authorization must be enforced server-side.

In addition to CSP, HTTP headers harden the browser environment. These headers mitigate multiple “P”-classified risks in Table 5, including Mixed Content Issues, Exposure of Sensitive Data, and CSS-based injection vectors. The following headers should be considered:

• Permissions-Policy (formerly Feature-Policy): This header allows developers to disable powerful and rarely used browser APIs that could be exploited if a framework component were compromised (e.g., geolocation, camera, microphone). For an institutional website using PureCSS or Skeleton, a restrictive policy such as geolocation=(), camera=(), microphone=() drastically reduces the impact of a successful XSS attack.
• X-Content-Type-Options: nosniff: Prevents the browser from “guessing” the file type, mitigating attacks where image files containing malicious code (polyglots) are executed as scripts or styles.
• Referrer-Policy: strict-origin-when-cross-origin: Prevents sensitive data contained in URLs (such as password reset tokens or session IDs) from leaking to third parties via the Referer header.

4.2.2. Analysis and Mitigation: Bootstrap (v5 and Legacy)

Bootstrap maintains its position as the most ubiquitous framework, which paradoxically makes it a frequent and well-documented target. The transition from version 3/4 (based on jQuery) to version 5 (pure JavaScript) significantly altered the security profile, eliminating jQuery-based attack vectors but introducing new complexities in the component API.

One of the most critical areas of risk in Bootstrap 5 lies in the use of components that render dynamic HTML content, such as Tooltips and Popovers. These components allow HTML to be inserted via data attributes (e.g., data-bs-html=“true”), creating a direct vector for XSS if the injected content (via title or data-bs-content) is user-controlled.

Attack Scenario: An attacker inserts malicious script into their “Bio” field in their user profile. If the application renders this bio within a Bootstrap Popover with the HTML option enabled, the script will execute in the browser of any user who views the profile.

Specific Mitigation Strategy:

Bootstrap 5 introduced an internal Sanitization API. However, relying on default settings is insufficient for high-risk applications. Mitigation requires explicit and restrictive configuration of the allowList.

• Strict AllowList Configuration: Modify the default allowlist to remove unnecessary tags and attributes. If the tooltip only needs bold and italics, remove support for img or other elements.
• Integration with DOMPurify: For robust security, it is recommended to bypass Bootstrap’s internal sanitizer in favor of DOMPurify, passing a custom sanitization function when initializing the component.

An example of secure configuration (Bootstrap 5 + DOMPurify) is provided below.

JavaScript const myTooltipEl = document.getElementById('myTooltip'); const tooltip = new bootstrap.Tooltip(myTooltipEl, {   html: true,   sanitizeFn: function (content) {     return DOMPurify.sanitize(content, {       ALLOWED_TAGS: ['b', 'i', 'em', 'strong'], // Strict whitelist       ALLOWED_ATTR:     });   } });

This approach delegates security to a specialized library, ensuring that bypasses in Bootstrap’s native sanitizer do not compromise the application.

It is important to note that many legacy applications still operate with Bootstrap 3 or 4. These versions have known XSS vulnerabilities related to the manipulation of data-target and href attributes in components such as Collapse and Scrollspy (e.g., CVE-2019-8331, CVE-2016-10735). In these versions, an attacker can inject malicious CSS selectors that execute scripts.

Mitigation Strategy:

Since official support for Bootstrap 3 has ended (EOL), mitigation requires Virtual Patching or extended commercial support (such as that offered by HeroDevs).

• Manual Patching: Developers should implement aggressive sanitization of any user input that could end up in data-target attributes.
• WAF (Web Application Firewall): Configuring WAF rules to block requests containing selector injection patterns (such as data-target=“<script>...”) is a necessary compensating layer for systems that cannot be refactored.

4.2.3. Analysis and Mitigation: Tailwind CSS

Tailwind CSS introduces a “utility-first” paradigm that processes HTML classes to generate stylesheets. Unlike Bootstrap, it does not have built-in JavaScript components by default, which reduces the traditional XSS surface area but introduces unique risks related to the process of building and injecting classes.

Tailwind’s arbitrary value feature (e.g., w-[500px]) and dynamic class interpolation are critical risk vectors. If an application constructs class names by concatenating user input strings, it opens the door to Class Injection or, in extreme cases, malicious CSS injection.

Risk Scenario:

Vulnerable code: <div class=“bg-[${corUsuario}]”>.

If an attacker provides url(‘https://malicious.com/leaked-data’) as the “color,” the browser will attempt to load the resource, leaking data or performing unwanted requests (client-side SSRF). Although modern Tailwind attempts to sanitize quotes, the practice of string interpolation is inherently insecure and can break the layout or introduce misleading visual behaviors (visual phishing).

Given the dynamic nature of class generation in Tailwind, mitigating layout and security risks should be accompanied by automated visual regression testing in the CI/CD pipeline.

JavaScript // UNSAFE const className = `text-[${userInput}]`; // SAFE const colorMap = {   red: 'text-red-500',   blue: 'text-blue-500',   default: 'text-gray-500' }; const className = colorMap[userInput] |

Mitigation Strategy:

• Prohibition of String Interpolation: The golden rule in Tailwind is to never interpolate user input directly into class names. Instead, input should be mapped to a predefined list of safe classes (safelist).
• Security Linting: Implement eslint-plugin-tailwindcss in the CI/CD pipeline to detect invalid or dangerous class construction patterns, ensuring that only valid utilities are generated.

It is important to observe that Tailwind’s security is intrinsically linked to its build configuration. The tailwind.config.js file defines the content property, which instructs the compiler where to look for classes.

Configuration Risk: If the content configuration is too permissive (e.g., content: [‘./**/*.{html,js}’]), it may inadvertently scan user upload directories or temporary files. If an attacker manages to upload a file containing thousands of complex utility class names, the build process (especially in JIT mode) can generate a massive CSS file, resulting in a Denial of Service (DoS) at the client resource level or server build time.

Mitigation:

• Restricted Content Scope: Configure the content property to strictly include trusted source code directories (e.g., ./src/components/**/*.jsx), explicitly excluding public, upload, or node_modules directories.
• Dependency Monitoring: Since Tailwind relies heavily on the PostCSS and npm ecosystem, regular audits (npm audit) are essential to prevent supply chain attacks via compromised PostCSS plugins [68].

4.2.4. Analysis and Mitigation: Foundation (ZURB)

The Foundation framework, once a direct competitor to Bootstrap, is currently in a state of minimal maintenance or practical abandonment. This classifies it as a “Forever-Day” risk—discovered vulnerabilities remain unpatched indefinitely by maintainers.

The most critical and persistent vulnerability in Foundation Sites is CVE-2020-26304. It resides in an inefficient regular expression used for URL or input validation, susceptible to Catastrophic Backtracking.

Vulnerability Mechanism:

When processing a specially crafted malicious string (usually long and repetitive), the regex engine enters an exponential processing state due to ambiguity in the regular expression grammar (Nondeterministic Finite Automaton—NFA). This can crash the user’s browser tab (client-side DoS) or, if validation occurs on the server (SSR with Node.js), bring down the service.

Mitigation Strategy (Manual Patching):

As there is no official fix planned, mitigation requires direct intervention in the code:

• Patching via patch-package: Use the patch-package tool to apply fixes directly to the node_modules folder in a persistent manner. It is necessary to locate the vulnerable regex in the Foundation source code and replace it with a secure version that avoids nested quantifiers (e.g., avoid (a+)+).
• Input Size Limitation: Implement strict character limits (maxlength) on all input fields validated by Foundation. ReDoS relies on long strings to scale CPU consumption; limiting input to 255 characters, for example, neutralizes the effectiveness of the attack.

To continue using Foundation safely in 2025, it is necessary to adopt an abandoned software management protocol:

• Vendoring (Internalization): Remove dependency on npm and download the audited source code into the project repository (vendor/foundation). This protects the project against typosquatting on abandoned packages and allows direct application and control of manual security patches.
• Component Isolation: Load only the SCSS/JS modules that are strictly necessary, reducing the available attack surface.

4.2.5. Analysis and Mitigation: PureCSS and Skeleton

PureCSS (Yahoo) and Skeleton (Dave Gamache) represent the extreme of minimalism. Skeleton has not been updated since approximately 2014, and PureCSS is inactive. Although the absence of complex JavaScript reduces XSS vectors, the exclusive reliance on CSS introduces risks of Data Exfiltration via CSS and pattern obsolescence.

In purely CSS frameworks, styling logic relies heavily on attribute selectors. This makes them susceptible to CSS injection attacks, where an attacker injects styles that allow them to read sensitive data from the page without executing JavaScript.

Exfiltration Mechanism:

An attacker can inject a malicious stylesheet like it follows.

CSS input[name="csrf_token"][value^="a"] { background-image: url('http://atacante.com/a'); } input[name="csrf_token"][value^="b"] { background-image: url('http://atacante.com/b'); }

If the CSRF token starts with “a,” the browser attempts to load the corresponding background image, sending a request to the attacker’s server. The attacker logs the request and infers the first character, repeating the process to exfiltrate the entire token [69].

Specific Mitigation Strategy:

• Restricted CSP for Styles: The most effective mitigation is to prevent the loading of unauthorized external images (img-src ‘self’) and block untrusted inline styles. This breaks the exfiltration channel (the loading of the background image).
• Framing Protection: Many CSS injection attacks rely on loading the victim page in an iframe. Configuring X-Frame-Options: DENY or Content-Security-Policy: frame-ancestors ‘none’ prevents this vector [70].
• Style Sanitization: If the application allows user style customization (e.g., profile colors), strictly validate the input to ensure that it is only hexadecimal or RGB codes, rejecting any string that contains a url, expression, or square brackets [ ].

The use of Skeleton in 2025 is, by definition, legacy management. The framework uses floats for layout instead of Flexbox or Grid, which can cause rendering inconsistencies.

• Fork and Own Strategy: Treat Skeleton not as an external dependency, but as an initial boilerplate. Copy the CSS into your project and take full responsibility for its maintenance. Do not expect security fixes.
• Manual Modernization: Replace obsolete practices (such as the old CSS reset included in Skeleton) with modern standards (such as updated normalize.css) to avoid unsafe or inconsistent behavior in modern browsers.

Regarding integrity and due to the age of frameworks of this type, a Mixed Content audit should be performed, ensuring that no hardcoded links to external resources use the http://protocol instead of https://.

4.3. Comparative Summary and Implementation Roadmap

Table 7. Summary of the risks and mitigation strategy associated with each framework.

Framework	Maintenance Status	Primary Risk Vector	Critical Mitigation Action
Bootstrap 5	Active	XSS via Data Attributes (Tooltips/Popovers) (CVE-2019-8331, CVE-2016-10735)	Configure Sanitizer allowList; Use Strict CSP.
Tailwind CSS	Active	Class/Arbitrary Value Injection	Prohibit string interpolation in classes; Restrict paths in content.
Foundation	Inactive/Abandoned	ReDoS (CVE-2020-26304)	Manual regex patch via patch-package; Input size limits.
PureCSS	Inactive	Data Exfiltration via CSS & Supply Chain	Vendoring CSS files (remove from npm); Strict CSP for img-src and style-src.
Skeleton	Abandoned (Boilerplate)	Obsolete Standards & CSS Injection	Total vendoring; Manual audit of forms and grids; Update resets.

consolidates the security posture and mitigation focus for each framework, providing an overview for decision makers. Actively maintained frameworks such as Bootstrap 5 and Tailwind CSS present risks mainly linked to dynamic frontend features. Bootstrap 5 is primarily exposed to cross-site scripting through data attributes used in JavaScript components, requiring strict sanitization and the enforcement of a robust Content Security Policy. Tailwind CSS, while also active, faces risks associated with class and arbitrary value injection, which can be mitigated by restricting dynamic class generation and tightly controlling content scanning paths. In contrast, Foundation, PureCSS, and Skeleton are inactive or abandoned, shifting the risk profile toward unpatched vulnerabilities, supply chain exposure, and outdated standards. Foundation’s identified ReDoS vulnerability necessitates manual patching and defensive input constraints. PureCSS raises concerns around data exfiltration through CSS and dependency trust, making local vendoring and strict CSP directives essential. Skeleton, as an abandoned boilerplate, requires comprehensive manual audits and full vendoring to reduce risks arising from obsolete CSS practices.

Frontend framework security is not a product, but an ongoing process of configuration and vigilance. For Bootstrap and Tailwind, the battle is against misconfiguration: ensuring that sanitizers are active and that the build process is secure. For Foundation, PureCSS, and Skeleton, the battle is against entropy and abandonment: organizations must take on the role of maintainers, internalizing the code and applying fixes manually.

Immediate adoption of a nonce-based CSP as a universal protection layer is recommended, along with the integration of static analysis tools (SAST) into the development pipeline to detect insecure patterns of use of these frameworks before they reach production. The ultimate responsibility lies with the engineering team to treat the frontend not as a benign presentation layer, but as a critical component of the information security architecture.

5. Discussion

The results identified in this study show strong convergence with classic and recent literature on web application security, while revealing emerging risk vectors associated with the evolution of frontend frameworks and development practices. A first aspect aligned with consolidated studies is the finding that most critical vulnerabilities (e.g., code injection, CSRF, weak authentication, insecure APIs, or TLS communication failures) are not inherent to responsive web design frameworks. This distinction clarifies that responsiveness itself—understood as adaptive layout mechanisms based on breakpoints, fluid grids, and media queries—does not directly generate these vulnerabilities. Rather, such risks remain primarily located in the backend and infrastructure layers. As argued by the layered security literature, these risks essentially belong to the domain of the backend and business logic, reinforcing the validity of the principle of separation of responsibilities between presentation and application core [71,72,73].

To enhance analytical precision, it is essential to distinguish between risks intrinsically associated with responsive frameworks and those that reflect general web application development practices or governance failures. Intrinsic risks are those that emerge directly from architectural or functional characteristics of the frameworks (e.g., client-side interactivity, DOM manipulation, breakpoint-driven rendering logic, or build-time class generation). In contrast, risks related to authentication, API protection, TLS configuration, dependency governance, or insufficient testing are systemic development concerns that would affect any web application, regardless of whether it adopts a responsive framework.

However, the results also confirm that frameworks are not neutral from a security standpoint. When examining the responsive dimension specifically, the study shows that adaptive components (e.g., collapsible menus, off-canvas navigation, dynamically loaded UI elements for mobile contexts) often rely on JavaScript-driven state changes that expand the interactive surface exposed to the browser. This expansion of the client-side attack surface constitutes an intrinsic risk of certain responsive frameworks, particularly those that embed rich interactive behavior as part of their core design philosophy. The emergence of XSS as a differentiating risk between frameworks is consistent with previous investigations such as Krishnan et al. [74] and Li et al. [75], which point to JavaScript-based interactive components as privileged attack surfaces. In responsive frameworks like Bootstrap and Foundation, mobile-first interactive elements (e.g., togglers, modals, and dropdown) are tightly coupled with dynamic DOM manipulation, which increases the need for robust sanitization and secure configuration. Bootstrap and Foundation, due to their historical dependence on dynamic components and permissive APIs, align with studies that document recurring CVEs in widely adopted libraries. Novelty lies less in the existence of the risk and more in its persistence even in modern versions, demonstrating that functional complexity—partly driven by cross-device adaptability—continues to generate sanitization and configuration challenges.

On the other hand, Tailwind CSS introduces a risk profile that is still largely unexplored in the traditional literature. Although it significantly reduces the classic XSS surface area by not including JavaScript by default, it shifts the security issue to the build process and dynamic class generation. From a responsiveness perspective, Tailwind’s utility-first and breakpoint-centric approach means that adaptive behavior is encoded directly in class composition, frequently generated or interpolated at build time. This build-time dependency and dynamic class construction represent intrinsic risks specific to the architectural model of utility-first responsive frameworks. However, threats such as supply chain compromise, npm package poisoning, or CI/CD misconfiguration should be understood as broader software engineering and DevSecOps challenges rather than risks uniquely created by responsiveness itself. This result points to a paradigm shift: risks are no longer limited to runtime and now emerge in the development pipeline, highlighting the growing relevance of toolchain security. Recent literature on supply chain attacks [76] and DevSecOps [77,78] finds fertile ground here, since misconfigured content paths, unsafe interpolation of responsive utility classes, or uncontrolled plugin usage can generate denial-of-service effects, CSS injection, or visual manipulation with an impact on user trust.

In minimalist and abandoned frameworks, such as PureCSS and Skeleton, the results reinforce an emerging debate about security through simplicity versus security through obsolescence. The absence of JavaScript reduces classic vectors, but the latest literature on attacks based exclusively on CSS demonstrates that minimalism does not equate to security [79,80,81]. Although their responsive mechanisms rely mainly on static grids and media queries, the study shows that even purely declarative adaptive layouts can be leveraged for sophisticated attacks (e.g., CSS-based data exfiltration or UI redressing tailored to specific viewport conditions). Here again, the intrinsic element lies in the use of CSS-based responsive selectors and attribute-driven styling logic, whereas broader issues such as outdated coding standards or lack of modernization reflect governance and lifecycle management decisions rather than structural properties of responsive design. The identification of risks of data exfiltration via CSS, still little considered in traditional analyses, represents a relevant and emerging contribution, emphasizing that even layers considered “passive” and purely responsive can be exploited in advanced attack contexts.

Another relevant finding is the clear association between maintenance status and risk profile. Abandoned frameworks transform known vulnerabilities into “forever-days,” a concept that is increasingly discussed in the security literature [82,83,84]. It is important to stress that this phenomenon is not intrinsic to responsive design frameworks per se, but to software lifecycle management and governance maturity. In this sense, the study shows that risk does not arise solely from the code, but also from the absence of governance, updates, and continuous testing. Unlike zero-days, which exploit vulnerabilities that are still unknown, forever-days represent a structural and cumulative risk, since technical information about the flaw is public, stable, and easily reusable by attackers, significantly reducing the cost of exploitation over time. In this context, this study highlights that the risk does not stem solely from the intrinsic quality of the code, but above all from the absence of software governance, regular update cycles, and systematic testing and auditing practices. The lack of maintenance means that the framework no longer evolves in line with the technological ecosystem, remaining dependent on obsolete standards and discontinued libraries that are no longer secure in the face of current browser capabilities and modern attack techniques. In addition, the lack of continuous testing against new versions of browsers and rendering engines increases the likelihood of unexpected behavior that can be exploited maliciously.

Beyond confirming patterns identified in the prior literature, this study offers several novel contributions to the understanding of security in responsive web frameworks. First, it provides a refined analytical distinction between intrinsic framework-level risks and broader development or governance-related vulnerabilities, enabling greater conceptual clarity in attributing security responsibility across architectural layers. Second, it advances the discussion by explicitly linking responsive design mechanisms—such as breakpoint-driven rendering, adaptive component loading, and utility-based class generation—to specific attack surface expansions, thereby moving beyond generic “frontend insecurity” claims toward framework-sensitive risk profiling. Third, the study identifies a paradigm shift from runtime-centric vulnerabilities to build-time and pipeline-based risks, particularly in utility-first ecosystems like Tailwind CSS, highlighting how responsiveness increasingly intersects with toolchain security and DevSecOps maturity. Additionally, the analysis foregrounds emerging vectors such as CSS-based data exfiltration and viewport-conditioned UI manipulation, challenging the assumption that declarative styling layers are inherently passive or low risk. Finally, by integrating maintenance status into the comparative risk model and framing abandoned frameworks as generators of “forever-day” exposure, the study contributes a lifecycle-governance dimension that connects technical vulnerability persistence with ecosystem sustainability.

6. Conclusions

6.1. Final Considerations

The conclusions of this study show that responsive web design frameworks are not, in themselves, the source of the most critical vulnerabilities in web applications, confirming the structural separation between frontend risks and problems inherent to the backend, infrastructure, and session management. However, the results show that frameworks significantly influence the risk profile, particularly regarding XSS and attack surfaces associated with interactive components and configuration practices. Frameworks with greater functional complexity maintain persistent risks, while utilitarian approaches such as Tailwind CSS shift security to the development pipeline, reinforcing the importance of toolchain security and DevSecOps practices. Additionally, the study shows that minimalism does not automatically equate to security, as CSS-based attacks can exploit even layers considered passive. Finally, the analysis confirms that maintenance status is a critical risk factor, with abandoned frameworks being particularly vulnerable to “forever-days.” Thus, security depends less on the isolated choice of framework and more on software governance, continuous maintenance, and the systematic adoption of secure development best practices.

6.2. Implications for IT Professionals

The implications of this study for IT professionals are relevant and multidimensional, requiring a critical reassessment of the role of the frontend in the overall security architecture of web applications. A first relevant impact lies in the need to abandon the perception, still common in organizational contexts, that responsive web design frameworks are technologically neutral from a security standpoint. The results show that, although most critical vulnerabilities continue to emerge in the backend, decisions made in the frontend directly influence the attack surface, the likelihood of exploitation, and the impact of configuration failures. For IT professionals, this implies greater responsibility in the selection, configuration, and ongoing governance of the frameworks adopted.

Another key aspect is the shift in focus from runtime security to the development pipeline. Modern frameworks such as Tailwind CSS demonstrate that unsafe practices in the build process, dependency management, and configuration definition can pose risks as significant as classic runtime vulnerabilities. For technical teams, this reinforces the importance of integrating DevSecOps principles, including regular dependency audits, strict control of configuration files, and the incorporation of static analysis and security linting tools into the continuous development process. Therefore, security is no longer a final control, but a continuous process distributed throughout the entire development cycle.

The study also highlights the strategic importance of software maintenance and governance. For IT professionals responsible for legacy systems, using abandoned frameworks means explicitly taking on the role of maintainer, with associated costs in auditing and manual patching. The notion of “forever-days” shows that the absence of updates transforms known vulnerabilities into structural risks, requiring informed decisions between refactoring, technological replacement, or the adoption of compensatory mechanisms such as WAFs and virtual patching.

Additionally, the analysis demonstrates that minimalism is not synonymous with security. IT professionals must recognize that even frameworks based exclusively on CSS can be exploited through advanced techniques, such as data exfiltration and style injection, which reinforces the need for strict CSP policies and a thorough understanding of the browser security model.

Finally, the findings of this study indicate the need for a cultural shift within organizations. Thus, the frontend should be treated as a critical component of security architecture and not just as an aesthetic layer. For IT professionals, this translates into the need for greater collaboration between frontend, backend, and security teams, and the adoption of a systemic approach in which secure configuration, active maintenance, and continuous monitoring are as important as the initial choice of framework.

6.3. Limitations and Future Research Directions

Despite the relevant contributions, limitations have also been identified that may give rise to proposals for future work. First, the analysis is predominantly based on a qualitative and interpretative approach, based on a review of technical documentation, vulnerability reports, and best practices reported in the literature and by development communities. Although this approach is adequate for identifying patterns and risk vectors, it does not allow for quantifying the actual frequency or empirical impact of vulnerabilities in production environments, limiting the statistical generalization of the results.

A second limitation concerns the selection of frameworks analyzed. The study focuses on five widely known frameworks but excludes other relevant ecosystems, such as frameworks based on reactive components, whose security model may differ substantially. Similarly, the analysis does not consider significant variations introduced by integrations with backend frameworks that may amplify or mitigate the risks identified in the frontend.

As future work, we recommend conducting empirical studies based on code analysis, controlled penetration testing, and laboratory experiments to measure the actual impact of identified vulnerabilities. Longitudinal investigations could analyze how the evolution of frameworks and browsers changes attack vectors over time. Another promising line of research is to study the interaction between frontend frameworks and DevSecOps practices, assessing how automated tools, organizational policies, and team training influence risk reduction. Finally, future studies could delve deeper into emerging threats, such as attacks based exclusively on CSS or the supply chain, contributing to a more holistic model of security in frontend development.