Written by Technical Team | Last updated 15.08.2025 | 17 minute read
Every Laravel development company eventually faces the same unglamorous truth: most security incidents are not arcane feats of cryptography, but simple input and output mistakes. SQL injection and cross-site scripting (XSS) sit at the top of that list. Both exploit basic assumptions in how we accept, store and display data. The good news is that Laravel ships with strong defaults that make these bugs rarer—if you lean into them. The bad news is that a single “quick fix” using raw SQL, an unescaped output tag, or an enthusiastic copy-paste from Stack Overflow can unwind those protections in seconds.
SQL injection is, at heart, a data/command confusion problem. The database expects a prepared command with placeholders; the attacker tries to slip additional commands into your data. If you concatenate user input into a SQL string, you risk letting the database interpret that input as part of the command. Laravel’s Eloquent ORM and Query Builder use PDO prepared statements under the bonnet, so the framework will parameterise values for you when you use the standard APIs. Injection creeps in the moment you reach for hand-rolled SQL, dynamic identifiers, or “clever” shortcuts in raw expressions.
XSS flips the direction of travel. Instead of smuggling commands into the database, an attacker smuggles executable script into your users’ browsers. If you print untrusted input into an HTML page without escaping, the browser may execute it as JavaScript. Stored XSS persists in your database (e.g., a malicious profile bio that runs on every profile page); reflected XSS bounces off your server in a single response (e.g., an error message echoing a query parameter); DOM-based XSS happens entirely in the browser when client-side code welds untrusted values into the DOM. Laravel’s Blade templates escape using {{ }} by default, which neutralises many cases—but attributes, inline scripts, JSON contexts and careless use of {!! !!} remain fertile ground for mistakes.
It’s crucial to recognise that neither class of attack is purely “backend” or “frontend”. SQL injection often starts with a route and controller pattern that steers developers towards raw filters, sorts or search queries. XSS frequently begins with server-side rendering that feeds the frontend, or with JSON that the frontend maps into the DOM. Successful defence, therefore, requires end-to-end thinking: from routing and validation to database privileges, from Blade to Content Security Policy (CSP), from CI security tests to runtime monitoring.
Finally, security is not a one-off sprint. Framework versions evolve, browser defaults shift, and new patterns—Livewire components, Inertia stacks, AlpineJS sprinkles—introduce new template contexts and escaping rules. Treat the guidance below as a living playbook: strong defaults, safe patterns, and repeatable checks that you embed into your engineering culture.
The safest Laravel applications are almost boring in how they talk to the database. They stick to Eloquent for reads and writes, lean on the Query Builder for complex aggregations, and use parameter binding whenever they must reach for raw SQL. Boredom is a feature here; it means the database always sees data and command separately.
Start with the obvious: avoid string concatenation. If you find yourself writing “WHERE email = ‘$email'”, stop. The Query Builder automatically parameterises values passed to where, orWhere, whereBetween, update, and so on. The following is safe:
// Safe: parameters are bound using PDO
User::where('email', $request->input('email'))->first();
Where most teams slip is in dynamic queries, particularly when filtering, sorting and searching. The impulse to “keep it DRY” leads to code that splices untrusted values into column names or raw fragments. Remember that identifiers (table names, column names, direction keywords) are not parameterised by PDO. If you must accept a sort or filter key from users, map it to a whitelist of known, safe column names:
// Whitelist for orderable columns
$sortable = [
'name' => 'users.name',
'joined' => 'users.created_at',
'status' => 'users.status',
];
$sort = $request->query('sort');
$direction = $request->query('direction') === 'desc' ? 'desc' : 'asc';
// Only use mapped, known identifiers
$orderByColumn = $sortable[$sort] ?? 'users.created_at';
$users = User::query()
->when($request->filled('status'), fn ($q) => $q->where('status', $request->status))
->orderBy($orderByColumn, $direction)
->paginate(20);
Sometimes you truly need raw SQL—for example, optimising a complex report or using database-specific functions. Use bound parameters even in whereRaw, havingRaw or DB::select:
// Safe raw query with bound parameters
$min = (int) $request->query('min', 0);
$results = DB::select(
'SELECT id, name FROM products WHERE price >= :min AND category = :cat',
['min' => $min, 'cat' => $request->query('category')]
);
Equally, be wary of orderByRaw, groupByRaw, and selectRaw. They are powerful, but PDO cannot parameterise identifiers inside them. If you pass anything user-controlled into these methods, it must be whitelisted first. As a rule of thumb, never pass request data directly into any *Raw method. Precompute safe fragments on the server, or construct them entirely from constants and whitelisted tokens.
At the model layer, guard against mass assignment pitfalls that can become a backdoor into sensitive columns. Use $fillable to declare the attributes that may be bulk-assigned, or $guarded set to [] only when you are absolutely certain that all columns are safe for mass assignment (rare in real systems). Casting with $casts also limits surprises by ensuring that numbers are numbers and dates are dates before they hit your queries:
class User extends Model
{
protected $fillable = ['name', 'email', 'status'];
protected $casts = [
'email_verified_at' => 'datetime',
'is_admin' => 'boolean',
];
}
Database credentials and privileges play a quiet but essential role. Use least privilege for the application’s database user—typically read/write on the application schema, but no DDL rights in production. Keep migration privileges in a separate user that only runs during deployment, not through the web app. When the inevitable code bug slips through, limited privileges can turn a catastrophic breach into a contained incident.
Quick wins for preventing SQL injection in Laravel:
In more advanced setups, consider query objects or repositories that centralise all SQL boundaries. Such layers give you a single place to enforce whitelists, parameter binding and auditing. They also make it easier to write unit tests that feed gnarly edge cases into your query builders without touching controllers or views. The act of isolating data access tends to surface unsafe patterns early, before they reach production traffic.
Finally, never confuse obscurity for security. Hiding stack traces, renaming tables or base64-encoding identifiers doesn’t stop an attacker who can influence query structure. Focus on strong parameterisation, strict identifier control, and clean separation of concerns. That is what keeps injections out of your logs—and your weekend free from incident calls.
If SQL injection is about what you send to the database, XSS is about what you send to the browser. Laravel defaults tilt in your favour, but XSS is a game of context. How you render a string determines whether it is inert text or live script. Your job is to ensure that every untrusted value is escaped correctly for the context in which it appears.
Blade’s {{ $value }} escapes HTML by default. That means characters like <, >, & and quotes are encoded so the browser treats them as text. Reserve {!! $value !!} for data you have deliberately sanitised and intend to render as HTML (e.g., a CMS page body). Even then, “sanitize then trust” requires a proper HTML sanitiser, not a home-built regex. If in doubt, render as text. It is remarkable how many XSS incidents begin with a misplaced pair of exclamation marks.
Context is everything. Escaping for element content is not the same as escaping for attributes, URLs or JavaScript literals. When you inject server values into JavaScript, never concatenate them into <script> tags. Use @json($value) to produce a valid, escaped JSON literal that the browser will treat as data, not code:
<script>
window.appConfig = @json([
'name' => config('app.name'),
'csrfToken' => csrf_token(),
'user' => ['id' => auth()->id()],
]);
</script>
For attributes like href, src and data-*, {{ }} escaping is usually sufficient, but you should also validate the shape of the value server-side. For example, only allow https URLs for href, or constrain to relative paths. Never dump arbitrary HTML from untrusted users into event handler attributes (e.g., onclick=”{{ $value }}”), and avoid inline event attributes entirely; modern frameworks and AlpineJS-style directives make them unnecessary.
A robust Content Security Policy (CSP) acts as a seatbelt when something slips through. CSP lets you say, “Only execute scripts I explicitly allow.” The simplest and strongest pattern is a nonce-based policy that allows scripts with a server-generated random nonce, and blocks inline scripts without it. You can add such a header with a small middleware:
// App/Http/Middleware/ContentSecurityPolicy.php
namespace App\Http\Middleware;
use Closure;
use Illuminate\Http\Request;
use Illuminate\Support\Str;
class ContentSecurityPolicy
{
public function handle(Request $request, Closure $next)
{
$nonce = base64_encode(random_bytes(16));
app()->instance('csp-nonce', $nonce);
$response = $next($request);
$policy = "default-src 'self'; script-src 'self' 'nonce-{$nonce}' 'strict-dynamic'; " .
"style-src 'self' 'unsafe-inline'; img-src 'self' data:; object-src 'none'; " .
"base-uri 'self'; frame-ancestors 'self';";
$response->headers->set('Content-Security-Policy', $policy);
return $response;
}
}
Then in Blade, apply the nonce to any inline scripts you must keep:
<script nonce="{{ app('csp-nonce') }}">
// minimal inline script, if absolutely necessary
</script>
Sanitising rich text is the one place where output escaping alone is not enough. If you intentionally allow users to submit HTML (e.g., blog posts, comments with limited formatting), run it through a battle-tested HTML sanitiser during ingestion or just before render. Configure an allowlist: tags like <p>, <strong>, <em>, <a href>, <ul>, <li>, and no <script>, <iframe>, or event attributes. Do not rely on strip_tags() as your only measure; it is far too blunt and misses tricky attributes and URI schemes.
XSS hardening checklist for Laravel views and APIs:
Whilst SSR and Blade are common in Laravel, many teams use Inertia, Livewire or SPAs with Vue/React. The same principles apply: data passed from PHP to the frontend must be treated as untrusted until it is escaped for the right context. With Inertia, for example, the server returns JSON; the client framework then renders components. Keep that JSON purely data-shaped and let the client insert it via bindings that escape by default. Avoid rendering raw HTML directly into the DOM via v-html or dangerouslySetInnerHTML unless it has been sanitised.
Finally, remember that XSS often piggybacks on seemingly benign features: file previews that echo filenames into alt attributes; toasts that display server messages; search pages that echo the query at the top; admin dashboards that render third-party analytics snippets. Each of these must be audited with the same discipline. Treat every edge between server data and the DOM as a potential context mismatch, and choose the safe primitive for that context.
Your safest database and view layer can still be undone by the messy world of incoming data. This is where Laravel’s validation, form requests and storage layer shine. Use them deliberately and you eliminate entire classes of injection and XSS issues without thinking about them again.
Begin with validation. Always validate close to the controller edge, and prefer Form Request classes over inline validate() calls once forms become non-trivial. Validation converts untrusted, free-form input into a well-shaped payload. It also gives you a natural place to normalise data, such as trimming strings, lower-casing e-mails, or restricting enumerations. For anything that later influences query shape—sort keys, filters, search modes—prefer in: rules that force values onto a whitelist:
// app/Http/Requests/StoreUserRequest.php
public function rules(): array
{
return [
'name' => ['required', 'string', 'max:120'],
'email' => ['required', 'email:rfc,dns', 'max:255'],
'status' => ['required', 'in:active,pending,suspended'],
'sort' => ['nullable', 'in:name,joined,status'],
'direction' => ['nullable', 'in:asc,desc'],
];
}
Guard sessions and forms with CSRF protection. Laravel injects a CSRF token automatically into @csrf Blade directives in forms, and verifies it on POST/PUT/PATCH/DELETE. XSS attacks often aim to steal CSRF tokens to mint authorised requests, so combine CSRF with HttpOnly cookies for the session and set SameSite=Lax or Strict (configured in config/session.php). HttpOnly stops scripts from reading cookies; SameSite reduces cross-origin request leakage.
File uploads deserve special attention because they bridge input, storage and output. Use Storage::putFile or store on uploaded files to generate safe, randomised filenames; never use the user-supplied file name as the final path. Validate MIME types and size limits (mimes:jpg,png,pdf or mimetypes:image/jpeg,image/png,application/pdf), and store uploads outside the web root when possible. When serving files back, stream them through a controller with response()->file() or response()->download() and set the Content-Type explicitly; do not let the browser guess. Rendering user-uploaded images in <img> tags is fine; rendering user-uploaded HTML is not.
When you need rich text input, shape both ends: validate an expected subset of tags, sanitise on save, and escape on render anyway. Many teams keep both the raw and sanitised version of content: raw for audit, sanitised for delivery. If you ever change sanitiser configuration, you can re-sanitise from the raw source without losing history.
Lastly, consider your error handling as part of validation hygiene. Validation errors should never echo user input back into raw HTML without escaping. Blade’s old() helper and error bag are already safe, but custom error renderers and client-side validation bridges can accidentally render unescaped strings. Keep the default patterns and you avoid that footgun entirely.
Prevention is the headline, but detection and response are what give you real-world resilience. Assume that someday, somewhere, a pull request will sneak in a raw query or a dangerous template. If you’ve layered monitoring, automated tests and clear incident drills, that mistake becomes a minor blip rather than a reputational crisis.
Start in CI with automated tests that target security assumptions. Feature tests can probe unsafe paths with payloads designed to break out of their intended contexts. For SQL injection, assert that search pages, filters and sort parameters do not cause exceptions and return reasonable results when fed with classic payloads like ‘ OR 1=1 — or ‘) UNION SELECT …. You are not trying to execute a real injection here—PDO will block it—but you’re verifying that your code paths stay inside the safe APIs and do not crash or leak stack traces. For XSS, craft tests that submit HTML/JS payloads to comment forms and then fetch the rendered page, asserting that the payload is escaped. This is especially effective when combined with a headless browser test that loads the page and checks that script tags are not present where they shouldn’t be.
Static analysis helps you police patterns at scale. Tools that scan for DB::raw, orderByRaw, {!! in Blade, v-html in Vue components or dangerouslySetInnerHTML in React code can fail builds when risky calls appear outside approved modules. Treat these as guardrails rather than absolute bans. Sometimes you will need selectRaw for performance; you’ll simply wrap it in a repository function that never accepts untrusted input and add comments explaining the safety case. The point is to make risky patterns visible and reviewable.
Runtime monitoring picks up what CI misses. Application logs should record unusual SQL errors, blocked requests, and CSP violation reports. Browsers can be configured to send CSP violation reports to an endpoint you control; aggregate and alert on these so that you see when a third-party script or a new component tries to run inline code without a nonce. At the server layer, web application firewalls can provide a defence-in-depth layer, flagging known injection patterns. Be careful with WAFs, though; they are not a substitute for proper escaping and parameterisation, and over-zealous rules can block legitimate traffic. Use them as sensors and last-ditch brakes, not your primary steering.
Incident response is where your culture shows. When you discover a potential injection or XSS vulnerability, immediately create a private incident channel with a single source of truth. Triage impact: which routes, parameters and roles are affected? Can the issue be exploited without authentication? If script execution is possible, treat any exposed session as suspect. Invalidate sessions en masse if necessary, rotate API keys and database credentials, and patch the code with the smallest safe change first (e.g., switch {!! to {{ }}, add a missing @csrf, or replace a raw query with a bound one). Once the bleeding stops, write a post-mortem: root cause, contributory factors, detection gaps, and one or two systemic changes that would have prevented the bug. Resist the urge to stack dozens of action items; choose the few that change behaviour.
Finally, build knowledge into onboarding and code review. New joiners should see examples of safe and unsafe patterns, understand why {!! is a footgun, and know where to find your whitelist maps for sorting and filtering. Code reviews should call out context-mismatch risks (“this value is used in an attribute—are we validating its shape?”) and query risks (“are we mapping this sort key to a safe column?”). It’s not pedantry; it’s the engineering habit that makes security feel routine rather than theatrical.
Think of SQL injection and XSS as two sides of one principle: always be explicit about trust and context. Laravel rewards that discipline. On the database side, Eloquent and the Query Builder give you parameter binding by default; use it everywhere, and whitelist any identifier you cannot parameterise. On the browser side, Blade escapes by default; keep it that way, and only render HTML you have deliberately sanitised. Wrap both halves with strong validation, CSRF protection, cautious file handling, and session cookie settings that prefer security over convenience.
CSP, when adopted with nonces, gives you a safety net that catches many edge cases before they become incidents. Monitoring and CI tests convert unknown unknowns into known issues you can fix in hours rather than days. Least-privilege database users limit blast radius. And a calm, practised incident drill ensures that when something does go wrong, your team moves quickly and communicates clearly.
A Laravel development company that lives these habits doesn’t merely “pass a pen test”. It ships features with confidence, on a platform designed to make the safe path the easy path. That reputation—of careful defaults, pragmatic controls and respectful handling of user data—is itself a competitive advantage. Keep the playbook close, keep your patterns boring, and your users will never notice the bullets you dodged on their behalf.
Is your team looking for help with Laravel development? Click the button below.
Get in touch