SQL injection is one of the most common and dangerous web application security vulnerabilities. It occurs when an attacker manipulates application input to change the SQL query executed by a database.

For Laravel developers, understanding how Laravel protects against SQL injection is important when building secure APIs, dashboards, authentication systems, e-commerce platforms, and other database-driven applications.

Laravel provides several mechanisms that help prevent SQL injection, particularly through Eloquent ORM, the Query Builder, and parameter binding.

However, Laravel cannot automatically protect every query if developers intentionally construct unsafe raw SQL.

In this guide, we’ll explain how Laravel prevents SQL injection, how parameter binding works, which Laravel query methods are safe, common mistakes to avoid, and best practices for writing secure database queries.

---

What Is SQL Injection?

SQL injection happens when untrusted user input is inserted directly into an SQL query.

Consider a login query that is built like this:

$email = $request->email;

$query = "SELECT * FROM users
          WHERE email = '$email'";

If the application directly inserts user-controlled input into the SQL statement, an attacker may manipulate the query.

The problem can be visualized as:

User Input
    ↓
Application
    ↓
String Concatenation
    ↓
SQL Query
    ↓
Database

The application is treating data as part of the SQL command.

That is the fundamental problem SQL injection attacks exploit.

---

How Laravel Protects Against SQL Injection

Laravel helps prevent SQL injection primarily by using parameterized queries and parameter binding.

When you use Eloquent or Laravel’s Query Builder correctly, user-provided values are generally sent separately from the SQL statement.

Instead of creating one large SQL string:

SQL + User Input

Laravel uses a structure conceptually similar to:

SQL Statement
     +
Parameters
     ↓
Database

This means the database can distinguish between:

• SQL instructions
• User-provided data

The basic protection flow looks like this:

User Input
     ↓
Laravel Query Builder / Eloquent
     ↓
Parameterized Query
     ↓
Parameter Binding
     ↓
Database
     ↓
Safe Query Execution

This is one of the most important reasons Laravel applications can be protected against SQL injection when its database APIs are used correctly.

---

What Is Parameter Binding?

Parameter binding means values are supplied separately from the SQL statement instead of being concatenated directly into it.

For example:

DB::select(
    'SELECT * FROM users WHERE email = ?',
    [$email]
);

Here:

SELECT * FROM users WHERE email = ?

is the SQL statement.

And:

[$email]

contains the value that should be bound to the placeholder.

The important concept is:

SQL structure ≠ User data

This prevents user input from being interpreted as SQL syntax.

---

Laravel Eloquent and SQL Injection Protection

Eloquent is Laravel’s ORM and is one of the most common ways developers interact with databases.

For example:

$user = User::where(
    'email',
    $request->email
)->first();

You don’t manually construct the SQL query.

Conceptually, Laravel generates a parameterized query similar to:

SELECT *
FROM users
WHERE email = ?
LIMIT 1

The email value is supplied separately.

This makes normal Eloquent queries significantly safer than manually concatenating SQL strings.

---

Example: Safe Eloquent Query

Consider a product search:

$products = Product::where(
    'name',
    'like',
    '%' . $request->search . '%'
)->get();

The search value is treated as a parameter rather than directly becoming part of the SQL command.

This is preferable to constructing SQL manually.

---

Unsafe SQL Query Example

A developer might write:

$search = $request->search;

$products = DB::select(
    "SELECT * FROM products
     WHERE name LIKE '%$search%'"
);

The problem is the input is directly concatenated into the SQL string.

The application is effectively creating:

SQL Query + Untrusted Input

This is exactly the pattern developers should avoid.

---

Safe Alternative With Parameter Binding

Instead, use:

$search = $request->search;

$products = DB::select(
    'SELECT * FROM products
     WHERE name LIKE ?',
    ["%{$search}%"]
);

Now the SQL structure remains separate from the value.

A better option for many applications is to use Eloquent or the Query Builder:

$products = Product::where(
    'name',
    'like',
    "%{$search}%"
)->get();

---

Laravel Query Builder and SQL Injection

Laravel’s Query Builder also uses parameter binding for normal query values.

