DEV Community: Manoj Sharma

Laravel Security Best Practices: Protecting Against Common Vulnerabilities

Manoj Sharma — Fri, 27 Feb 2026 07:39:22 +0000

“Security is not a feature. It is a discipline.” - Laravel Community

Key Takeaways

Defense in Depth: Laravel provides multiple built-in security layers (CSRF, hashing, validation, ORM protection) that work best when used together.
OWASP Alignment: Most Laravel security features directly mitigate OWASP Top 10 vulnerabilities such as SQL Injection, XSS, and CSRF.
Secure by Default: Laravel’s opinionated defaults (bcrypt/argon hashing, prepared statements, CSRF middleware) dramatically reduce attack surfaces.
Authentication Hardening: Proper use of guards, rate limiting, and password policies prevents brute-force and credential stuffing attacks.
Configuration Matters: Many security breaches occur not due to framework flaws, but because of misconfigured environments, permissions, or exposed secrets.
Production Readiness: Mature Laravel applications treat security as a continuous process, not a one-time setup.

Index

Introduction
Understanding the Laravel Security Architecture
Common Vulnerability 1: SQL Injection
Common Vulnerability 2: Cross-Site Request Forgery (CSRF)
Common Vulnerability 3: Cross-Site Scripting (XSS)
Common Vulnerability 4: Authentication & Authorization Flaws
Common Vulnerability 5: Mass Assignment
Common Vulnerability 6: File Upload & Storage Risks
Common Vulnerability 7: Sensitive Data Exposure
Rate Limiting & Brute Force Protection
Secure Configuration & Deployment Practices
Statistics
Interesting Facts
FAQs
Conclusion

Introduction

Security is not an optional feature in modern web applications-it is a foundational requirement. As Laravel applications scale in users, data, and integrations, they also become attractive targets for attackers exploiting common vulnerabilities.

Laravel is widely respected for being secure by default, but defaults alone are not enough. Developers must understand why these protections exist and how to apply them correctly. This article walks through Laravel security best practices by mapping real-world vulnerabilities to concrete framework features, helping you build applications that are resilient, compliant and production-ready.

“Security is always excessive until it’s not enough.” - Robbie Sinclair

Understanding the Laravel Security Architecture

Laravel’s security model is layered:

HTTP Layer (Middleware, CSRF, Rate Limiting)
Application Layer (Validation, Authorization, Policies)
Data Layer (Eloquent ORM, Query Builder, Encryption) Each layer assumes the previous one might fail, which is the essence of defense in depth.

Common Vulnerability 1: SQL Injection

Threat: Attackers inject malicious SQL through user input.
The Laravel Solution
Laravel’s Query Builder and Eloquent ORM use prepared statements, eliminating direct query injection.

User::where('email', $request->email)->first();
//Dangerous (avoid raw queries with untrusted input):
DB::select("SELECT * FROM users WHERE email = '$email'");

Benefit: SQL injection risks are virtually eliminated when using Eloquent correctly.

Common Vulnerability 2: Cross-Site Request Forgery (CSRF)

Threat: An attacker tricks an authenticated user into performing unwanted actions.
The Laravel Solution
Laravel automatically protects POST, PUT, PATCH, and DELETE routes using CSRF tokens.

<form method="POST">
    @csrf
</form>

Benefit: Requests without valid tokens are rejected before reaching your business logic.

Common Vulnerability 3: Cross-Site Scripting (XSS)

Threat: Malicious scripts are injected into web pages and executed in users’ browsers.
The Laravel Solution
Blade templates escape output by default.

{{ $user->name }}  <!-- Escaped -->
{!! $html !!}      <!-- Dangerous -->

Best Practice: Never use {!! !!} unless the content is fully trusted or sanitized.

Common Vulnerability 4: Authentication & Authorization Flaws

Threat: Unauthorized access to protected resources.
The Laravel Solution

Authentication via guards (session, token, sanctum, passport)
Authorization via Gates and Policies

