Laravel application security: CSRF, XSS, SQL injection and OWASP
Site and panel breaches are not bad luck. They come from skipped defences. Laravel ships with protection against the most common attacks — if someone actually uses it.
Business owners rarely ask about CSRF tokens. They ask whether someone can steal the customer database, peek at the price list, or knock the panel over on a Friday night. Those questions map to a few classic attack types — and Laravel defends against them out of the box, if the app is built properly.
Three attacks that still work on cheap websites
SQL injection — stealing data through a form
An attacker pastes a malicious SQL fragment into search or login. A poorly written app runs it on the database. In Laravel, Eloquent and the query builder use bound parameters, so raw SQL from a form never reaches the database. We use raw queries only rarely — always with bindings.
XSS — a malicious script in the user’s browser
If the app renders a customer name or comment without escaping, someone can inject a script that steals a session or rewrites the page. Laravel’s Blade engine escapes variables by default. Vue.js also escapes content unless you deliberately use v-html. We never do that with user data.
CSRF — an action in your name
The user is logged in. They open another site that silently sends a “change password” or “transfer funds” request to your app. Laravel requires a CSRF token on forms and state-changing requests — without it the server rejects the call.
OWASP Top 10 — a checklist, not marketing
OWASP Top 10 is the list of the most serious web-app risks. At GESOFT we treat it as a checklist, not a slogan:
- Broken access control — Laravel roles and policies, permission tests, no “secret URLs” as the only defence.
- Cryptographic failures — bcrypt/argon2 passwords, HTTPS everywhere, secrets only in .env, never in Git.
- Injection — ORM, request validation, allow-lists instead of trusting the client.
- Security misconfiguration — debug off in production, separate environments, least-privilege database users.
- Vulnerable components — regular dependency updates, CVE monitoring, no abandoned packages.
- Identification failures — login rate limits, 2FA, expiring sessions, password reset with a one-time token.
What we add beyond Laravel defaults
- Rate limiting on login, forms and APIs — makes password guessing and spam harder.
- Security headers (HTTPS, HSTS, frame restrictions, referrer policy).
- Audit logs: who changed sensitive data, when, and from which IP.
- Database and file backups, with a tested restore — an untested backup is not a backup.
- Two-factor login where the panel touches money or personal data.
- Server hardening: firewall, SSH keys only, OS updates.
If you already have a PHP app and are not sure these things are in place, start with a security audit. New projects get these controls from day one. Tell us what you need to protect — we will say exactly where to start.
Describe your project