For example:

$users = DB::table('users')
    ->where('email', $email)
    ->get();

This is safer than manually constructing SQL.

Another example:

$orders = DB::table('orders')
    ->where('status', $status)
    ->where('user_id', $userId)
    ->get();

Laravel handles the values as query parameters.

---

Eloquent vs Query Builder vs Raw SQL

Here is a simplified comparison:

Approach	SQL Injection Risk	Recommended
Eloquent where()	Low when used correctly	Yes
Query Builder where()	Low when used correctly	Yes
Parameterized DB::select()	Low when used correctly	Yes
whereRaw() with bindings	Low when used correctly	Yes
DB::raw() with user input	High if misused	Avoid direct input
SQL string concatenation	High	Avoid
User input inside raw SQL	High	Avoid

The key point is that Laravel’s protection depends on how you write the query.

---

How Parameter Binding Works

Consider this:

$email = $request->email;

DB::select(
    'SELECT * FROM users WHERE email = ?',
    [$email]
);

Conceptually:

SQL:
SELECT * FROM users WHERE email = ?

Parameter:
john@example.com

The database receives the SQL structure and the parameter separately.

Even if the parameter contains characters that resemble SQL syntax, it remains data rather than becoming part of the SQL command.

---

Named Parameter Bindings

Laravel also supports named bindings in raw queries.

For example:

$users = DB::select(
    'SELECT * FROM users
     WHERE email = :email',
    [
        'email' => $email,
    ]
);

This can make more complex raw queries easier to read.

---

Using whereRaw() Safely

Laravel provides methods such as:

whereRaw()

These are useful when a normal Query Builder expression isn’t enough.

For example:

$users = User::whereRaw(
    'email = ?',
    [$email]
)->get();

The important part is the parameter binding:

[$email]

Avoid this:

User::whereRaw(
    "email = '$email'"
)->get();

The second version directly inserts user input into SQL and can introduce SQL injection risk.

---

Using DB::raw() Carefully

DB::raw() allows developers to insert raw SQL expressions.

For example:

$users = User::select([
    'id',
    'name',
    DB::raw('COUNT(*) as total')
])->groupBy('id', 'name')->get();

This can be useful for database expressions.

However, DB::raw() should not be treated as a security mechanism.

It essentially tells Laravel:

“I know this is raw SQL.”

Therefore, developers must be particularly careful when constructing raw SQL expressions dynamically.

---

The Dangerous Pattern

Avoid code such as:

$column = $request->column;

$query = DB::raw(
    "ORDER BY $column"
);

Here, user input is being inserted into a SQL expression.

Parameter binding is generally designed for values, not arbitrary SQL identifiers such as:

• Column names
• Table names
• SQL keywords
• Sort directions

These require a different approach.

---

How to Safely Handle Dynamic Columns

Suppose users can sort products by:

• Name
• Price
• Created date

Don’t directly trust the requested column:

$column = $request->sort;

Product::orderBy($column)->get();

Instead, use an allowlist:

$allowedColumns = [
    'name',
    'price',
    'created_at',
];

$column = $request->input(
    'sort',
    'created_at'
);

if (!in_array($column, $allowedColumns, true)) {
    $column = 'created_at';
}

$products = Product::orderBy($column)->get();

Now only known column names can be used.

---

Safely Handling Sort Direction

The same principle applies to sort direction.

Don’t blindly trust:

$direction = $request->direction;

Use an allowlist:

$allowedDirections = [
    'asc',
    'desc',
];

$direction = strtolower(
    $request->input('direction', 'asc')
);

if (!in_array($direction, $allowedDirections, true)) {
    $direction = 'asc';
}

Then:

$query->orderBy(
    $column,
    $direction
);

This is an important distinction:

Parameter Binding
        ↓
Best for VALUES

Allowlisting
        ↓
Best for IDENTIFIERS

---

Laravel Validation Is Not the Same as SQL Injection Protection

Laravel validation is extremely useful, but validation alone should not be considered a replacement for parameterized queries.

For example:

$request->validate([
    'email' => [
        'required',
        'email',
    ],
]);

