For all the attention given to advanced threats and AI-driven attacks, many successful breaches still rely on techniques that have been around for decades.
SQL injection has been studied and discussed for more than 20 years, yet more than 20% of organizations are still vulnerable when first assessed, and the technique continues to account for a meaningful share of modern vulnerabilities.
VP of Product at Wallarm.
Cross-site scripting (XSS) is another long-standing example. It allows attackers to inject malicious scripts into web applications, enabling data theft, session hijacking, and unauthorized actions on behalf of legitimate users.
The technique has persisted since the late 1990s and continues to appear in modern applications, including those built on frameworks that claim to mitigate it by default.
If the industry has spent so much time addressing decades-old attacks, why do they still succeed? The answer has less to do with awareness and more to do with how modern technology environments are built and maintained.
Technology doesn’t replace itself
Technology does not replace itself in clean cycles. New systems layer on top of existing ones, and older code remains in place because it continues to support business operations. Over time, this produces environments that are more complex and harder to fully secure.
Organizations continue to build APIs, adopt microservices, and integrate AI tools into their systems. These changes support growth and improve functionality, but they also increase exposure.
Each new layer introduces additional connections, dependencies, and potential points of failure. Older vulnerabilities are rarely removed in the process. They are inherited.
That is why long-standing attack techniques remain effective. Attackers do not need sophisticated methods when simpler ones still work.
Gaps in ownership create real risk
There is also a disconnect between how security responsibilities are perceived and how they are executed. Developers expect security controls to catch issues later in the pipeline. Security teams assume secure coding practices are already in place. Both assumptions create gaps.
APIs illustrate the problem clearly. Some are developed internally, others integrated from third parties. Application security teams focus on internally developed assets, while vulnerability management teams often treat APIs as outside their scope.
The result is that some APIs are never fully assessed or consistently monitored, and known vulnerability classes persist in them long after the industry considers those classes solved.
The AI attack surface is mostly old problems in new packaging
Most of the conversation about AI security focuses on model-specific risks: prompt injection, jailbreaks, training data poisoning, and model theft. Those risks are real and worth addressing. They are also a small portion of the actual attack surface that an AI deployment introduces.
A production AI system is a distributed application.
It includes inference APIs that accept user input and return model output, retrieval pipelines that pull from vector databases and traditional data stores, agent frameworks that call external tools and services, identity and authorization layers that gate access to capabilities, and a supply chain of models, libraries, and datasets sourced from third parties.
Each of these components is built from architectural patterns that predate generative AI by years or decades.
That means the AI attack surface exposes the same vulnerability classes practitioners have been fighting all along. Inference endpoints are APIs, and they inherit the same authentication, authorization, rate limiting, and input validation problems that the rest of the API ecosystem has.
Retrieval-augmented generation pipelines query databases, which means SQL injection and access control failures still apply. Agent tools execute requests against internal and external systems, which reintroduces server-side request forgery and command injection in new contexts.
Supply chain risk in model registries and dependency packages mirrors the risk in any other software supply chain.
Teams that focus exclusively on novel AI-specific threats leave the larger and more familiar surface unprotected. An attacker does not need to craft a clever prompt injection if the inference API has broken object-level authorization or a misconfigured CORS policy. The path of least resistance still runs through the basics.
This is also where the pace problem compounds. AI features ship under aggressive timelines, and the API surface expands faster than security teams can assess it. Each new endpoint inherits the organization’s existing API security posture, including whatever gaps already exist.
Security is a business decision
Setting security priorities requires translating technical vulnerabilities into business impact. A SQL injection finding is widely understood as a class, but its significance depends on what data it exposes and how it can be reached. Without that context, prioritization defaults to whatever is loudest, which is usually whatever is newest.
That is how organizations end up overestimating their protection against basic threats. They have tools that address known vulnerabilities at the perimeter or in code review, but coverage breaks down at the edges, particularly in APIs and AI components that do not map cleanly to traditional application security models.
Old risks don’t go away
Fixing this does not require new approaches. Established security practices still work. The difficulty is applying them consistently across an environment that keeps growing and reshaping itself, and ensuring that older vulnerability classes are not deprioritized when new technologies are introduced.
Three actions matter most. Define ownership for every API and AI component, internal or third-party, so no asset falls between teams. Test AI deployments using existing application and API security disciplines before adding AI-specific tooling on top.
And measure exposure based on what is reachable and exploitable, not on whether a vulnerability class is considered new or old.
The continued success of decades-old attacks is not a knowledge gap. It is a prioritization gap. Security teams that balance attention between novel threats and unresolved fundamentals will reduce exposure more effectively than those chasing whichever risk is currently in the headlines.
We've featured the best endpoint protection software.
This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.
The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit