10 Things NOT to Do When Developing a Laravel App (Security Edition)

Laravel makes building modern PHP applications a breeze—but it’s also easy to make dangerous mistakes if you’re not careful. In this post, we cover 10 things you should absolutely avoid doing when building a Laravel app, with a focus on security.

1. ❌ Skipping Input Validation

Not validating request data allows attackers to inject unexpected or malicious input.

✅ Do this:

$request->validate([
    'email' => 'required|email',
    'password' => 'required|min:8',
]);

Use Laravel’s built-in validation to whitelist acceptable input.

2. ❌ Trusting $request->all() Without Filtering

Dumping all request input into a model is a quick path to mass assignment vulnerabilities.

// BAD
User::create($request->all());

✅ Do this:

Use $request->only() or $request->validated() and define $fillable on your models.

3. ❌ Leaving Debug Mode On in Production

Debug mode (APP_DEBUG=true) can expose stack traces, environment variables, and DB credentials.

✅ Always set:

APP_DEBUG=false
APP_ENV=production

In production .env files.

4. ❌ Hardcoding Secrets in Code

Putting secrets like API keys, DB passwords, or tokens in your controller or config files is a huge risk.

✅ Use .env files and Laravel’s env() helper in config files only (not in code logic).

'api_key' => env('THIRD_PARTY_API_KEY'),

5. ❌ Not Using CSRF Protection

Laravel uses CSRF tokens by default, but disabling it or using external frontends without syncing can expose you.

✅ Keep VerifyCsrfToken middleware enabled and use @csrf in forms:

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

For APIs, use Laravel Sanctum or Passport for token-based protection.

6. ❌ Storing Passwords in Plaintext

If you’re manually handling passwords (not recommended), never store them raw.

✅ Always hash passwords:

use Illuminate\Support\Facades\Hash;

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

Laravel uses bcrypt or argon2 under the hood.

7. ❌ Ignoring Authorization Checks

Just because a user is authenticated doesn’t mean they can access everything.

✅ Use Laravel’s Gate, Policy, or middleware like can:

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

Or in Blade:

@can('delete', $post)
    <button>Delete</button>
@endcan

8. ❌ Failing to Escape Output in Blade

Rendering unescaped user input opens the door to XSS attacks.

❌ Bad:

{!! $user->bio !!}

✅ Good:

{{ $user->bio }}

Only use {!! !!} when you’re 100% sure the content is safe (e.g. sanitized Markdown).

9. ❌ Using Old or Unmaintained Packages

Abandoned Laravel packages may contain unpatched vulnerabilities.

✅ Audit dependencies regularly:

composer audit
composer outdated

Stick to well-known, updated packages and monitor CVE databases.

10. ❌ Forgetting to Set Proper File Permissions

Improper permissions on .env, storage/, or bootstrap/cache/ can expose secrets or break the app.

✅ Recommended:

chmod 640 .env
chmod -R 775 storage bootstrap/cache
chown -R www-data:www-data storage bootstrap/cache

Never expose .env, .git, or vendor/ directories over the web.

✅ Final Thoughts

Laravel provides a secure foundation, but it’s your job to use it responsibly. Avoiding these 10 pitfalls can save your app from being hacked, defaced, or worse. Stay up to date, write defensive code, and remember: security is a process, not a feature.

If you’re deploying Laravel apps professionally, consider adding security headers, rate limiting, and logging as part of your standard checklist.

Stay safe, and code smart.