This verifies that the input looks like an email address.

But database queries should still use safe query APIs:

User::where(
    'email',
    $request->email
)->first();

The strongest approach combines:

Validation
    +
Parameterized Queries
    +
Authorization
    +
Least Privilege

---

Laravel and SQL Injection: A Real-World Example

Imagine an e-commerce application with a product search endpoint:

GET /api/products?search=laptop

A controller might look like:

public function index(Request $request)
{
    $search = $request->input('search');

    return Product::where(
        'name',
        'like',
        "%{$search}%"
    )->get();
}

This is a typical safe pattern.

The search term is treated as a value.

The flow is:

GET /api/products?search=laptop
             ↓
       Laravel Request
             ↓
       Query Builder
             ↓
       Bound Parameter
             ↓
          Database

---

Real-World Example: User Login

Consider a login system.

A safe Eloquent query might be:

$user = User::where(
    'email',
    $request->email
)->first();

Then password verification should be handled using Laravel’s password hashing facilities rather than constructing SQL based on the password.

For example:

if (
    $user &&
    Hash::check(
        $request->password,
        $user->password
    )
) {
    // Authentication successful
}

This separates:

• Database lookup
• Password verification
• Authentication logic

from manually constructed SQL.

---

Real-World Example: Filtering Orders

Suppose an admin dashboard allows filtering orders.

A safe Query Builder implementation could be:

$query = DB::table('orders');

if ($request->filled('status')) {
    $query->where(
        'status',
        $request->status
    );
}

if ($request->filled('user_id')) {
    $query->where(
        'user_id',
        $request->user_id
    );
}

$orders = $query->get();

The filter values are handled as parameters.

For more complex applications, validate the request first:

$data = $request->validate([
    'status' => [
        'nullable',
        'string',
        'max:50',
    ],

    'user_id' => [
        'nullable',
        'integer',
    ],
]);

Then build the query from validated data.

---

Does Laravel Automatically Escape SQL Queries?

This is a common misconception.

Laravel does not simply “escape every SQL string.”

Instead, its normal database APIs use parameter binding for values.

This is a much better approach than relying on manually escaping strings.

Think of it this way:

❌ Manual SQL Escaping
Application attempts to clean input

✅ Parameter Binding
Database receives SQL structure
and values separately

Developers should therefore focus on using parameterized database APIs rather than manually escaping SQL strings.

---

What About LIKE Queries?

Developers often wonder whether LIKE queries are safe.

For example:

Product::where(
    'name',
    'like',
    "%{$search}%"
)->get();

The value is still passed as a query parameter.

However, LIKE has special wildcard characters:

%
_

These have meaning inside a SQL LIKE expression.

That is not the same thing as SQL injection.

If your application’s requirements say that % and _ should be treated as literal search characters rather than wildcards, you may need to escape those characters according to your database and query requirements.

The important distinction is:

SQL Injection
≠
LIKE Wildcard Behavior

---

Can Eloquent Queries Still Be Vulnerable?

Yes, if developers bypass safe query construction.

For example:

$name = $request->name;

User::whereRaw(
    "name = '$name'"
)->get();

The fact that the application uses Eloquent does not automatically make this raw SQL safe.

The safer version is:

User::whereRaw(
    'name = ?',
    [$name]
)->get();

Or, preferably:

User::where(
    'name',
    $name
)->get();

This is an important Laravel security lesson:

Using Laravel does not automatically make unsafe SQL safe.

---

Common SQL Injection Mistakes in Laravel

Mistake 1: String Concatenation

Avoid:

$sql = "SELECT * FROM users
        WHERE name = '$name'";

Use parameter binding instead.

---

Mistake 2: Interpolating Input Into whereRaw()

Avoid:

User::whereRaw(
    "email = '$email'"
)->get();

Use:

User::whereRaw(
    'email = ?',
    [$email]
)->get();

---

Mistake 3: Trusting Dynamic Column Names

Avoid:

$orderBy = $request->sort;

$query->orderBy($orderBy);

Use an allowlist.

---

Mistake 4: Assuming Validation Solves Everything