$this->authorize('update', $post);

Benefit: Authorization logic is centralized and enforced consistently across controllers.

Common Vulnerability 5: Mass Assignment

Threat: Attackers modify protected model attributes via request payloads.
The Laravel Solution

Explicitly define $fillable or $guarded.
class User extends Model {
    protected $fillable = ['name', 'email'];
}

Benefit: Prevents users from altering sensitive fields like is_admin.

Common Vulnerability 6: File Upload & Storage Risks

Threat: Uploading malicious scripts or executable files.
Best Practices

Validate file types and size
Store uploads outside the public directory

$request->validate([
    'file' => 'required|mimes:jpg,png,pdf|max:2048'
]);

Benefit: Prevents remote code execution and storage abuse.

Common Vulnerability 7: Sensitive Data Exposure

Threat: Leakage of passwords, API keys, or personal data.
The Laravel Solution

Secure hashing using bcrypt() or Argon2
Encrypted environment variables

Hash::make($request->password);

Never:

Commit .env files
Log sensitive data

Rate Limiting & Brute Force Protection

Laravel provides built-in rate limiting middleware.

Route::middleware('throttle:5,1')->group(function () {
    Route::post('/login', 'AuthController@login');
});

Benefit: Protects against brute-force login attempts and API abuse.

Secure Configuration & Deployment Practices

Disable APP_DEBUG in production
Use correct file permissions
Rotate secrets regularly
Keep Laravel and dependencies updated

“Security holes are often configuration bugs wearing a disguise.” - Unknown

Statistics

Over 60% of web application breaches are linked to misconfiguration or improper access control. (Source)
Applications using prepared statements reduce SQL injection incidents by more than 90%. (Source)
Rate limiting can reduce brute-force attack success rates by up to 70%.
The OWASP Top 10 accounts for the majority of real-world Laravel exploit attempts.

Interesting Facts

Blade’s auto-escaping is one of Laravel’s most underrated security features.
Laravel Sanctum is often preferred for SPA authentication due to its reduced attack surface.
Many real-world Laravel hacks originate from exposed .env files, not framework bugs.
CSRF protection was enabled by default in Laravel long before many frameworks adopted it.

FAQs

Q1: Is Laravel secure out of the box?
Yes, but only if you follow best practices and avoid bypassing built-in protections.

Q2: Should I use raw SQL in Laravel?
Only when absolutely necessary and always with parameter binding.

Q3: How often should dependencies be updated?
Regularly. Security patches are released frequently.

Q4: Is hashing enough to protect passwords?
Yes, when combined with strong password policies and rate limiting.

Q5: What is the biggest Laravel security mistake?
Exposing sensitive configuration via .env or public storage.

Conclusion

Laravel security is not about adding more code-it’s about using the framework correctly. By leveraging Laravel’s built-in protections and aligning them with real-world threat models, developers can eliminate entire classes of vulnerabilities before they ever reach production.

As Laravel continues to power millions of applications worldwide, security best practices are what distinguish hobby projects from enterprise-grade systems.

About Author: Manoj is a Senior PHP Laravel Developer at AddWeb Solution , building secure, scalable web apps and REST APIs while sharing insights on clean, reusable backend code.

Advanced Laravel Eloquent: Polymorphic Relationships Explained

Manoj Sharma — Mon, 29 Dec 2025 12:19:26 +0000

"Database schema is a contract. Polymorphism is the clause that allows your application to grow without breaking that contract." - Laravel Architecture Lead

Key Takeaways

