intro
SQL injection is one of the most dangerous attacks targeting applications. This SQL injection cheat sheet will walk you through what it is, how it works, and what you can do to protect against it.
All developers are aware of security flaws targeting their applications; security engineers will also be aware of the existence of the OWASP Top 10 listing, too. OWASP says that the 2025 edition of the OWASP security flaws should be released in the first half of 2025, as they’re collecting data around security issues and flaws in web applications. We’ll see a refreshed edition of OWASP in 2025, but we’re almost certain that injection will remain a part of the list. Explore this SQL injection cheat sheet!
Injection and Its Characteristics in the OWASP List
Injection was a part of the OWASP list in 2007, 2010, 2017, and 2021. We’re certain that in 2025, injection will remain a part of the list. The reason why we’re saying that is because injection has three key characteristics:
It’s also worth keeping in mind that injection attacks don’t exclusively refer to SQL injection — what it does refer to is any web-based attack where a user injecting malicious input to harm an application is the culprit. For web applications, it just so happens that most of such situations have something to do with SQL injection, hence the connotation.
Now, keep on reading this SQL injection cheat sheet to find out how that’s done!
How Does SQL Injection Work?
SQL injection is very easy to come across because it’s very simple to write queries that provide user input to the database without verifying the input at hand. This concept is what makes SQL injection possible — if it weren’t for such a concept, this SQL injection cheat sheet wouldn’t exist. What a weird world we live in, huh?
Injecting SQL works in the following way:
The weak link here is the second step: an application becomes susceptible to SQL injection once user input is passed directly onto a database. That’s because a malicious payload (a malicious query crafted by an attacker) can extract data from the database or even manipulate some data.
Types of Queries and SQL Injection
Before we jump into the specifics, we’ll walk you through the types of queries working inside of your database. There are four types of queries that can interact with your database:
SQL injection is equally dangerous regardless of what query it is based on!
Just as multiple types of queries can be susceptible to SQL injection, there are multiple different types of SQL injection as well: there is classic SQL injection, error-based SQL injection, union-based SQL injection, blind SQL injection, and out-of-band SQL injection.
The type of SQL injection an application will be susceptible to depends on how the queries, the application, the database, and the server work in conjunction. We won’t get into all of the nitty-gritty details in this SQL injection cheat sheet, but regardless, you can prevent SQL injection using simple methods that apply to all of the types at once.
Preventing SQL Injection
It’s a well-known fact that SQL injection can be prevented by separating user input from the query.
Prepared statements, or PDO, work by sending the query and the data to the database separately, thus preventing user input from being provided straight to the database, and avoiding SQL injection as a result.
For example, this query would not be susceptible to SQL injection:
The above example would be a SQL injection cheat sheet example of a PDO-based query.
A good SQL injection cheat sheet should also tell you that prepared statements won’t always protect you from injection either — if you use prepared statements or PDO but still provide user input straight into a database, the end result will still be the same. Here’s an example:
Even though the user ID is a value of NULL (NULL values increment automatically on a field that has the AUTO_INCREMENT value), the application would be susceptible to SQL injection because the username and the user email would still be provided by the user. The IP address is another discussion because the REMOTE_ADDR value can be easily spoofed and so you would need to look into the HTTP_FORWARDED_FOR value too, but we’re not getting into that here.
A common misconception is that only SELECT queries are a target for SQL injection because of attackers searching for a malicious payload (and thus gaining access to the database) — this SQL injection cheat sheet tells you that it’s not the case!
INSERT queries are susceptible to SQL injection the same way as all other types of queries dependent on user input would: an attacker could simply nullify the rest of the query using -- (a comment sign) and act on data.
Granted, a DELETE query won’t grant the attacker the ability to select usernames and passwords from the database (data would be deleted instead), but nonetheless, the defined action would be taken by the database.
Preventing Other Security Flaws
Preventing SQL injection by using parameterized statements is only half the battle — you shouldn’t rely solely on them for your security strategy. Attackers are searching for and exploiting other security flaws present in your application, too — XSS (Cross-Site Scripting), CSRF (Cross-Site Request Forgery), DoS (Denial of Service), and DDoS (Distributed Denial of Service) attacks are all you need to brace yourself for.
All this means that your application needs a proper security strategy — grab a WAF (Web Application Firewall), harden the security of your server (follow a backup plan, patch vulnerabilities, protect user accounts, and perform other actions), set up a CDN for DDoS protection (CloudFlare or Imperva distributes the traffic coming onto your application by distributing it across multiple servers to lessen the load coming onto the server that hosts your application), and follow other steps outlined in the OWASP Top 10 or other security guidelines.
Consider connecting to your database using an SSH client, make use of privileges and permissions in SQL clients to prevent potentially dangerous queries from being executed in the first place, and you will be on your way.
These steps should give you a good head start in securing your application from SQL injection and related attack vectors, but lastly, you shouldn’t forget that the weakest link in the chain is often a human.
Use strong passwords for every online account (password managers do a great job of doing that for you), make use of data breach search engines like BreachDirectory to scan your online accounts through hundreds of publicly available data breaches, and change your passwords if you’re found to be in danger, and use a VPN when connected to publicly accessible networks for your safety.
Follow these basic tips, and even the most sophisticated SQL injection attacks won’t be that scary anymore.
Summary
This SQL injection cheat sheet has provided you with the types of SQL injection that you may encounter and discussed ways to prevent SQL injection from harming your most precious data. Regardless, keep in mind that SQL injection is only the tip of the iceberg when it comes to security — keep yourself informed on ways to protect your application and your database from other attacks like Cross-Site Request Forgery and Cross-Site Scripting, make use of data breach search engines like BreachDirectory to protect your most precious assets on the web, and until next time.
FAQ
What is SQL injection and how does it work?
SQL injection is a type of injection attack outlined in the OWASP Top 10 and other venues that choose your database as its primary victim. An application is susceptible to an injection attack if it provides user input straight into a query and doesn’t sanitize it.
How can I protect my application from SQL injection?
Protect your application from SQL injection by separating user input from the database query. That can be easily done using prepared statements.
What else can I do to protect my application, database, and server?
To further protect your application, database, and the server they run on, consider educating yourself on the rest of the security flaws outlined in the OWASP Top 10 list as well as making use of CDNs to prevent DDoS attacks, not providing information to the users of your application through errors, and use other measures.
How would the BreachDirectory API help the security of my database or application?
Consider using the BreachDirectory API to assist with the security measures of your application and other infrastructure by implementing publicly available data breach data into the lifecycle of your security plan.
By doing so, you will be the first one that get informed once the data from a certain application gets leaked on the web and will be enabled to take preventative action to protect your clients, customer base, employees, and users of your application at the same time.
Implement the BreachDirectory API into your application and protect your customers today! If you want to know whether you’re exposed to a data breach, consider using the search engine instead.