Validation helps control input, but database queries should still use parameterized APIs.

---

Mistake 5: Using Raw SQL Everywhere

Raw SQL isn’t inherently insecure.

The problem is unsafe construction of raw SQL.

Use Eloquent or Query Builder when they can express the query clearly.

---

Safe vs Unsafe Laravel Database Queries

Query Pattern	Security
User::where('email', $email)	✅ Safe
DB::table('users')->where('email', $email)	✅ Safe
DB::select('... WHERE email = ?', [$email])	✅ Safe
whereRaw('email = ?', [$email])	✅ Safe
whereRaw("email = '$email'")	❌ Unsafe
"SELECT ... '$email'"	❌ Unsafe
Dynamic SQL from user input	❌ Risky
Allowlisted dynamic columns	✅ Safer
Validated input + parameter binding	✅ Recommended

---

SQL Injection vs Other Security Vulnerabilities

SQL injection is specifically related to database query manipulation.

A modern Laravel application should also protect against other classes of vulnerabilities.

Vulnerability	Example Protection
SQL Injection	Parameter binding
XSS	Output escaping / sanitization
CSRF	CSRF protection
Broken Authorization	Policies / Gates
Mass Assignment	$fillable / validated data
Brute Force	Rate limiting
Session Attacks	Secure cookies / HTTPS
File Upload Attacks	File validation and safe storage

Security requires multiple layers.

---

Best Practices for Preventing SQL Injection in Laravel

1. Prefer Eloquent

For normal CRUD operations, Eloquent provides a clean abstraction:

User::where(
    'email',
    $email
)->first();

---

2. Use Query Builder for Complex Queries

For queries that don’t naturally fit Eloquent:

DB::table('orders')
    ->where('status', 'paid')
    ->where('user_id', $userId)
    ->get();

---

3. Use Parameter Binding for Raw SQL

If raw SQL is necessary:

DB::select(
    'SELECT * FROM users
     WHERE status = ?',
    [$status]
);

---

4. Never Concatenate User Input Into SQL

Avoid:

$sql .= $request->input('value');

when the resulting string becomes executable SQL.

---

5. Allowlist Dynamic SQL Identifiers

For dynamic:

• Columns
• Sort directions
• Table selections

use predefined allowed values.

---

6. Validate Request Data

Use Laravel validation:

$data = $request->validate([
    'status' => 'required|string',
]);

Then use the validated values in parameterized queries.

---

7. Keep Database Permissions Limited

The application’s database user should have only the permissions it needs.

This follows the principle of least privilege.

---

8. Review Raw SQL During Code Reviews

Pay special attention to:

DB::raw()
whereRaw()
orderByRaw()
selectRaw()
havingRaw()
groupByRaw()

These methods aren’t automatically unsafe, but they deserve additional review whenever dynamic values are involved.

---

A Secure Laravel Database Query Pattern

A practical pattern for production applications is:

public function search(Request $request)
{
    $data = $request->validate([
        'search' => [
            'nullable',
            'string',
            'max:100',
        ],

        'status' => [
            'nullable',
            'string',
            'max:50',
        ],
    ]);

    $query = Product::query();

    if (!empty($data['search'])) {
        $query->where(
            'name',
            'like',
            '%' . $data['search'] . '%'
        );
    }

    if (!empty($data['status'])) {
        $query->where(
            'status',
            $data['status']
        );
    }

    return $query->get();
}

This combines:

Request Validation
        ↓
Controlled Input
        ↓
Eloquent Query
        ↓
Parameter Binding
        ↓
Database

This is a strong pattern for many real-world Laravel APIs.

---

How to Review a Laravel Query for SQL Injection

When reviewing Laravel code, ask these questions:

Question 1

Is user input directly concatenated into SQL?

"WHERE name = '$name'"

If yes, investigate immediately.

Question 2

Is raw SQL being used?

Search for:

DB::raw()
whereRaw()
selectRaw()
orderByRaw()
havingRaw()
groupByRaw()

Question 3

Are raw values parameterized?

Look for:

?

or named bindings:

:name

Question 4

