# What Is SQL Injection (SQLi)? Types, Real Attack Scenarios and Prevention Methods

**URL:** https://securesys.com.tr/en/learning/web-application-security/what-is-sql-injection-types-prevention

### What Is SQL Injection (SQLi)?

![What is SQL Injection (SQLi)? Union, Error, Boolean and Time based types](/images/bilgi-merkezi/covers/cover-sql-injection.webp)

SQL Injection (SQLi) is a web application security vulnerability that lets an attacker manipulate the queries an application sends to its database by injecting their own malicious SQL commands. It occurs when the application inserts user-supplied data (a form field, URL parameter, HTTP header, etc.) directly into a SQL query without adequate validation or without using parameterised queries.

Although SQL Injection has been on the [OWASP Top 10](/en/services/web-application-security-test-service) list for years, it remains one of the most common and most damaging vulnerabilities. A successful SQL Injection attack can lead to reading the entire database, modifying or deleting data, bypassing authentication mechanisms and, in some cases, executing commands on the server.

### Types of SQL Injection

SQL Injection is not a single technique but a family of vulnerabilities that manifest differently across scenarios:

- **Error-Based SQL Injection** — Database error messages are returned directly to the user, allowing the attacker to gather information about the database structure from the error output.
- **Union-Based SQL Injection** — The SQL `UNION` operator is used to append additional data rows chosen by the attacker to the result of the original query.
- **Boolean-Based Blind SQL Injection** — Even when the application returns no error message, data can be extracted from differences in the page's true/false behaviour.
- **Time-Based Blind SQL Injection** — Data is inferred by exploiting delays in the application's response time (e.g. `SLEEP()` commands).
- **Out-of-Band SQL Injection** — The result is delivered to the attacker over an alternative channel such as HTTP or DNS requests; generally used when other methods are not possible.

### A Real-World Scenario

During a penetration test of an e-commerce platform's product filtering feature, it was found that the price-range parameter was inserted directly into the SQL query without server-side validation. The test team manipulated this parameter, observed the change in the number of rows returned by the filtering query, and confirmed using a boolean-based blind technique that the database name, table structure and ultimately the hashed credentials of administrator accounts could be accessed.

The finding was verified in a controlled, read-only manner without altering any data on the live system, then reported to the organisation with a detailed technical report and prioritised remediation recommendations.

### Prevention Methods

- **Parameterised queries (prepared statements)** — user input must never be concatenated directly into a SQL string.
- **Correct configuration of ORM layers** — using an ORM alone is no guarantee of security; raw query usage must be reviewed carefully.
- **Principle of least privilege** — the application's database user should only be authorised for the operations it actually needs.
- **Input validation and a whitelist approach** — the expected data type and format must be strictly checked on the server side.
- **Detailed error messages must not be shown to end users** — database error output should be logged and a generic error returned to the user.
- **[Web Application Firewall](/en/services/waf-solutions-api-security) (WAF)** — as an additional defensive layer it can block known attack signatures, but is not sufficient on its own.

### Potential Outcome and Business Impact

| Potential Outcome | Business Impact |
| --- | --- |
| Full read access to the customer database | KVKK/GDPR breach, mass data leak |
| Bypassing the authentication mechanism | Unauthorised administrator access |
| Modification of database records | Financial and operational damage |
| Command execution on the database server (in some scenarios) | Complete compromise of the infrastructure |

### SecureSys SQL Injection Testing Approach

SecureSys experts identify context-specific SQL Injection scenarios that automated scanners miss, through manual analysis. Our tests cover the systematic scanning of all entry points (forms, URL parameters, HTTP headers, API endpoints), safe and controlled verification of blind/time-based techniques, evaluation of database access privileges, and reporting of findings prioritised by business impact. See our [penetration testing methodology](/en/learning/web-application-security/web-application-penetration-testing-methodology) page for details on our approach.

To have your web application tested against SQL Injection and other OWASP Top 10 risks, reach out via our [Web Application Penetration Testing Service](/en/services/web-application-security-test-service) page.