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
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
orimage
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'");
No binding. Total SQL injection vulnerability.
Fix it:
Use parameter binding or Eloquent:
User::where('email', $email)->first();
🧩 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]);
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/
andbootstrap/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)