Are dynamic columns allowlisted?

If a user controls a column or sort direction, make sure the value comes from a known list.

Question 5

Is validation being performed?

Validation improves the application’s overall input-handling strategy.

---

SQL Injection Security Checklist for Laravel

Before deploying a Laravel application, review:

☑ Use Eloquent where practical
☑ Use Query Builder for database queries
☑ Use parameter binding for raw SQL
☑ Never concatenate user input into SQL
☑ Avoid untrusted values in raw expressions
☑ Allowlist dynamic column names
☑ Allowlist sort directions
☑ Validate request data
☑ Use least-privilege database credentials
☑ Review raw query methods during code reviews
☑ Keep Laravel and database drivers updated
☑ Test authorization separately from query security

---

Frequently Asked Questions

1. Does Laravel prevent SQL injection automatically?

Laravel provides strong protection against SQL injection when developers use Eloquent, Query Builder, and parameterized queries correctly.

However, developers can still introduce vulnerabilities by constructing unsafe raw SQL or inserting untrusted input into raw SQL expressions.

---

2. Is Laravel Eloquent safe from SQL injection?

Normal Eloquent query methods such as:

User::where('email', $email)->first();

use parameter binding for values and are generally safe against SQL injection.

Problems can arise when developers use raw SQL incorrectly.

---

3. Is DB::raw() safe in Laravel?

DB::raw() is not inherently a SQL injection protection mechanism.

It allows raw SQL expressions to be used, so developers must ensure that untrusted input is not directly inserted into the SQL expression.

---

4. Is whereRaw() safe in Laravel?

whereRaw() can be used safely when values are passed through parameter bindings:

User::whereRaw(
    'email = ?',
    [$email]
)->get();

Avoid directly interpolating user input into the SQL string.

---

5. Does Laravel validation prevent SQL injection?

Validation helps control and verify incoming data, but it should not replace parameterized database queries.

The recommended approach is to combine validation with Eloquent, Query Builder, or parameter binding.

---

6. Can Laravel Query Builder be vulnerable to SQL injection?

The normal Query Builder methods use parameter binding for values and are designed to safely handle them.

However, vulnerabilities can still be introduced when developers use raw SQL methods incorrectly or dynamically construct SQL identifiers.

---

7. Should I use raw SQL in Laravel?

Raw SQL can be appropriate for complex database operations or database-specific functionality.

However, use Eloquent or Query Builder when they can express the query clearly. When raw SQL is necessary, use parameter binding and carefully review any dynamic SQL.

---

8. What is the best way to prevent SQL injection in Laravel?

The most important practices are:

1. Use Eloquent or Query Builder.
2. Use parameter binding for raw queries.
3. Never concatenate untrusted input into SQL.
4. Allowlist dynamic SQL identifiers.
5. Validate incoming data.
6. Use least-privilege database credentials.
7. Review raw SQL carefully during development and code reviews.

---

Conclusion

Understanding how Laravel protects against SQL injection is essential for every Laravel developer building production applications.

Laravel’s Eloquent ORM and Query Builder provide a safer way to interact with databases by using parameterized queries and binding values separately from SQL statements.

For example, this is a preferred approach:

User::where(
    'email',
    $email
)->first();

Instead of manually creating:

"SELECT * FROM users
 WHERE email = '$email'"

The difference is important because user input remains data rather than becoming part of the SQL command.

However, Laravel’s security features are not a substitute for secure development practices. Developers still need to be careful when using:

DB::raw()
whereRaw()
selectRaw()
orderByRaw()
havingRaw()
groupByRaw()

Raw SQL isn’t automatically dangerous, but dynamically inserting untrusted input into raw SQL can create serious vulnerabilities.

The safest general approach is:

Validate Input
      ↓
Use Eloquent / Query Builder
      ↓
Parameter Binding
      ↓
Authorize Access
      ↓
Execute Query
      ↓
Return Controlled Data

By following these practices, Laravel developers can significantly reduce the risk of SQL injection while keeping their database code clean, maintainable, and production-ready.

Secure query design is not just about the framework. It is about how the framework is used.