1. Introduction
An Application Programming Interface (API) is a structured interface that enables communication and interaction between software systems, applications, or services [
1]. APIs expose specific functionalities and data through defined rules, allowing software components and distributed systems to exchange information without requiring direct access to underlying implementations [
2,
3] (
Figure 1). In modern software engineering, APIs have become fundamental building blocks for modular development, software reuse, and distributed system integration [
4]. Libraries, frameworks, cloud platforms, and web services commonly expose APIs to simplify interoperability between client applications and backend systems [
5]. As software ecosystems continue to expand, APIs increasingly influence system scalability, maintainability, and long-term adaptability [
2].
Beyond technical interoperability, web APIs also affect developer productivity and software usability. Prior studies have shown that well-designed APIs can reduce development effort, simplify integration tasks, and improve maintainability by providing clearer and more consistent interfaces [
1,
4]. Web APIs additionally support modular and scalable architectures in which services can evolve independently without significantly disrupting dependent systems [
2]. However, poorly designed APIs may introduce implementation complexity, increase developer confusion, and contribute to integration errors or insecure usage practices [
1]. Existing API usability research further emphasizes that unclear documentation, inconsistent interface behavior, and insufficient usability evaluation can negatively affect developer experience and increase misuse risks [
4].
Although APIs include local libraries, operating-system interfaces, and framework-level interfaces, this review focuses specifically on web APIs exposed through HTTP/HTTPS communication models. This focus is motivated by the growing dependence of modern web applications, cloud services, mobile platforms, and microservice architectures on web APIs as primary integration mechanisms. At the same time, web APIs have become increasingly attractive attack surfaces for cyber threats and large-scale exploitation campaigns, particularly when authentication, data exposure, and input-handling practices are weak or inconsistently applied [
6,
7]. Recent industry reports indicate that compromised APIs are frequently involved in ransomware operations, unauthorized data exposure, credential abuse, and remote exploitation attempts [
8,
9]. Therefore, web API security has become a critical concern not only for technical interoperability but also for the resilience, trustworthiness, and operational security of modern software ecosystems.
Web APIs have become common targets of cyberattacks because they act as gateways to sensitive services, databases, and distributed application components. Improperly secured APIs may expose back-end systems to unauthorized access, injection attacks, data leakage, malicious code manipulation, and denial-of-service conditions [
6,
7]. Prior studies further show that recurring web API weaknesses are frequently associated with insecure implementation practices, weak validation mechanisms, insufficient developer awareness, and inconsistent integration of security controls across the software development lifecycle [
10,
11,
12,
13,
14]. Therefore, web API security should be treated as a continuous software engineering concern rather than an isolated implementation task.
To address these growing security challenges, the Open Web Application Security Project (OWASP) [
11,
12] provides widely adopted guidance for identifying and categorizing critical application and web API security risks. The OWASP Top 10 (2021) highlights recurring weaknesses such as broken access control, injection vulnerabilities, insecure design, and security misconfiguration, many of which continue to appear in modern web API deployments, as shown in
Table 1. The table highlights that many of the most critical web application risks continue to originate from weaknesses related to improper input validation, insecure access control, and insecure implementation practices. These recurring categories reinforce the importance of integrating security considerations early within API design and development processes. In addition, the OWASP API Security Top 10 (2023) extends this focus specifically toward API-related threats, including excessive data exposure, broken object-level authorization, and unsafe API consumption [
12]. The continued prevalence of these vulnerabilities suggests that many web API security failures are not solely caused by protocol limitations but are also influenced by implementation decisions, usability challenges, inconsistent security practices, and gaps in developer security awareness. Therefore, understanding these recurring weaknesses is essential for developing more resilient, secure, and developer-aware web API ecosystems.
This study presents a systematic and developer-oriented review of contemporary web API security research, with emphasis on the commonly reported vulnerabilities, insecure development practices, usability concerns, and architectural factors that contribute to insecure API ecosystems. Unlike prior surveys that primarily focus on attack taxonomies, isolated mitigation techniques, or general web application vulnerabilities, this review examines how technical weaknesses intersect with developer practices, API usability, security integration challenges, and the practical limitations of existing security analysis approaches [
6,
7]. Existing literature often provides limited discussion regarding how developers interpret security requirements, apply secure coding practices, or integrate security mechanisms effectively during web API development [
13,
14]. The study further synthesizes evidence from academic and industry literature to provide a broader analytical perspective on why recurring web API vulnerabilities continue to persist despite the availability of established security mechanisms and defensive guidelines.
The intended audience of this work includes software developers, API designers, cybersecurity researchers, security practitioners, and organizations seeking to improve secure web API development and deployment practices. To guide this review, the following research questions (RQs) are investigated:
RQ1: What developer-centric and usability-related factors contribute most significantly to recurring security weaknesses in modern web APIs?
RQ2: How do different web API architectures influence the manifestation and persistence of specific vulnerability classes, and what implementation-related factors explain these differences?
RQ3: To what extent do existing security tools and research approaches effectively support the detection or mitigation of web API vulnerabilities, and what limitations remain in their practical adoption and evaluation?
The primary contribution of this paper is to provide a structured and developer-focused synthesis of the current web API security landscape by examining the recurring security problems, implementation flaws, architectural considerations, and usability challenges discussed throughout the literature. Rather than focusing solely on attack taxonomies or isolated mitigation techniques, this review connects technical vulnerabilities with the broader software engineering and developer-related factors that influence insecure web API practices. The main contributions of this study are summarized as follows:
Provides a structured review of recent studies addressing web API vulnerabilities, insecure development practices, and security challenges in modern web applications.
Synthesizes and categorizes existing literature on common web API-related vulnerabilities, including injection flaws, authentication weaknesses, access-control issues, and other recurring security risks affecting web APIs.
Examines how web API architectures, design decisions, and usability-related factors influence vulnerability exposure, security adoption, and mitigation practices.
Discusses the practical role, limitations, and research challenges associated with security analysis and vulnerability detection approaches, including static analysis techniques used during secure software development.
These contributions establish a broader understanding of the technical and human-centered factors that shape modern web API security challenges. By linking commonly reported vulnerabilities with implementation practices, architectural decisions, and developer-oriented concerns, this review highlights several gaps that continue to affect the effectiveness of current web API security approaches. Based on these observations, the following objectives guide the scope and analytical focus of this review:
Identify and analyze the most critical security vulnerabilities affecting modern web APIs, including injection vulnerabilities, authentication and authorization weaknesses, denial-of-service (DoS) risks, and cross-site scripting (XSS)-related threats.
Examine how web API architectures, implementation practices, and design patterns contribute to the emergence and persistence of API security vulnerabilities.
Investigate the usability, adoption, and practical limitations of existing web API security mechanisms and vulnerability detection approaches discussed in the literature.
Provide a structured synthesis of recent web API security research to support future studies, secure software engineering practices, and improved security awareness among developers and practitioners.
Several previous review studies have examined vulnerabilities and mitigation techniques in traditional web applications. For example, Deepa et al. [
15] reviewed approaches for securing web applications against injection and business logic vulnerabilities, with particular attention to SQL injection and XSS attacks. Similarly, Zhang et al. [
16] analyzed the effectiveness and efficiency of web application vulnerability detection approaches and highlighted limitations in existing evaluation practices. However, these studies primarily focused on traditional web application environments and general vulnerability detection mechanisms rather than the broader security challenges specific to modern web APIs. In contrast, this study focuses specifically on web API security and emphasizes the relationship between web API vulnerabilities, architectural decisions, developer practices, usability concerns, and security analysis approaches. In addition, this review incorporates recent developments in web API security research, including evolving API threat landscapes, API-specific attack surfaces, and the growing reliance on automated security analysis techniques within modern software development workflows.
The organization of this paper is as follows:
Section 2 outlines the methodology used to retrieve and analyze the relevant literature.
Section 3 presents a taxonomical characterization that provides essential background information on APIs.
Section 4 discusses the most common and impactful security vulnerabilities affecting APIs.
Section 5 presents the deeper synthesis and critique. Finally,
Section 6 summarizes the findings of the study and highlights possible directions for future research.
2. Systematic Literature Review Methodology
2.1. Reporting Guidelines
This systematic review was conducted and reported in accordance with the PRISMA2020 guidelines [
17]. The review protocol was not registered in a public database.
2.2. Information Sources and Search Strategy
To fulfill the objectives of this paper, a structured literature review was conducted between February and October 2023. Although the primary search window covered February to October 2023, the included studies were revalidated during manuscript revision to ensure that all sources remain current and relevant to contemporary API security research. The search targeted high-impact digital libraries in computer science and cybersecurity, including Google Scholar, IEEE Xplore, ACM Digital Library, DBLP, ScienceDirect, and SpringerLink. An iterative keyword-based search strategy was employed to ensure comprehensive coverage. The primary search terms were selected based on their relevance to API security and were expanded through the use of synonyms and contextually related phrases to broaden the scope while maintaining focus. A representative search string was: (“API” OR “Application Programming Interface”) AND (security OR vulnerability OR attack OR misuse OR authentication OR authorization) AND (developer OR usability OR “static analysis” OR SAST OR tools). Database-specific syntax was adapted as needed, and backward and forward snowballing were also performed. The complete list of primary keywords and their analogs is presented in
Table 2.
2.3. Eligibility Criteria
Inclusion: (i) peer-reviewed studies published between 2018 and 2023; (ii) articles written in English; (iii) primary focus on API security, including vulnerabilities, misuse patterns, developer challenges, or defenses; (iv) studies that provide technical or conceptual insights into common API-related security threats; (v) accessible full-text articles.
Exclusion: (i) non–peer-reviewed sources (e.g., blogs, white papers, or non-academic reports); (ii) studies not centered on API security (e.g., general software vulnerabilities without direct API relevance); (iii) duplicate records identified during database searches; (iv) short abstracts, posters, or incomplete works; (v) inaccessible or unavailable full texts.
2.4. Study Selection Process
A total of 292 records were initially identified across all databases. After removing 25 duplicate records, 272 unique studies remained for title and abstract screening. Two reviewers independently screened the studies based on the predefined eligibility criteria, and disagreements were resolved through discussion with a third reviewer. Following the screening phase, 222 records were excluded because they did not sufficiently address web API security, developer-related factors, or web API-related vulnerabilities. The remaining 50 studies underwent full-text assessment and satisfied the inclusion criteria for qualitative synthesis.
The final set of 50 studies was not determined by a predefined numerical target but rather by the outcome of the PRISMA-guided screening and eligibility process. During the full-text assessment stage, the selected studies consistently covered the major analytical themes identified throughout the review, including web API vulnerabilities, misuse patterns, developer-related challenges, usability concerns, and mitigation approaches. Many excluded studies either showed substantial thematic overlap with the included literature or lacked sufficient relevance to the defined scope of web API security.
As the review process progressed, additional studies produced diminishing analytical variation and largely reinforced previously identified themes, vulnerability patterns, and implementation concerns. The selected studies also provided coverage across different API architectural styles, security challenges, mitigation strategies, and research perspectives reported in both academic and industry-oriented literature. Therefore, the final study set was considered sufficient for qualitative synthesis, comparative thematic interpretation, and the analytical objectives of this review.
Figure 2 presents the PRISMA 2020 flow diagram summarizing the identification, screening, eligibility, and inclusion process.
2.5. Data Extraction
For each of the 50 included studies, we extracted the following information using a standardized data extraction form that was piloted and refined iteratively: bibliographic details (authors, title, year, and venue), API domain, and specific categories of vulnerabilities or misuse patterns (e.g., injection, broken authentication, excessive data exposure). We also recorded information on developer-centric factors, threat models, and evaluation setups, including datasets and static analysis tools where applicable. In addition, we captured the key findings of each study to support synthesis and comparison across the literature. This structured extraction process improved consistency across the reviewed studies and supported a taxonomy-driven synthesis of findings related to web API vulnerabilities, architectural characteristics, usability concerns, developer-side challenges, and security mitigation practices.
2.6. Risk of Bias and Study Quality
Because this study is based on a systematic review of previously published literature, no new experimental data were generated. To reduce potential selection and interpretation bias, the review process followed predefined inclusion and exclusion criteria together with a PRISMA-guided study selection methodology. The methodological quality and relevance of the selected studies were assessed using a structured qualitative evaluation framework developed for this review. The framework examined four primary dimensions: (i) relevance to web API security, (ii) clarity and depth of vulnerability analysis, (iii) discussion of developer-centric or usability-related factors, and (iv) methodological transparency. Each study was reviewed against these dimensions to determine whether it provided sufficient technical depth, practical relevance, and alignment with the objectives of this review.
Studies that lacked direct relevance to web APIs, focused primarily on unrelated software domains, provided insufficient discussion of security implications, or lacked sufficient methodological clarity were excluded during the screening and eligibility phases. In addition, the selected studies were categorized according to web API architectural models, vulnerability classes, usability concerns, mitigation approaches, and evaluation characteristics to improve consistency during synthesis and comparative analysis.
Rather than applying a formal numerical scoring model, this review employed a structured qualitative assessment approach to support reproducibility and reduce subjective interpretation during study selection and synthesis. This approach was considered appropriate because the reviewed literature exhibited substantial heterogeneity in research objectives, evaluation methods, datasets, implementation environments, and reporting styles. Nevertheless, some limitations remain, including possible publication bias, database selection bias, and variation in the methodological rigor of the included studies.
2.7. Synthesis Methods
A narrative synthesis approach was employed to analyze and integrate the findings from the selected studies. The synthesis was guided by a taxonomy-driven framework that categorized the literature into major dimensions, including web API architectural styles, security vulnerabilities, misuse patterns, usability concerns, and developer practices. This structure enabled the identification of recurring themes, relationships among vulnerability causes, and gaps in existing research.
A quantitative meta-analysis was not feasible because of substantial heterogeneity across the reviewed studies in terms of research objectives, evaluation methods, datasets, implementation environments, and reported outcomes. Instead, the review focused on comparative interpretation and thematic analysis to identify common security weaknesses, recurring implementation problems, and emerging challenges affecting web API ecosystems.
Particular attention was given to studies discussing the interaction between technical vulnerabilities and human-centered factors such as API usability, developer practices, documentation quality, and secure development workflows. This analytical perspective supported the development of a conceptual understanding of how implementation complexity and developer behavior contribute to recurring web API security weaknesses. The completed PRISMA 2020 checklist is provided in the
Supplementary Materials.
3. Background and Foundational Concepts of Web APIs
This section provides a structured overview of the foundational aspects of Application Programming Interfaces (APIs), offering an essential context for understanding their security implications. It introduces the core dimensions of APIs, including their definition, historical evolution, classification types, usability characteristics, significance in modern systems, and the primary challenges developers face in designing and maintaining them.
3.1. Definition and Scope of APIs
Application Programming Interfaces (APIs) are reusable software interfaces that enable communication and interaction between software components, applications, or services. Robillard et al. [
18] define an API as “the interface to a reusable software entity used by multiple clients outside the developing organization, and that can be distributed separately from environment code.” This definition highlights the modularity and reusability of APIs across independent development environments. APIs allow software components to expose specific functionalities to external consumers without revealing internal implementation details, thereby supporting abstraction, modularity, and interoperability across systems.
APIs have become increasingly central to modern software engineering, particularly in web-based applications, cloud computing, and distributed systems. Their widespread adoption has enabled seamless service integration, automation, and large-scale interoperability between heterogeneous platforms [
19]. However, as APIs continue to evolve into primary integration layers for interconnected systems, they also introduce new operational and security challenges related to usability, implementation complexity, and exposure of sensitive functionality.
3.2. Evolution of API
API evolution refers to the continuous modification of API structures, behaviors, and interfaces as developers introduce new features, improve performance, fix defects, or adapt to changing technological requirements [
20]. These changes may include method renaming, parameter modifications, interface restructuring, refactoring activities, or the deprecation of obsolete functionality [
21]. Because APIs serve as communication layers between dependent software systems, even minor changes can significantly affect client applications and development workflows. As a result, API evolution requires balancing innovation with backward compatibility to minimize disruption for existing consumers [
2]. This challenge becomes particularly significant in large-scale and publicly accessible APIs, where developers must coordinate versioning, documentation, migration guidance, and release management carefully to preserve usability and maintain adoption across evolving software ecosystems.
The increasing complexity of modern software systems and the widespread reliance on distributed services and web-based integration architectures have accelerated the importance of API evolution research [
22,
23,
24]. Prior studies emphasize that web APIs must continuously evolve to remain useful, secure, and competitive while simultaneously preserving stability for dependent applications [
2,
25]. However, frequent API modifications can introduce migration difficulties, compatibility problems, and increased maintenance overhead for developers consuming these APIs [
26,
27]. Research has further shown that rapidly evolving APIs often require developers to adapt applications under tight release cycles, increasing the likelihood of implementation errors, insecure workarounds, or delayed adoption of updated security practices [
25,
28]. API evolution is not solely a technical maintenance process; it also represents a usability, documentation, and developer-support challenge that directly influences software reliability, maintainability, and security resilience.
3.3. API Taxonomy and Classification
To provide a structured understanding of the web API landscape, this study adopts an established taxonomy-based classification that organizes APIs along three complementary dimensions: access scope, architectural style, and intended purpose. As illustrated in
Figure 3, these dimensions capture how APIs are exposed to consumers, how they are designed and implemented, and the functional roles they serve within modern software ecosystems.
The access dimension characterizes how APIs are made available, including public, private, partner, and composite APIs. The architectural style dimension distinguishes APIs based on their interaction and communication models, encompassing paradigms such as REST, SOAP, GraphQL, RPC, and event-driven designs. The purpose dimension reflects the functional role of APIs within systems, such as enabling system integration, orchestrating business processes, or delivering user-facing experiences.
Together, these dimensions provide a structured contextual perspective for understanding the diversity of web APIs without associating security properties inherently with any single category. Instead, previous studies emphasize that security outcomes emerge from how these dimensions interact with developer practices, configuration decisions, and implementation choices, rather than from the classification itself.
Although foundational studies [
29,
30] provide taxonomies of APIs and their operational scope, more recent work emphasizes the need to balance openness and control when exposing API functionalities. This evolving typology of web APIs has influenced how platforms deliver services, authenticate access, and scale distributed systems, reinforcing the relevance of taxonomy-based perspectives for understanding contemporary API ecosystems.
These three dimensions play different complementary roles in contextualizing how web APIs are designed, exposed, and consumed. Industry-oriented classifications similarly distinguish between access-oriented API types (e.g., public, internal, partner, and composite APIs) and architectural protocol styles (e.g., REST, SOAP, GraphQL), highlighting the practical relevance of multi-dimensional API taxonomies in real-world systems [
31]. These classifications are commonly used in practice to clarify how APIs differ in their technical interaction models, in their exposure policies, and in their integration roles within larger software ecosystems [
32,
33]. In this context, the access scope dimension influences the exposure and threat surface of APIs by determining who can interact with them and under what constraints. The intended purpose dimension reflects how APIs are embedded within system workflows, influencing data sensitivity, operational criticality, and potential impact in case of misuse.
However, while access scope and purpose frame the operational context of APIs, the architectural style directly governs how requests are structured, processed, and validated. As a result, architectural decisions have a more immediate and observable influence on the emergence of security vulnerabilities, particularly those related to input handling, authorization logic, and request complexity.
While this taxonomy serves as a general foundation, this review intentionally focuses on the architectural style dimension. In particular, the analysis focuses on RESTful, SOAP, and GraphQL APIs because these styles are widely adopted in contemporary systems and are frequently associated with the security vulnerabilities examined in this review. Accordingly, the following subsections examine these architectural styles in greater detail, highlighting their design characteristics and the security challenges that arise in practice.
These dimensions influence how security weaknesses emerge and propagate across web API ecosystems. For example, access scope affects exposure boundaries and trust assumptions, while architectural style shapes request processing, data exchange behavior, and input validation complexity. Similarly, the intended purpose of web APIs influences operational sensitivity and the potential impact of misuse or unauthorized access. Accordingly, understanding these dimensions provides important context for analyzing recurring vulnerability patterns and developer-related security challenges in modern web APIs.
3.3.1. RESTful APIs
RESTful APIs are based on the Representational State Transfer (REST) architectural style, which emphasizes stateless communication, resource-oriented interactions, and lightweight interoperability across distributed systems. RESTful services commonly operate over HTTP and HTTPS protocols and rely on standard methods such as GET, POST, PUT, and DELETE to retrieve, create, modify, or remove resources [
34]. Because of their simplicity, scalability, and compatibility with web technologies, RESTful APIs have become one of the most widely adopted architectural styles in modern web systems [
35].
Despite these advantages, RESTful APIs frequently introduce security challenges when secure development practices are inconsistently implemented. Since REST itself does not enforce built-in security controls, developers are responsible for correctly implementing authentication, authorization, input validation, session management, and secure communication mechanisms. In practice, weaknesses such as improper input sanitization, insecure token handling, and insufficient access-control validation can expose RESTful APIs to vulnerabilities, including injection attacks, broken authentication, and cross-site scripting [
34,
35]. Furthermore, publicly accessible endpoints and predictable request structures may increase exposure to automated probing, enumeration attempts, and abuse when rate limiting, monitoring, or logging mechanisms are insufficiently configured.
Recent studies emphasize that these weaknesses generally originate from implementation-level and configuration-level decisions rather than from the REST architectural style itself [
35]. In many cases, developers prioritize interoperability, rapid deployment, and usability while overlooking secure validation and access-control practices during implementation. Secure RESTful API development requires integrating security-oriented design principles early in the development lifecycle, including strong input validation, parameterized queries, secure token management, rate limiting, and continuous monitoring mechanisms.
3.3.2. SOAP APIs
The Simple Object Access Protocol (SOAP) is a protocol-driven web service standard used to exchange structured information through XML-based messaging [
36,
37]. Unlike REST, SOAP defines a stricter messaging structure and can support message-level security through standards such as WS-Security. This makes SOAP suitable for enterprise, financial, healthcare, and other environments that require formal message structure, reliability, and stronger security controls [
37].
However, SOAP’s XML-based design also introduces implementation and configuration challenges. Because SOAP services rely on XML parsing, schema validation, and message processing rules, insecure parser configurations or weak validation practices may expose systems to XML-related attacks, denial-of-service conditions, or unauthorized message manipulation. Prior studies note that cloud and enterprise APIs, including SOAP-based services, may be exposed to attacks such as eavesdropping, session hijacking, malicious code execution, XSS, and denial-of-service when authentication, encryption, and access-control mechanisms are poorly enforced [
36,
37]. These risks do not necessarily arise from the SOAP itself, but from inconsistent implementation, weak configuration, or overreliance on transport-layer protection alone.
Therefore, secure SOAP API development requires more than simply adopting the protocol. Developers must apply rigorous schema validation, harden XML parsers, enforce authentication and authorization policies, and consistently configure WS-Security mechanisms where appropriate. In this sense, SOAP illustrates how a security-supporting protocol can still become vulnerable when developer practices, configuration decisions, or operational controls are insufficiently managed.
3.3.3. GraphQL APIs
GraphQL is a query language and runtime for APIs that was introduced as an alternative to REST for applications requiring flexible and efficient data retrieval [
37]. Unlike RESTful APIs, which often expose multiple endpoints for different resources, GraphQL commonly relies on a single endpoint through which clients specify the exact data they need. This design can reduce over-fetching and under-fetching, but it also changes how security concerns appear in practice.
Because GraphQL allows clients to define the structure and depth of queries, insecure or insufficiently constrained implementations may expose systems to data overexposure, excessive query complexity, and denial-of-service risks through deeply nested or resource-intensive requests [
37]. Ali et al. [
34] similarly describe GraphQL as a flexible API model in which clients retrieve only the required data through a schema-driven query structure. This flexibility, however, places greater responsibility on developers to enforce schema validation, query restrictions, authorization checks, and access-control rules at the field and resolver levels.
Therefore, GraphQL security challenges are not inherent flaws in the query language itself but are often associated with implementation decisions and configuration practices. Secure GraphQL deployment requires limiting query depth and complexity, validating schemas and inputs, enforcing authorization consistently across fields and resolvers, and carefully controlling introspection and exposed schema information in production environments.
3.4. Usability of API
API usability represents one of the most important qualitative characteristics influencing how developers learn, adopt, and securely use APIs. A usable API reduces cognitive complexity, facilitates integration, and improves developer productivity and satisfaction [
19]. Unlike traditional graphical interfaces, APIs are primarily consumed through documentation, code examples, parameter structures, and interaction models, making developers themselves the direct users of the interface [
38]. As a consequence, poorly designed APIs may introduce not only usability difficulties but also security risks when developers misunderstand authentication flows, misuse sensitive functions, or incorrectly handle data validation and access-control logic.
Research increasingly emphasizes that API usability and security are closely interconnected rather than independent concerns. As Rauf et al. [
19] explain, APIs with poor learnability, inconsistent naming conventions, or unclear documentation increase developer confusion and integration errors. These usability problems often lead developers to adopt insecure workarounds, such as bypassing validation routines, hard-coding credentials, or misconfiguring authorization mechanisms. Similarly, McLellan et al. [
38] argue that programmers should be treated as users whose interaction patterns with APIs must be evaluated early in development to reduce misuse and implementation errors before public release.
Several studies further demonstrate that developers strongly associate API quality with ease of learning, consistency, documentation clarity, and the ability to quickly identify correct usage patterns [
39,
40,
41]. Henning [
40] notes that poorly designed APIs create friction throughout software development, increasing development effort and amplifying implementation mistakes across dependent systems. Likewise, Lauret [
41] emphasizes that APIs should be treated as products designed around developer experience rather than merely technical interfaces. This perspective has become increasingly important in large-scale distributed systems where APIs serve as long-term integration contracts across organizations and services.
The usability of APIs also directly affects adoption and long-term ecosystem sustainability, particularly in large-scale enterprise environments where APIs function as long-term integration assets [
42]. According to Rauf et al. [
43], novice developers frequently encounter obstacles related to unclear documentation, insufficient learning resources, confusing workflows, and difficulty understanding API behavior. These barriers negatively influence developer satisfaction and reduce continued API adoption. Inconsistent interface behavior and poor documentation can additionally increase the likelihood of insecure coding practices, particularly among inexperienced developers who depend heavily on tutorials and code examples when integrating APIs into applications.
A widely recognized example of API usability is the Google Maps API, which has been extensively adopted because of its consistent design, clear documentation, and ease of integration [
44]. Platforms such as Uber have leveraged these usability characteristics to build scalable real-time systems and location-based services [
45]. This example illustrates how well-designed APIs can accelerate development, encourage ecosystem growth, and reduce integration complexity. Conversely, APIs that lack coherent documentation, stable interaction models, or clear security guidance may increase the probability of developer misuse and vulnerability propagation across interconnected applications. Overall, API usability should not be viewed solely as a productivity or developer-experience concern. Instead, usability functions as a foundational factor influencing secure implementation practices, maintainability, adoption, and long-term operational resilience within modern software ecosystems.
3.5. Importance of API
Web APIs play an essential role in enabling communication and interoperability across modern software systems, cloud platforms, and distributed applications. By exposing reusable functionalities through standardized interfaces, APIs support modular development, code reuse, and service integration across heterogeneous systems [
46]. Their widespread adoption has also increased the exchange of sensitive data and expanded the overall attack surface of interconnected services [
47]. As a result, security challenges associated with API implementation, integration, and maintenance have become increasingly important in both academic research and industrial practice [
6].
3.6. Developer and Implementation Challenges in API Use
Despite their widespread adoption, APIs introduce several technical and organizational challenges related to design, usability, maintainability, and security. One major challenge involves designing APIs that satisfy diverse functional requirements while remaining intuitive and easy for developers to use. Modern APIs are frequently deployed across distributed cloud services, microservice architectures, mobile platforms, and IoT environments, which significantly increases architectural complexity and complicates consistent API management and integration practices.
Another significant challenge concerns API usability and developer experience. Murphy et al. [
48] observed that API designers often struggle to anticipate real-world developer use cases, particularly during the early stages of API development. The study further highlights that APIs are frequently difficult for programmers to learn and use because of factors such as unclear abstractions, insufficient documentation, inconsistent design decisions, and complex dependencies. These usability challenges may negatively affect developer productivity and can contribute to implementation mistakes, software bugs, and security-related problems during API integration and usage. In addition, maintaining long-term API consistency and backward compatibility remains difficult once APIs are publicly released. Changes to API structures, parameters, or behaviors may disrupt dependent applications and introduce operational instability. Murphy et al. [
48] also emphasize that API designers often face challenges obtaining meaningful user feedback and identifying which API features are most valuable to developers. As a result, organizations increasingly require structured API design guidelines, usability evaluation practices, and security-aware development processes to reduce implementation errors and improve the reliability of modern API ecosystems.
3.7. Summary
This section establishes the foundational context for understanding web APIs by examining their definitions, evolution, taxonomy, architectural styles, usability factors, and implementation challenges. The discussion showed that web API security is shaped not only by technical protocols such as REST, SOAP, and GraphQL, but also by developer practices, documentation quality, configuration decisions, usability limitations, and lifecycle management. This background provides the basis for the following section, which examines common web API security vulnerabilities and explains how recurring weaknesses often emerge from the interaction between architectural design, implementation choices, and human-related challenges.
4. API Security Vulnerabilities
Web APIs represent major attack surfaces in modern distributed systems because they frequently expose access to backend services, application logic, and sensitive data resources. Their rapid adoption across cloud platforms, microservices, and web applications has been accompanied by a substantial increase in reported security vulnerabilities, emphasizing the need for systematic analysis of existing threats and mitigation approaches [
49].
Several studies indicate that API vulnerabilities commonly originate from insecure implementation decisions such as improper input validation, weak authentication mechanisms, insecure authorization logic, and inconsistent security configurations. Sun et al. [
6] emphasize that malformed or unvalidated input data remains one of the most persistent causes of security breaches, particularly in environments where validation controls are inconsistently applied across services. Similarly, Qazi et al. [
37] observe that APIs frequently operate as intermediaries between clients and backend systems, thereby increasing their exposure to unauthorized access, data leakage, injection attacks, and logic-based exploitation. These findings suggest that many API vulnerabilities are not isolated technical flaws but manifestations of broader design and security-related implementation issues, especially when security considerations are not integrated during early development phases [
13].
Industry observations further reinforce the severity and growth of API-related threats in operational environments. According to Wallarm Research, API-specific vulnerabilities increased from 48 identified cases in Q1 2022 to 184 cases in Q2 2022, representing a 268% increase [
50]. Injection-related weaknesses and Broken Object Level Authorization (BOLA) were among the most frequently reported high-risk vulnerabilities. These findings demonstrate that attackers continue to exploit recurring development shortcomings rather than entirely new attack vectors, indicating persistent gaps in secure API development and deployment practices.
To systematically understand these risks, frameworks such as the OWASP API Security Top 10 [
12] provide structured classifications of critical API vulnerabilities based on prevalence, exploitability, and operational impact. The framework consistently identifies risks such as injection attacks, broken authentication, excessive data exposure, and insufficient access control as dominant categories affecting modern APIs. These classifications align closely with both empirical academic findings and industry security reports, reinforcing their practical relevance in contemporary API ecosystems.
However, a notable gap exists between academic research and operational industry observations. Academic studies often emphasize vulnerability identification and mitigation techniques, whereas industry reports focus more heavily on attack frequency, exploitation trends, and the operational consequences of insecure APIs. This divergence suggests that existing research does not always fully capture the evolving complexity of real-world API ecosystems or the practical challenges developers face when implementing security mechanisms in production environments.
In this context, this study provides a comparative synthesis that connects vulnerability categories, implementation weaknesses, detection approaches, and human-related factors. This review does not treat vulnerabilities solely as isolated technical defects. Instead, it examines how integration complexity, insecure development practices, configuration errors, and insufficient security integration contribute to the persistence of these vulnerabilities in real-world web API environments.
Building on this perspective, the following subsection examines the most common web API vulnerabilities reported in both academic research and industry practice, with particular emphasis on their technical causes, misuse patterns, and mitigation strategies.
4.1. Common Web API Security Vulnerabilities and Misuse Patterns
Security vulnerabilities in web APIs have evolved beyond isolated implementation flaws into recurring patterns that reflect deeper weaknesses in API design practices, developer behavior, and security configuration decisions. As APIs continue to increase in complexity, interoperability, and external exposure, they increasingly function as primary attack surfaces that enable adversaries to exploit systemic weaknesses rather than isolated coding errors [
13].
This subsection synthesizes findings from both academic research and industry reports to examine how common web API vulnerabilities emerge in practice. Rather than only categorizing vulnerability types, the analysis focuses on the technical conditions, implementation decisions, and recurring misuse patterns that contribute to these vulnerabilities. Particular attention is given to how developer practices, configuration errors, and architectural choices influence vulnerability exposure across different API styles.
To contextualize these relationships,
Table 3 summarizes major web API architectural styles, their commonly reported vulnerabilities, the developer or implementation practices associated with these weaknesses, and representative mitigation strategies discussed in the literature.
As shown in
Table 3, vulnerabilities across REST, SOAP, and GraphQL APIs are rarely caused by inherent flaws in the architectural styles themselves. Instead, the literature consistently associates these weaknesses with implementation-level decisions such as insufficient input validation, insecure parser configurations, unrestricted query execution, weak authorization enforcement, and improper token management. This observation supports the broader argument of this review that many recurring API security problems originate from interface-related issues, insecure development practices, and inconsistent security integration during API design and deployment.
4.1.1. SQL Injection and Cross-Site Scripting (XSS)
SQL Injection (SQLi) and Cross-Site Scripting (XSS) remain among the most persistent and extensively studied injection-based vulnerabilities in web APIs and web applications. Academic studies primarily describe these vulnerabilities as consequences of insufficient input validation, unsafe query construction, and improper output handling practices [
47,
51]. In particular, SQLi vulnerabilities commonly emerge when user-controlled input is directly incorporated into database queries, while XSS vulnerabilities often result from inadequate sanitization or encoding of dynamically rendered content. Existing studies consistently recommend mitigation techniques such as parameterized queries, contextual output encoding, and strict input sanitization as foundational defensive measures.
However, industry reports demonstrate that these vulnerabilities continue to persist at a large scale despite the maturity of existing mitigation strategies. For example, Akamai reported more than 11 billion web attack attempts, including approximately 6.2 billion SQL injection attacks and over one billion XSS-related attacks targeting modern applications and APIs [
47]. Similarly, Vaadata [
52] notes that APIs frequently expose injection points because validation controls are inconsistently implemented across dynamically exchanged requests and backend integrations.
This discrepancy between well-established defensive guidance and the continued prevalence of injection attacks suggests that the problem extends beyond purely technical weaknesses. Several studies associate the persistence of SQLi and XSS vulnerabilities with broader usability and development concerns, including insecure coding habits, insufficient security testing, inconsistent validation practices, and limited awareness of secure implementation requirements [
51]. These findings indicate that recurring injection vulnerabilities are not solely failures of API architectures themselves but are also consequences of usability, implementation, and development-process shortcomings that continue to affect real-world systems.
4.1.2. Broken Authentication
Broken authentication vulnerabilities represent a distinct category of API security weaknesses in which the primary challenge often extends beyond technical implementation flaws into the complexity and usability of authentication mechanisms themselves. Modern authentication frameworks such as OAuth 2.0 and OpenID Connect are widely adopted in distributed systems and microservice architectures; however, their correct implementation frequently requires developers to manage complex token flows, authorization logic, and inter-service trust relationships [
53]. As authentication mechanisms become increasingly decentralized across interconnected services, the difficulty of maintaining consistent and secure configurations also increases.
Empirical usability research further demonstrates that secure authentication frameworks may still introduce vulnerabilities when developers misuse or misunderstand security APIs. Wijayarathna et al. [
54] found that developers frequently struggle with authentication API complexity, unclear documentation, insufficient feedback mechanisms, and confusing implementation workflows. Their study showed that programmers often introduced insecure authentication behaviors despite using established authentication frameworks, not because the underlying protocols were inherently insecure, but because the APIs were difficult to use correctly. These findings challenge traditional assumptions that authentication vulnerabilities originate primarily from protocol weaknesses alone.
Unlike injection vulnerabilities, which are commonly mitigated through validation and sanitization mechanisms, broken authentication vulnerabilities are strongly influenced by human and usability factors. Improving authentication security requires stronger protocols and clearer API documentation, secure-by-default configurations, simplified implementation workflows, and developer-oriented guidance that reduces the likelihood of misuse during integration and deployment.
4.1.3. Denial-of-Service (DoS)
Denial-of-Service (DoS) vulnerabilities in modern web APIs increasingly differ from traditional network-level flooding attacks, as many attacks now exploit weaknesses in application-layer processing and API logic rather than relying solely on high-volume traffic generation. Academic studies indicate that insufficient input constraints, inefficient request processing, recursive query structures, and unbounded resource consumption can trigger resource exhaustion even under relatively moderate traffic conditions [
55]. In API-driven environments, these weaknesses are particularly significant because a single malicious request may consume disproportionate computational or database resources.
Industry observations further demonstrate the growing operational impact of API-focused DoS attacks. Reports from Infosecurity Magazine [
56] indicate that millions of distributed denial-of-service incidents were recorded during 2021, with a growing number specifically targeting API endpoints and cloud-connected services. This trend reflects the increasing exposure of APIs as externally accessible integration points within distributed systems and microservice environments.
These findings suggest that DoS vulnerabilities are shaped by both technical and implementation-related factors. While research primarily focuses on identifying architectural and processing weaknesses that enable resource exhaustion, industry evidence highlights how attackers systematically exploit these weaknesses at scale. Effective mitigation requires a layered approach that combines secure API design practices, such as request complexity limits and bounded resource allocation, with operational protections including rate limiting, traffic monitoring, anomaly detection, and API gateway enforcement mechanisms. These observations further reinforce that API security cannot be treated as an isolated protocol concern but instead requires coordinated design, implementation, and operational defenses across multiple system layers.
4.1.4. Cross-Site Request Forgery (CSRF)
Cross-Site Request Forgery (CSRF) represents a distinct class of web vulnerabilities that exploit implicit trust relationships within web architectures rather than directly compromising authentication credentials or injecting malicious input [
57]. In CSRF attacks, authenticated browsers automatically include session credentials, such as cookies or tokens, when processing malicious cross-origin requests, enabling attackers to perform unintended actions on behalf of legitimate users [
57,
58]. Unlike injection-based vulnerabilities, CSRF attacks abuse the assumptions underlying trusted sessions and browser behavior, making them particularly dependent on architectural design decisions and session management practices.
Prior studies emphasize that CSRF vulnerabilities persist due to a combination of technical weaknesses and developer-side implementation challenges. Research highlights that insufficient request-origin validation, weak session handling, and inconsistent deployment of anti-CSRF protections remain common causes of exposure [
57,
59]. At the same time, empirical analyses demonstrate that many frameworks either require developers to explicitly enable CSRF defenses or provide incomplete guidance regarding their secure configuration, increasing the likelihood of insecure deployments [
59]. These findings reinforce that the persistence of CSRF vulnerabilities is influenced not only by technical limitations but also by usability, documentation quality, and developer awareness.
The literature further indicates that CSRF vulnerabilities present significant detection challenges compared with injection-oriented attacks. Unlike SQL injection or XSS, which often exhibit identifiable payload patterns, CSRF attacks are highly dependent on application logic, authenticated session context, and state-changing operations [
60,
61]. Thus, conventional vulnerability scanners frequently struggle to identify CSRF weaknesses reliably, motivating the development of more advanced detection approaches such as dynamic analysis frameworks and web API-level protection mechanisms [
58,
61].
Effective mitigation therefore requires architectural and operational protections rather than isolated input validation techniques alone. Common mitigation strategies include anti-CSRF token mechanisms, SameSite cookie policies, origin and referrer validation, and secure session management practices [
59]. These observations demonstrate that CSRF vulnerabilities reflect broader challenges involving framework design, developer guidance, and operational security practices across modern web API ecosystems.
The common web API security vulnerabilities and their representative mitigation are summarized in
Table 4.
Table 4 highlights that the reviewed vulnerabilities differ not only in their technical attack mechanisms but also in the implementation and operational conditions that enable their exploitation. Injection-oriented vulnerabilities such as SQLi and XSS remain strongly associated with insufficient validation practices, whereas authentication and CSRF-related weaknesses are more closely connected to configuration complexity, session management, and developer misuse patterns. The table further illustrates that effective mitigation strategies increasingly require coordinated security practices spanning implementation, usability, and operational controls rather than isolated defensive mechanisms alone.
According to the reviewed studies and industry reports summarized in
Figure 4, injection-oriented vulnerabilities, particularly SQL injection and XSS, remain among the most persistent and rapidly increasing categories of web API security threats. The observed growth trends indicate that the continued prevalence of these vulnerabilities cannot be explained solely by the absence of mitigation techniques, since defensive mechanisms such as parameterized queries, output encoding, and input sanitization have been well established for many years. Instead, the findings across the literature increasingly associate this persistence with inconsistent implementation practices, insecure defaults, insufficient validation enforcement, and developer-side integration challenges.
Authentication and session-management vulnerabilities exhibit a similar pattern. Although modern authentication frameworks provide robust security capabilities, their secure deployment frequently depends on correct configuration, appropriate token management, and developer understanding of complex authentication workflows. This demonstrates that many web API vulnerabilities emerge through the interaction between technical mechanisms, implementation practices, and usability-related challenges rather than through protocol weaknesses alone.
The findings reveal an important research gap in the current web API security literature. The approaches often analyze vulnerabilities as isolated technical problems without sufficiently addressing the relationships among architectural complexity, developer behavior, usability challenges, and operational deployment practices. Hence, improving web API security requires more integrative approaches that combine vulnerability detection, secure-by-design development practices, usability-aware security mechanisms, and real-world operational analysis.
To further examine how existing research addresses these challenges,
Table 5 presents a comparative synthesis of the major vulnerability detection and analysis approaches discussed in the literature. The comparison highlights substantial differences in scalability, interpretability, deployment complexity, and detection effectiveness across static, dynamic, hybrid, machine learning-based, and industry-driven approaches.
In particular, static and rule-based techniques generally prioritize scalability and ease of deployment but frequently suffer from high false-positive rates and limited contextual awareness. Dynamic and hybrid approaches improve runtime visibility and detection accuracy, although they introduce higher operational complexity and increased computational cost. Machine learning-based techniques provide adaptability against evolving attack patterns but remain constrained by explainability, dataset quality, and deployment challenges. Together, these limitations demonstrate that no single detection strategy fully addresses the complexity of modern web API security, reinforcing the need for integrated and developer-aware security frameworks.
5. Discussions and Comparative Analysis
The reviewed literature indicates that recurring web API security vulnerabilities emerge through the interaction between technical implementation issues, developer practices, usability limitations, and the operational complexity of modern distributed systems. However, the strength and type of evidence vary across the reviewed studies. For example, empirical usability work on authentication APIs links developer mistakes to API complexity and usability barriers through direct programmer observation and think-aloud evaluation [
54], whereas broader cloud API security studies emphasize organizational exposure, insecure configurations, and limited security awareness from a higher-level security management perspective [
37]. Although these studies differ in method and scope, they converge on the view that established mitigations for injection attacks, authentication failures, and denial-of-service conditions are often weakened by practical implementation and integration challenges.
The usability-related evidence also varies in methodological strength. Earlier API usability work provides design-oriented and practitioner-focused arguments that programmers should be treated as API users and that documentation, naming, and interface consistency affect correct API use [
38]. In contrast, later systematic mapping work provides broader evidence that API usability evaluation methods remain fragmented across goals, development phases, and usability factors [
19]. Technical surveys of API property inference further show that automated techniques can infer usage rules and behavioral patterns, but these approaches often differ in the properties inferred, input data, and evaluation methods [
18]. Taken together, these studies support the relationship between usability and security, but they also show that the evidence is distributed across empirical studies, systematic mappings, and technical surveys rather than a single unified evaluation model.
Another recurring challenge concerns the limitations of existing vulnerability detection and analysis techniques. Although static, dynamic, hybrid, and machine learning-based approaches continue to evolve, the reviewed studies indicate substantial methodological variation in how these techniques evaluate web API-related vulnerabilities. Rule-based and static analysis approaches often provide scalability and automation advantages, but they frequently struggle with contextual understanding, distributed API interactions, and logic-driven vulnerabilities. In contrast, machine learning and behavior-oriented approaches may improve contextual interpretation, yet they commonly depend on large training datasets, environment-specific tuning, or limited experimental settings [
51].
The reviewed literature also reports inconsistent findings regarding precision, interpretability, and developer trust in automated security warnings. Some studies emphasize the effectiveness of automated detection for identifying recurring vulnerability patterns, while others highlight persistent limitations related to false positives, alert fatigue, insufficient explainability, and reduced practitioner confidence in security tooling [
26]. These differences partly reflect variation in evaluation environments, datasets, architectural assumptions, and measurement criteria across the reviewed studies. Consequently, improving web API security requires not only stronger detection algorithms but also more consistent empirical validation strategies that integrate usability, explainability, contextual awareness, and operational practicality into security evaluation processes.
These broader observations are reinforced by the comparative analysis of detection approaches presented in
Table 5, which demonstrates that existing techniques vary substantially in their scalability, contextual awareness, interpretability, and deployment complexity. The reviewed approaches indicate that no single detection strategy currently addresses the full spectrum of modern web API security challenges.
Another issue concerns the evolution of APIs and their implications for backward compatibility. As APIs mature, changes in endpoints, request structures, or authentication flows can inadvertently break client applications or expose previously unexploited security gaps. However, the reviewed literature approaches API evolution from different methodological and analytical perspectives. Large-scale systematic reviews primarily emphasize research trends, versioning practices, and evolution challenges across software ecosystems [
2], while earlier migration and software evolution studies focus more heavily on compatibility management, refactoring complexity, and the practical consequences of breaking changes in long-term software maintenance [
26]. Other studies further highlight that the pressure to maintain functionality, scalability, and rapid deployment frequently competes with secure implementation priorities, particularly in fast-evolving API ecosystems [
20].
Despite these differences in scope and methodology, the reviewed studies consistently indicate that API evolution remains insufficiently explored from a security-focused perspective. Existing research more commonly evaluates maintainability, compatibility, or software evolution concerns than the direct security implications of deprecated endpoints, inconsistent versioning strategies, or insecure migration practices. This imbalance suggests that the security consequences of API evolution are often treated as secondary concerns relative to functionality and deployment efficiency. As a result, the literature reveals a continuing tension between innovation velocity, backward compatibility, and long-term security resilience in modern API ecosystems.
Although the reviewed literature provides broad taxonomies of API types, vulnerabilities, and usage patterns, the evidence across studies remains methodologically fragmented. The reviewed work varies substantially in research scope, evaluation environments, empirical depth, and analytical focus. Some studies rely on controlled usability experiments or practitioner observations, whereas others emphasize conceptual analysis, systematic mappings, architectural reviews, or vulnerability categorization frameworks. Consequently, direct comparison across studies remains difficult, particularly when evaluating the relative impact of developer practices, usability constraints, architectural complexity, and security tooling on recurring API vulnerabilities.
The reviewed studies nevertheless suggest that these dimensions are closely interconnected within modern API ecosystems. However, the strength of evidence supporting developer-related and usability-related security conclusions remains uneven across the literature, with some findings supported primarily through qualitative or observational analysis rather than large-scale empirical validation. This fragmentation highlights the need for more integrative and empirically grounded approaches capable of connecting technical vulnerabilities with implementation practices, usability constraints, and operational deployment challenges across diverse API environments.
The main findings and recurring challenges discussed above are consolidated in
Table 6, which outlines the primary issues and their proposed solutions based on the reviewed studies.
Table 6 demonstrates that many recurring web API security challenges emerge through the interaction between technical vulnerabilities, developer practices, usability limitations, and evolving architectural complexity. The studies suggest that effective mitigation requires technical countermeasures and developer-oriented guidance, secure-by-default design strategies, usability-aware tooling, and stronger integration of security considerations throughout the web API development lifecycle.
Integrative Conceptual Perspective for Web API Security
Based on the vulnerabilities and behavioral factors identified in
Section 4, this study synthesizes the reviewed findings into an integrative conceptual perspective that highlights the relationships among developer practices, web API usability, and security tool effectiveness.
Table 7 organizes the supporting evidence into three analytical dimensions, while
Figure 5 visually illustrates how these dimensions interact to influence recurring web API vulnerabilities.
Figure 5 complements
Table 7 by showing the directional relationships among the three dimensions. Developer behavior shapes implementation decisions, web API usability influences how securely developers configure and integrate APIs, and security tool effectiveness affects the detection and mitigation of continuing API security issues.
This study organizes the reviewed findings into an integrative conceptual perspective for understanding recurring web API security challenges. The proposed perspective synthesizes recurring patterns identified across the reviewed studies into three interacting dimensions: developer behavior, web API usability, and security tool effectiveness. At its core, this perspective synthesizes recurring relationships reported across the reviewed literature, particularly those associated with developer awareness, implementation practices, usability challenges, and security tool effectiveness in web API environments.
Table 7 highlights how recurring web API security weaknesses emerge through the interaction between developer practices, integration complexity, and the effectiveness of existing security tools. Across the reviewed literature, vulnerabilities are rarely attributed solely to architectural flaws in APIs themselves. Instead, the findings consistently associate insecure outcomes with implementation complexity, inconsistent developer guidance, configuration challenges, and limitations in current detection approaches.
The reviewed studies further indicate that usability and security are closely interconnected within modern web API ecosystems. Ambiguous documentation, inconsistent interface behavior, and insufficient implementation feedback can increase the likelihood of insecure API integration, while limitations in existing analysis tools, including false positives and limited contextual awareness, reduce their practical effectiveness in real-world development environments.
This integrative conceptual perspective provides a broader interpretation of why web API vulnerabilities continue to persist despite the availability of established mitigation techniques. The findings suggest that improving API security requires not only technical countermeasures but also stronger alignment between secure development practices, usability-aware API design, and developer-centered security evaluation approaches.
Across the reviewed studies, an important pattern emerged regarding the relationship between technical vulnerabilities and developer-oriented factors. Studies focusing primarily on vulnerability detection often emphasized implementation flaws and validation failures, whereas usability-oriented studies highlighted documentation quality, API complexity, and developer workflow challenges as contributing factors. This contrast suggests that recurring API security weaknesses cannot be fully explained through technical analysis alone but instead emerge from the interaction between architectural complexity, security integration practices, and human-centered development constraints.