Kamruzzaman Kamrul

Posted on Jun 27

Laravel Is Secure by Default... Until It’s Not

#laravel #php #programming #security

When I first started building Laravel apps, I felt confident.
Why? Because Laravel ships with so many great defaults: CSRF protection, hashed passwords, validation rules, Eloquent sanitization... the list goes on.

But then something happened.
One of my apps—deployed in production—leaked sensitive data because I forgot to turn off APP_DEBUG. Another time, a malicious user uploaded a PHP file disguised as an image and gained shell access.

That’s when I learned the hard truth:
Laravel is secure by default… until you override those defaults or forget to configure the rest.

This post isn’t a hit piece on Laravel. I love the framework.
But like any powerful tool, Laravel assumes you know what you’re doing when you go to production.

Let’s break down a few areas where “secure by default” can give you a false sense of safety—and how to fix that.

1. `APP_DEBUG=true` in Production

Yes, it’s the classic Laravel mistake.
Leave APP_DEBUG=true in production and suddenly, if an error occurs, Laravel shows a stack trace, complete with:

File paths
Environment variables
Database credentials
Secret keys

All served nicely to anyone who hits that broken route.

✅ Fix:

Always set:

APP_ENV=production
APP_DEBUG=false

And better yet, automate that check in your CI/CD or deploy script.

2. CSRF Protection Can Be Bypassed

Laravel includes CSRF protection out of the box.
But I’ve seen countless developers manually exclude routes for APIs, AJAX, or mobile apps—without adding a secure alternative.

protected $except = [
    'api/*',
    'checkout/submit',
];

This opens the door to CSRF attacks, especially if cookies are used for session authentication.

✅ Fix:

For APIs, use token-based auth (Sanctum, Passport).
Never disable CSRF protection on web routes unless you're 100% sure they don't need it.

3. Validation Isn’t a Firewall

Laravel's validation is powerful, but it’s not bulletproof.

Example: using required|string doesn’t mean your input is safe from XSS if you forget to escape output in Blade templates.

{!! $comment->body !!}

If $comment->body contains <script>alert('xss')</script>, you’ve just introduced a front-end vulnerability.

✅ Fix:

Use {{ $comment->body }} instead of {!! !!} unless you're 100% sure it’s sanitized.
Use libraries like HTMLPurifier or Laravel-specific wrappers to clean rich text.

4. File Uploads Are a Playground for Attackers

Laravel makes file uploads easy. But validating them safely? That’s a bit trickier.

Attackers can:

Rename a .php file to .jpg
Bypass MIME checks
Upload executable code to your server

✅ Fix:

Use $request->file('avatar')->store('avatars'); — which stores outside public/
Validate MIME types and extensions
Never allow user uploads to go directly into the public/ folder

5. SQL Injection Isn’t Dead (Yes, Even in Laravel)

Eloquent and the query builder do a great job of binding parameters.
But as soon as you use raw queries or DB::statement with concatenated input…

DB::select("SELECT * FROM users WHERE email = '$email'");

You're on dangerous ground.

✅ Fix:

Always bind variables properly:

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

Better yet, use Eloquent or Query Builder whenever possible.

6. Permissions: The Hidden Hole

Laravel’s Gate and Policy system is robust.
But many developers forget to apply policies in places like:

API endpoints
Resource controllers
Background jobs
Blade components (e.g., “Edit” button rendered when it shouldn’t be)

One unchecked condition, and you’ve got privilege escalation.

✅ Fix:

Use $this->authorize() in controllers
Wrap actions in @can() in Blade
Create reusable role-permission models (and avoid reinventing ACL logic every project)

The Real Takeaway

Laravel gives you powerful tools—but you still have to use them correctly.

Security in Laravel isn’t just about avoiding mistakes. It’s about developing the habit of asking:

What happens if someone abuses this?
What would a hacker try here?
What assumptions am I making about user input?

💡 Want to Dive Deeper?

This post barely scratches the surface.

If you're building or maintaining Laravel apps—and you care about protecting user data, your business, and your peace of mind—I wrote a full book on this:

📘 *Bulletproof Laravel: Write Code That Hackers Hate*
It covers everything from: