Let's Connect

Padlock on a keyboard symbolizing application security

Laravel ships with excellent security defaults — CSRF protection, hashed passwords, SQL injection safety through the query builder. Yet I still find the same vulnerabilities in almost every codebase I audit. They are not framework failures; they are usage failures. This is the checklist I run.

Authorization, not just authentication

Logging in says who you are; authorization says what you may touch. Every route that loads a resource by id needs a policy check — $this->authorize('view', $invoice) — or one guessed URL exposes another user's data (IDOR, the most common bug I find). Route model binding plus policies makes this nearly free; there is no excuse to skip it.

Mass assignment is still biting people

Model::create($request->all()) with a permissive $fillable lets an attacker post is_admin=1. Use $request->validated() exclusively, keep $fillable tight, and treat any ->all() in a controller as a code review failure.

File uploads: validate like you mean it

  • Validate MIME type and extension allow-lists, never deny-lists
  • Store uploads outside the public path or on S3; serve via signed URLs
  • Re-encode images (Intervention) to strip embedded payloads
  • Generate filenames yourself — never trust the client's

The environment around the code

  • APP_DEBUG=false in production — debug pages leak credentials
  • Secrets in env or a secret manager, never committed; rotate on team departures
  • Security headers (CSP, X-Frame-Options, HSTS) via middleware
  • composer audit in CI so vulnerable dependencies fail the build
  • Rate limiting on login, password reset, and any endpoint that sends email or SMS
Audits find the same five issues every time. Fix the boring things and you are ahead of 90% of applications.Md Raihan Hasan