Architectural Flexibility: Polymorphic relationships allow a single model to belong to multiple other models using a single association, drastically reducing database schema complexity.
Schema Scalability: Instead of creating separate "post_comments" and "video_comments" tables, you use one "comments" table that serves every entity in your application.
DRY (Don't Repeat Yourself): Logic for attachments, tags, or likes is written once and shared across infinite models.
Decoupling with Morph Maps: Using EnforceMorphMap prevents your database from becoming "coupled" to your PHP class names, ensuring long-term maintainability.
Performance Control: While powerful, polymorphic relations require strategic indexing on morph columns to prevent slow query execution as data scales.
Framework Dominance: Laravel's 35.87% market share in 2025 is largely due to developer-friendly tools like Eloquent that turn complex SQL into readable API calls.

Index

Introduction
The Architecture of Polymorphism
Real-World Use Case 1: Universal Comment System (One-to-Many)
Real-World Use Case 2: Media & Image Library (One-to-One)
Real-World Use Case 3: Flexible Tagging System (Many-to-Many)
Real-World Use Case 4: Global Activity Feeds & Audit Logs
Real-World Use Case 5: Likes and Reactions
The "Morph Map" Essential Pattern
Statistics
Interesting Facts
FAQs
Conclusion

Introduction

In traditional database design, if a User can have an Image and a Product can have an Image, you often end up with two separate tables or a messy table filled with nullable foreign keys. As your application grows, this table expansion makes your schema breaking easily and your code redundant.

Polymorphic relationships are useful in the scenario. They allow a model to "morph" its identity depending on the context. By the end of this article, you will understand how to build a unified database structure that allows your features to grow horizontally without adding a single new table for every new entity.

The Architecture of Polymorphism

At its core, a polymorphic relationship relies on two columns instead of one:

ID: The primary key of the related model (e.g., 10).
Type: The class name or "alias" of the related model (e.g., App\Models\Post).

Laravel uses the morphs() helper in migrations to create these columns automatically with proper indexing.

Real-World Use Case 1: Universal Comment System (One-to-Many)

Imagine your app has Posts, Videos, and Tasks. All of them need comments.
The Implementation:

// Migration
Schema::create('comments', function (Blueprint $table) {
$table->id();
$table->text('body');
$table->morphs('commentable'); // Creates commentable_id and commentable_type
$table->timestamps();
});
// Comment Model
public function commentable() {
return $this->morphTo();
}
// Post Model
public function comments() { 
return $this->morphMany(Comment::class, 'commentable');
}

Benefit: You can now call $post->comments or $video->comments. Eloquent handles the filtering logic behind the scenes, ensuring a video never sees a post's comments.

Real-World Use Case 2: Media & Image Library (One-to-One)

A User has one profile picture, and a Brand has one logo. Both are just images.
The Implementation:

public function image() {
return $this->morphOne(Image::class, 'imageable');
}

Benefit: Centralizing images makes it incredibly easy to implement global features like image optimization or CDN offloading, as all "owner" models interact with the same Image logic.

Real-World Use Case 3: Flexible Tagging System (Many-to-Many)

What if many Posts can have many Tags, and many Products can also have many Tags?
The Implementation: Using morphToMany and morphedByMany, you create a single pivot table (e.g., taggables) that tracks every relationship across the entire app.

class Tag extends Model {
    protected $fillable = ['name'];
    public function posts() {
        return $this->morphedByMany(Post::class, 'taggable');
    }
    public function videos() {
        return $this->morphedByMany(Video::class, 'taggable');
    }
}
class Post extends Model {
    public function tags() {
        return $this->morphToMany(Tag::class, 'taggable');
    }
}
class Video extends Model {
    public function tags() {
        return $this->morphToMany(Tag::class, 'taggable');
    }
}
$post->tags()->sync([1, 2]);

Real-World Use Case 4: Global Activity Feeds & Audit Logs

Track every action: "User A liked Post B" or "User C updated Task D."
The Implementation:

$log = Activity::create([
 'action' => 'updated',
'subject_id' => $task->id,
'subject_type' => get_class($task),
]);

Benefit: Your "Activity Feed" becomes a single stream of polymorphic data that can be rendered using different Blade components based on the subject_type.

Real-World Use Case 5: Reactions

Real-World Use Case 5: Reactions
Instead of post_reactions and comment_reactions, use a Reaction model that morphTo a reactionable entity.
Benefit: You can calculate "Global Popularity" by querying one table, regardless of whether the "Reaction" was on a comment, a photo, or a thread.

class Reaction extends Model {
    protected $fillable = ['user_id', 'type'];
    public function reactionable() {
        return $this->morphTo();
    }
    public function user() {
        return $this->belongsTo(User::class);
    }
}
class Post extends Model {
    public function reactions() {
        return $this->morphMany(Reaction::class, 'reactionable');
    }
    public function likesCount() {
        return $this->reactions()->where('type', 'like')->count();
    }
}
class Comment extends Model {
    public function reactions() {
        return $this->morphMany(Reaction::class, 'reactionable');
    }
}
Reaction::updateOrCreate(
    [
        'user_id' => auth()->id(),
        'reactionable_id' => $post->id,
        'reactionable_type' => Post::class,
    ],
    [
        'type' => 'love',
    ]
);

“You have the right to perform your prescribed duty, but not to the fruits of action.”
— Bhagavad Gita 2.47

The "Morph Map" Essential Pattern

By default, Laravel stores the full class name (e.g., App\Models\Post) in your database. If you ever rename that class, your data breaks.
The Solution: In your AppServiceProvider, define a map :

use Illuminate\Database\Eloquent\Relations\Relation;
public function boot() {
Relation::enforceMorphMap([
'post' => 'App\Models\Post',
'video' => 'App\Models\Video',
]);
}

Now, your database only stores the string post. This decouples your data from your code structure.

Statistics

With proper indexing, polymorphic relationship queries can go from tens of seconds down to sub-millisecond response times on large datasets (Source).
A survey of Object-Relational Mapping (ORM) solutions over 20+ years describes many pattern trade-offs and how complex ORM features have evolved in practice - including polymorphisms, inheritance mapping, etc. (Source).
Unindexed polymorphic queries on tables with >1M rows can be 3x slower than standard foreign keys, making indexing critical.
Polymorphic relationships can reduce the total number of pivot tables in a complex application by up to 34%.

Interesting Facts

The "Morphs" Helper: The $table->morphs('name') migration helper automatically creates an index on both columns, which is vital for performance.
Naming Conventions: If your relation is named imageable, Laravel expects imageable_id and imageable_type.
N+1 Risks: Polymorphic relations are prone to N+1 issues when eager loading isn't used properly (e.g., with('commentable')).
Soft Deletes: If you use Soft Deletes on a parent model, the polymorphic children (like comments) aren't automatically hidden unless you use a cascading package.

FAQs

Q1: Can I use foreign keys with Polymorphic relations? A: No. Since the _id column points to multiple tables, standard database-level foreign key constraints cannot be enforced. You must handle data integrity in your code.

Q2: Are polymorphic relationships slower? A: Slightly, as the database must filter by two columns (Type and ID). However, with proper indexing, the difference is negligible for most apps.

Q3: When should I NOT use them? A: If two entities are fundamentally different and will never share logic, keep them in separate tables. Don't force polymorphism for the sake of it.

Q4: How do I query only "Posts" from a polymorphic "Comments" table? A: Use Comment::where('commentable_type', 'post')->get().

Q5: What is nullableMorphs()? A: It is the same as morphs(), but it allows the _id and _type columns to be NULL.

Conclusion

Polymorphic relationships are the "secret sauce" for building scalable, clean, and professional Laravel applications. They transform your database from a rigid set of tables into a dynamic, flexible ecosystem capable of supporting complex features like tagging, commenting, and logging with minimal overhead.

As Laravel continues to dominate with its 35.87% market share, mastering these advanced Eloquent patterns is what separates a junior developer from a senior architect.

About Author: Manoj is a Senior PHP Laravel Developer at AddWeb Solution , building secure, scalable web apps and REST APIs while sharing insights on clean, reusable backend code.

Laravel Caching Strategies: Boost Your App Speed with Redis, Query Cache & Response Cache

Manoj Sharma — Fri, 19 Dec 2025 07:34:27 +0000

"Caching is the closest thing we have to a 'magic button' for scalability. Use it wisely, and your servers will thank you." - Senior Backend Architect

Key Takeaways

Caching is the ultimate performance multiplier, shifting the load from expensive CPU/Database operations to lightning-fast memory storage.
Redis stands as the industry-standard driver for Laravel caching due to its atomic operations and incredible throughput.
Query Caching targets the database layer, preventing repetitive SQL execution for data that doesn't change frequently.
Response Caching can deliver entire HTML pages in milliseconds by bypassing the entire application lifecycle for guest users.
Cache Tags are essential for enterprise applications, allowing developers to invalidate specific groups of cached data without clearing the entire system.
Laravel 12 continues to dominate with over 2.5 million websites and a 35.87% market share, making performance optimization a high-demand skill.

Index

Introduction
The Laravel Cache Architecture
Why Redis is King
Real-World Use Case 1: High-Traffic Product Catalog (Redis)
Real-World Use Case 2: Expensive Dashboard Analytics (Query Cache)
Real-World Use Case 3: Public Blog/News Landing Pages (Response Cache)
Real-World Use Case 4: API Rate Limiting and Atomic Locks
Real-World Use Case 5: Multi-Tenant Settings Caching (Cache Tags)
Performance Optimization: The 'Remember' Pattern
Statistics
Interesting Facts
FAQs
Conclusion

Introduction

In the modern web, speed isn't just a luxury - it's a requirement. A one-second delay in page load time can lead to a 7% reduction in conversions. If you've built a Laravel application that feels sluggish as your database grows, you're likely hitting a bottleneck that raw server power can't solve.

This guide dives into the architectural heart of Laravel's caching system. We will move beyond simple Cache::put() examples and explore how to implement Redis for massive scale, how to surgically cache database queries, and how to serve entire responses instantly. Whether you're managing a high-traffic e-commerce store or a data-heavy SaaS, these strategies will transform your user experience.

The Laravel Cache Architecture

Laravel provides a unified API for various caching backends. This "driver-based" approach means you can write the same code whether you are caching a simple file or a distributed Redis cluster.

The Main Drivers:

File: Great for local development; stores data in storage/framework/cache.
Database: Useful if you can't install Redis; uses a dedicated table.
Redis: The gold standard. An in-memory data structure store used as a database, cache, and message broker.
Memcached: A high-performance, distributed memory object caching system.

Why Redis is King

While the file driver is easy, Redis is built for concurrency. When hundreds of users hit your site simultaneously, the file system can experience "locking" issues. Redis handles thousands of operations per second with sub-millisecond latency because it lives entirely in RAM.

Real-World Use Case 1: High-Traffic Product Catalog (Redis)

In e-commerce, fetching 50 products with their categories, images, and prices on every page load is expensive.

The Implementation:

namespace App\Services;

use App\Models\Product;
use Illuminate\Support\Facades\Cache;

class ProductService
{
    public function getActiveProducts()
    {
        // Cache for 1 hour (3600 seconds)
        return Cache::remember('products.active.all', 3600, function () {
            return Product::with(['category', 'images'])
                ->where('is_active', true)
                ->get();
        });
    }
}

Benefit: The database is hit exactly once every hour. The other 10,000 visitors receive the data from Redis in ~2ms.

Real-World Use Case 2: Expensive Dashboard Analytics (Query Cache)

Imagine a dashboard showing "Total Sales This Year." This query might scan millions of rows.

The Implementation:

$stats = Cache::remember('stats.yearly_sales.' . auth()->id(), now()->addMinutes(30), function () {
    return Order::where('user_id', auth()->id())
        ->whereYear('created_at', now()->year)
        ->sum('total_amount');
});

Benefit: Instead of the CPU calculating millions of rows on every dashboard refresh, Laravel retrieves the pre-calculated sum from the cache.

Real-World Use Case 3: Public Blog/News Landing Pages (Response Cache)

For public pages like a "Privacy Policy" or "Trending News," why even boot up Eloquent?
Using packages like spatie/laravel-responsecache, you can cache the entire HTML output.

// In your routes/web.php
Route::middleware('doNotCacheResponse')->group(function () {
    // Routes that should NOT be cached (User Profile, Checkout)
});

Route::middleware('cacheResponse:600')->group(function () {
    // Public pages cached for 10 minutes
    Route::get('/trending', [NewsController::class, 'index']);
});

Benefit: The server sends the HTML directly to the browser, bypassing the Controller and Database entirely.

Real-World Use Case 4: API Rate Limiting and Atomic Locks

Caching isn't just for data; it's for control. Atomic locks prevent "Race Conditions" (e.g., two people claiming the last ticket at the exact same microsecond).

use Illuminate\Support\Facades\Cache;

$lock = Cache::lock('processing-payment-' . $user->id, 10);

if ($lock->get()) {
    // Process the payment safely
    // ...
    $lock->release();
} else {
    return response()->json(['error' => 'Please wait for previous transaction'], 429);
}

Real-World Use Case 5: Multi-Tenant Settings Caching (Cache Tags)

If you have a SaaS where users can change their "Brand Color," you need to clear the cache only for that user when they hit save.

// Storing with tags
Cache::tags(['user:' . $user->id, 'settings'])->put('color', '#ff0000', 3600);

// Invalidating only this user's settings cache
Cache::tags(['user:' . $user->id])->flush();

Benefit: You don't have to clear the cache for all 1,000 tenants just because one tenant updated their profile.

Performance Optimization: The 'Remember' Pattern

Instead of using Cache::get() and Cache::put() separately, always use Cache::remember(). This prevents "Cache Stampede" - a situation where multiple requests find the cache empty at the same time and all try to regenerate it, crashing the database.

Statistics

Performance Gain: Applications using Redis caching typically see a 60-80% reduction in Database Load. (Source)
Scale: Over 2.5 million websites are powered by Laravel globally as of 2025. (Source)
Market Share: Laravel holds a 35.87% market share among PHP frameworks. (Source)
User Retention: Sites that load in under 2 seconds have a 15% lower bounce rate than those loading in 4 seconds (Source).

"Caching is the closest thing we have to a 'magic button' for scalability. Use it wisely, and your servers will thank you." - Senior Backend Architect

Interesting Facts

TTL (Time To Live): In older versions of Laravel, cache time was in minutes. In modern versions, it is in seconds.
The "Null" Driver: Laravel includes an array driver that only persists for the duration of a single request-perfect for testing.
Encapsulation: You can cache entire Eloquent Collections, but remember that when you retrieve them, they are "unserialized" objects, not fresh database records.
Sugar: Laravel 11+ introduced Cache::flexible(), allowing you to serve "stale" data while a background task refreshes the cache.

FAQs

Q1: Is Redis better than the File driver? A: Yes, for production. Redis is in-memory (fast) and supports concurrent access without file-locking issues.

Q2: How do I clear the cache for just one key? A: Use php artisan cache:forget key-name or Cache::forget('key') in your code.

Q3: Will caching use up all my server RAM? A: If using Redis, yes, it uses RAM. You should set a maxmemory limit and an eviction policy (like allkeys-lru) in your Redis config.

Q4: Can I cache images in Laravel Cache? A: It's better to cache the URL or the Path to the image. Caching raw binary image data in Redis can bloat memory quickly.

Q5: What is a Cache Stampede? A: It's when a popular cache key expires and 1000 users all try to re-calculate it at once. Using Atomic Locks can prevent this.

Q6: Should I cache every database query? A: No. Only cache queries that are slow and return data that doesn't change on every single request.

Q7: How do I test if my cache is working? A: You can use Log::info() inside your Cache::remember closure. If you see the log on every refresh, the cache isn't hitting.

Q8: Does php artisan config:cache clear my data cache? A: No. config:cache is for configuration files. Use php artisan cache:clear for your data.

Q9: Can I use multiple cache stores at once? A: Yes. You can use Cache::store('redis')->get(...) and Cache::store('file')->get(...) in the same app.

Q10: What are Cache Tags? A: They are labels that allow you to group related cache keys so you can clear them all at once (e.g., all keys related to 'reports').

Conclusion

Mastering Laravel caching is the bridge between a "side project" and a "production-grade" application. By strategically implementing Redis for high-frequency data, Query Caching for heavy analytics, and Response Caching for public pages, you ensure your app remains responsive regardless of user growth.
As Laravel continues to dominate the web with its 35.87% framework market share, performance is the metric that will set your work apart. Stop making your database do work it has already done - start caching.

About Author: Manoj is a Senior PHP Laravel Developer at AddWeb Solution , building secure, scalable web apps and REST APIs while sharing insights on clean, reusable backend code.

Advanced Laravel Eloquent: Custom Query Builders and Model Scopes

Manoj Sharma — Fri, 17 Oct 2025 07:39:43 +0000

When working with Laravel, one of the most powerful tools at your disposal is Eloquent ORM. While basic queries with where(), orderBy(), and relationships cover 80% of real-world needs, advanced applications often demand reusable, clean, and scalable query logic.

This is where Custom Query Builders and Model Scopes come into play. They allow you to extract business logic from controllers and services, keep your queries expressive and improve maintainability.

Index

Introduction
Model Scopes
Custom Query Builders
Combining Scopes and Builders
When to Use What
Performance Optimization with Scopes
Real-Life Case Study
Key Takeaways
FAQs
Conclusion

1. Model Scopes

Scopes are predefined query filters that can be reused across your project.

Example: Active Users Scope
Imagine you have a User model where users can be active or inactive.

Instead of writing this repeatedly:

$activeUsers = User::where('status', 'active')->get();

You can create a scope inside User.php:

class User extends Model
{
    // Local Scope
    public function scopeActive($query)
    {
        return $query->where('status', 'active');
    }

    // Dynamic Scope Example
    public function scopeStatus($query, $status)
    {
        return $query->where('status', $status);
    }
}

Now you can call:

$activeUsers = User::active()->get();
$inactiveUsers = User::status('inactive')->get();

Cleaner, reusable, and expressive.

“I tend to identify the awkward spots in the framework fairly quickly too, because I'm using it so much, in a real-world setting. The community drives the development in a lot of ways, and I add my own insights here and there too.” - Taylor Otwell

2. Global Scopes

Sometimes you need automatic query conditions applied everywhere.
For example, in a multi-tenant SaaS app, every model should automatically filter data by tenant_id.

use Illuminate\Database\Eloquent\Builder;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Scope;

class TenantScope implements Scope
{
    public function apply(Builder $builder, Model $model)
    {
        $builder->where('tenant_id', auth()->user()->tenant_id);
    }
}

Attach it to your model:

class Project extends Model
{
    protected static function booted()
    {
        static::addGlobalScope(new TenantScope);
    }
}

Now:

Project::all(); // always filtered by tenant_id automatically

3. Custom Query Builders

For more complex logic, you can create custom query builder classes.

Real-Time Example: Filtering Orders

Suppose you’re building an eCommerce dashboard where admins filter orders by status, date, or payment method.
Instead of writing multiple if/else queries in controllers, create a custom query builder.

Step 1: Create Custom Builder

namespace App\QueryBuilders;
use Illuminate\Database\Eloquent\Builder;

class OrderBuilder extends Builder
{
    public function paid()
    {
        return $this->where('payment_status', 'paid');
    }

    public function status($status)
    {
        return $this->where('status', $status);
    }
    public function dateBetween($start, $end)
    {
        return $this->whereBetween('created_at', [$start, $end]);
    }
}

Step 2: Attach to Model

use App\QueryBuilders\OrderBuilder;
use Illuminate\Database\Eloquent\Model;

class Order extends Model
{
    public function newEloquentBuilder($query)
    {
        return new OrderBuilder($query);
    }
}

Step 3: Use It in Controllers

$orders = Order::query()
    ->paid()
    ->status('shipped')
    ->dateBetween('2025-09-01', '2025-09-10')
    ->get();

Clean, chainable, and highly reusable.

4. Combining Scopes and Builders

You can mix local scopes and custom builders for maximum power.
Example:

$recentPaidOrders = Order::paid()
    ->status('delivered')
    ->dateBetween(now()->subDays(7), now())->get();

Here, paid() and status() come from the custom builder.

5. When to Use What?

Local Scopes -> For small, reusable conditions (active(), published()).
G*lobal Scopes ->* For tenant filtering, soft deletes, always-on conditions.
Custom Query Builders -> For complex, chainable business queries across models.

“If you have to spend effort looking at a fragment of code and figuring out what it's doing, then you should extract it into a function and name the function after the what” - Martin Fowler

6. Performance Optimization with Scopes

Scopes can also help optimize queries by avoiding N+1 queries.
Example: Counting Relationships
Instead of:

$users = User::all();
foreach ($users as $user) {
    echo $user->posts->count(); // N+1 problem
}

Define a scope in User model:

class User extends Model
{
    public function scopeWithPostsCount($query)
    {
        return $query->withCount('posts');
    }
}

Now:

$users = User::withPostsCount()->get();
foreach ($users as $user) {
    echo $user->posts_count;//Single optimized query
}

7. Key Takeaways

Local Scopes > Best for small, reusable query filters (e.g., published, activeUsers)
Global Scopes > Apply system-wide rules automatically (e.g., tenant_id in multi-tenant apps).
Custom Query Builders > Perfect for complex, chainable business queries (e.g., filtering orders by date, status, payment).
Dynamic Scopes > Accept parameters for flexible filtering (e.g., category($id)).
Performance Scopes > Use withCount() and eager loading inside scopes to prevent N+1 queries.
Readability & Maintainability > Controllers and services stay clean, queries become self-explanatory.

When your app grows, organizing query logic with scopes and builders is not optional - it’s essential for scalability and maintainability.

“I have always wished that my computer would be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone.” - Bjarne Stroustrup

8. Real-Life Case Study

In one of our projects (a multi-tenant SaaS CRM), we:

Used global scopes to automatically restrict all queries by tenant_id.
Defined local scopes like scopeActiveLeads() and scopeConvertedLeads().
Built a custom query builder for filtering leads by industry, lead_score, and source. This reduced controller complexity by 70% and made queries self-explanatory for new developers.

Result:

Cleaner controllers
Fewer bugs from repeated query conditions
Faster API responses

9. FAQs

1. What are Model Scopes in Laravel?
Reusable query filters in models to keep your queries clean and DRY.

2. When should I use Custom Query Builders?
For complex, chainable queries that go beyond simple filters.

3. Can Scopes and Builders be combined?
Yes, combining them allows both simple and advanced query logic.

4. How do they improve performance?
They reduce repetitive queries and prevent N+1 issues with optimized loading.

10. Conclusion

Laravel’s Eloquent ORM isn’t just about where and get. With local scopes, global scopes, and custom query builders, you can build clean, DRY, and scalable query logic that reads like plain English.
Use Local Scopes for small reusable filters.

Use Global Scopes for automatic, system-wide conditions.
Use Custom Builders for complex, chainable business queries.
Optimize performance with withCount(), eager loading, and scope-based prefetching.

About Author: Manoj is a Senior PHP Laravel Developer at AddWeb Solution , building secure, scalable web apps and REST APIs while sharing insights on clean, reusable backend code.