DEV Community

Kamruzzaman Kamrul
Kamruzzaman Kamrul

Posted on

Top 10 Laravel Security Mistakes I Made (So You Don’t Have To)

Let’s be honest: most developers don’t start their Laravel journey thinking about security.
We focus on making things work. Then, someday, something breaks—or worse, someone breaks in.

I’ve been building Laravel apps for years now, from MVPs to full-fledged SaaS products. And along the way, I’ve made some security mistakes. Some were small oversights. Others were the kind of mistakes that make you lose sleep.

Here are 10 security mistakes I’ve made as a Laravel developer—so you don’t have to.


🔥 1. Leaving APP_DEBUG=true in Production

Yes, I’ve done it.
I deployed with APP_DEBUG=true, and when something crashed, the entire stack trace—with env values, file paths, and database credentials—was exposed.

Fix it:
Always set:

APP_ENV=production
APP_DEBUG=false
Enter fullscreen mode Exit fullscreen mode

Add checks in your CI/CD pipeline to prevent this in the future.


🧪 2. Using {!! $userInput !!} Without Sanitization

I once let users post formatted content using a WYSIWYG editor and rendered it in Blade using {!! !!}.
Guess what? They embedded <script>alert('xss')</script> and it executed.

Fix it:

  • Never trust user input.
  • Use {{ }} unless you're 100% sure content is sanitized.
  • Use tools like mewebstudio/purifier to clean HTML.

📤 3. Letting Users Upload Files Without Control

I allowed file uploads without validating MIME type, file extension, or storage location.
One user uploaded a .php file disguised as a .jpg, and that nearly turned into a server breach.

Fix it:

  • Store files outside public/
  • Validate MIME types with Laravel’s mimes or image rules
  • Disable script execution in your storage directories

🔐 4. Using Raw SQL with User Input

I was in a rush and wrote something like:

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

No binding. Total SQL injection vulnerability.

Fix it:
Use parameter binding or Eloquent:

User::where('email', $email)->first();
Enter fullscreen mode Exit fullscreen mode

🧩 5. Not Enforcing Authorization Everywhere

I assumed that once I used Policies in a few controllers, I was safe.
Then I realized: API routes, queued jobs, and blade templates weren’t enforcing them.

Fix it:

  • Use $this->authorize() in every controller method
  • Use @can in Blade views
  • Wrap your logic in Gates and Policies consistently

🧠 6. Not Requiring Email Verification

I let users sign up and immediately start using the app.
Then spammers found it and flooded my system with fake accounts.

Fix it:
Use Laravel’s built-in email verification with:

Auth::routes(['verify' => true]);
Enter fullscreen mode Exit fullscreen mode

And protect routes with ->middleware('verified')


🕵️‍♂️ 7. Ignoring Suspicious Behavior

I didn’t track failed logins, rapid password reset attempts, or unusual activity.
By the time I realized something was off, it was too late.

Fix it:

  • Track login attempts and lock out after X failures
  • Use Laravel’s throttle middleware
  • Add activity logging (e.g., with Laravel Auditing)

⚙️ 8. Committing .env Files to Git

Early on, I didn’t use .gitignore properly, and I accidentally committed my .env file—including API keys and DB credentials.

Fix it:

  • Use .gitignore to exclude .env
  • Store secrets securely (e.g., Laravel Vault, 1Password, AWS Secrets Manager)

📂 9. Giving Wrong File Permissions

I once set 777 on the entire Laravel folder during a deployment issue.
That “fixed it”... and opened everything to the world.

Fix it:

  • Set correct permissions: 755 for directories, 644 for files
  • Ensure storage/ and bootstrap/cache/ are writable—but nothing else

🧵 10. Underestimating Queue & Scheduler Security

I wrote jobs that assumed data was always valid—then a malicious user queued a job with manipulated input.
The job ran without validation. Boom.

Fix it:

  • Validate input in jobs, even if it's validated earlier
  • Never assume background processes are immune to abuse

💡 Final Thoughts

Security in Laravel isn’t about writing paranoid code—it’s about being deliberate.
You don’t need to know everything, but you do need to stop trusting everything.

If you’ve made some of these mistakes, you’re not alone—I’ve made them too. That’s why I wrote a book.


📘 Bulletproof Laravel: Write Code That Hackers Hate

This book is everything I wish I had when I started building Laravel apps.
It’s packed with real-world security strategies, code examples, case studies, and production checklists.

👉 Grab it on Amazon: https://www.amazon.com/dp/B0FFNT7BMQ

if you want to stop writing code that just “works” and start writing code that can’t be broken.


Have you made any of these mistakes—or others I didn’t list?
Drop them in the comments 👇. Let’s help each other write safer Laravel apps.

Top comments (0)