Practical Complete Guide: Laravel Security Design — From CSRF, XSS, SQL Injection, Authentication and Authorization, Rate Limiting, Audit Logs, to Accessible Error Display

greeden

hace 3 horas

Practical Complete Guide: Laravel Security Design — From CSRF, XSS, SQL Injection, Authentication and Authorization, Rate Limiting, Audit Logs, to Accessible Error Display

What You Will Learn in This Article

Basic security measures you should understand in Laravel
How to prevent CSRF, XSS, SQL injection, Mass Assignment, and authorization gaps
How to design authentication, passwords, sessions, and login attempt limits
Key points for file uploads, APIs, webhooks, and external integrations
How to think about security logs, audit logs, alerts, and incident response
Accessibility design for communicating errors and warnings clearly to everyone

Target Readers

Beginner to intermediate Laravel engineers who can build basic features but feel uncertain about security before production release
Tech leads who want to establish security review standards within their teams
QA and maintenance staff who want to detect vulnerabilities and permission leaks early through testing and operations
Designers, customer support, and accessibility staff who want to make errors and warnings easier for users to understand calmly

Accessibility Level: ★★★★★
Security features often involve “restriction,” “denial,” and “re-entry” for users. That is why it is important not to communicate 403, 419, 429, validation errors, login failures, and similar states only through color or technical terms. This article covers role="alert", role="status", error summaries, specific link text, and guidance that makes the next action clear.

1. Introduction: Laravel Has a Secure Foundation, but Incorrect Use Can Be Dangerous

Laravel includes many security features needed for web applications, such as CSRF protection, validation, authentication, authorization, hashing, encryption, and rate limiting. This is a major strength. However, the scope protected by the framework and the scope developers must design for are different.

For example, Blade’s {{ }} basically escapes output, but careless use of {!! !!} can create XSS risks. Eloquent and the query builder make it easier to avoid SQL injection, but building raw SQL through string concatenation is dangerous. Even if authentication exists, forgetting authorization checks in controllers may allow users to see data they should not be able to access.

In other words, Laravel security depends on both “using standard features correctly” and “closing application-specific risks through design.” This article explains the basics beginners should understand first, then moves through areas that often cause real-world incidents: permissions, files, APIs, audit logs, and error display.

2. Production Settings to Check First: `APP_DEBUG=false` and `.env` Management

The first step in security is environment configuration, even before code. In production, make sure to check the following.

APP_ENV=production
APP_DEBUG=false
APP_KEY=base64:...
APP_URL=https://example.com

If you publish to production with APP_DEBUG=true, stack traces, file paths, and parts of configuration values may be displayed when exceptions occur. This is very dangerous because it gives attackers clues.

As a rule, .env should not be included in Git management. Put only key names in .env.example, and manage real values through the server environment or CI/CD secrets.
Be especially careful not to display the following information in logs or screens:

Database usernames and passwords
API keys
Mail service credentials
Payment service secret keys
Encryption keys
OAuth client secrets

Environment configuration may seem plain, but incidents in this area can have a major impact. It is safer to decide team rules early.

3. CSRF Protection: Always Include `@csrf` in Forms

CSRF is an attack that causes a logged-in user to perform unintended actions. Laravel provides standard CSRF protection for form submissions in web routes.

Always include @csrf in forms.

<form method="POST" action="{{ route('profile.update') }}">
    @csrf
    @method('PATCH')

    <label for="name">Name</label>
    <input id="name" name="name" type="text" value="{{ old('name', $user->name) }}">

    <button type="submit">Update</button>
</form>

For state-changing requests such as POST, PUT, PATCH, and DELETE, requests without a CSRF token are rejected.
Conversely, avoid designs that change data with GET requests. For example, the following URL is dangerous.

GET /users/123/delete

Deletion and updates should always be implemented with appropriate HTTP methods such as POST, PATCH, or DELETE.

4. XSS Protection: Trust Blade Escaping and Avoid Dangerous Output

XSS is an attack in which malicious scripts are embedded into a page. In Laravel Blade, normal {{ }} output is escaped.

<p>{{ $comment->body }}</p>

With this writing style, even if a user enters <script>, it is less likely to be executed as HTML.

On the other hand, output like the following requires caution.

{!! $comment->body !!}

{!! !!} outputs HTML without escaping it. It is dangerous when used with untrusted user input.
If you absolutely need to allow HTML, consider restricting allowed tags or sanitizing HTML.

4.1 Be Careful with Attribute Values

<a href="{{ $url }}">Link</a>

If a URL is generated from user input, validation is necessary to prevent dangerous schemes such as javascript: from being mixed in.
URL validation and allowed-domain restrictions can improve safety.

5. SQL Injection Protection: Use Eloquent and the Query Builder by Default

SQL injection is an attack that causes input values to be interpreted as SQL. In Laravel, using Eloquent or the query builder safely binds values in many cases.

Safe example:

$users = User::where('email', $request->input('email'))->get();

Dangerous example:

$email = $request->input('email');

$users = DB::select("SELECT * FROM users WHERE email = '$email'");

Avoid building SQL through string concatenation. If raw SQL is absolutely necessary, always use placeholders.

$users = DB::select(
    'SELECT * FROM users WHERE email = ?',
    [$request->input('email')]
);

Also be careful when receiving sort columns or search target columns directly from requests.
Prepare an allowlist as shown below.

$allowedSorts = ['name', 'created_at', 'email'];

$sort = in_array($request->input('sort'), $allowedSorts, true)
    ? $request->input('sort')
    : 'created_at';

$users = User::orderBy($sort)->paginate(20);

It is important to validate not only values, but also column names and directions.

6. Validation: The Basic Rule Is “Do Not Trust Input”

The foundation of security is not trusting user input. In Laravel, FormRequest helps organize input validation.

php artisan make:request StorePostRequest

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class StorePostRequest extends FormRequest
{
    public function rules(): array
    {
        return [
            'title' => ['required', 'string', 'max:100'],
            'body' => ['required', 'string', 'max:5000'],
            'status' => ['required', 'in:draft,published'],
        ];
    }

    public function attributes(): array
    {
        return [
            'title' => 'Title',
            'body' => 'Body',
            'status' => 'Publication Status',
        ];
    }
}

In the controller, use only validated data.

public function store(StorePostRequest $request)
{
    $post = Post::create($request->validated());

    return redirect()
        ->route('posts.show', $post)
        ->with('status', 'Post created.');
}

Validation is not just for displaying errors.
It is an important defensive layer that stops invalid types, overly long strings, disallowed values, and unintended array structures early.

7. Mass Assignment Protection: Explicitly Define `$fillable`

In Laravel, you can pass arrays to create() or update() for mass assignment. This is convenient, but dangerous if unintended fields are updated.

Dangerous example:

$user->update($request->all());

If the request contains is_admin=1, depending on the configuration, this could lead to privilege escalation.

In the model, explicitly define assignable fields with $fillable.

class User extends Model
{
    protected $fillable = [
        'name',
        'email',
    ];
}

Also use validated() in the controller.

$user->update($request->validated());

Using both $fillable and FormRequest greatly reduces unintended updates.

8. Authentication: Handle Passwords, Login Attempts, and Sessions Carefully

Authentication is the mechanism for confirming identity. Laravel Starter Kits and authentication features allow you to safely start with basic login, registration, and password reset.

When storing passwords, always hash them.

use Illuminate\Support\Facades\Hash;

$user = User::create([
    'name' => $request->name,
    'email' => $request->email,
    'password' => Hash::make($request->password),
]);

Add rate limiting to login attempts. If you use a Starter Kit, login attempt limits may already be included, but if you implement authentication yourself, make sure to check.

Route::post('/login', [LoginController::class, 'store'])
    ->middleware('throttle:10,1');

Be careful with wording when login fails.
If you display “This email address does not exist,” it may be used to check whether a user exists.
A safer message is:

The email address or password is incorrect.

9. Authorization: Being Logged In Does Not Mean a User Can Do Anything

Authentication and authorization are different.
Authentication confirms “who the person is.”
Authorization determines “whether that person may perform this action.”

In Laravel, Policies help organize permissions for each model.

php artisan make:policy PostPolicy --model=Post

namespace App\Policies;

use App\Models\Post;
use App\Models\User;

class PostPolicy
{
    public function update(User $user, Post $post): bool
    {
        return $user->id === $post->user_id;
    }

    public function delete(User $user, Post $post): bool
    {
        return $user->id === $post->user_id;
    }
}

Always call authorize() in the controller.

public function update(UpdatePostRequest $request, Post $post)
{
    $this->authorize('update', $post);

    $post->update($request->validated());

    return redirect()
        ->route('posts.show', $post)
        ->with('status', 'Post updated.');
}

Hiding buttons on the screen is not enough.

@can('update', $post)
    <a href="{{ route('posts.edit', $post) }}">Edit</a>
@endcan

Use @can to improve the experience, and enforce final protection with server-side authorize().

10. 403 Pages: When Denying Access, Explain Clearly

When authorization fails, Laravel returns 403.
If this page only says “Forbidden,” users do not know what to do.

Recommended wording:

You do not have permission to perform this action.
If necessary, please contact an administrator to request permission.

Example of an accessible error page:

<main aria-labelledby="error-title">
    <h1 id="error-title" tabindex="-1">You do not have permission to perform this action</h1>

    <p>
        Your current account is not allowed to view or operate this page.
    </p>

    <ul>
        <li><a href="{{ route('dashboard') }}">Return to dashboard</a></li>
        <li><a href="{{ route('support') }}">Contact support</a></li>
    </ul>
</main>

It is important not only to deny access, but also to show the next action.

11. 419 Pages: Do Not Blame Users for Session Expiration

A 419 may be returned when the CSRF token does not match or the session expires.
If you only display “Invalid operation,” users may feel blamed.

Recommended wording:

This page has expired because there was no activity for a while.
Please try the operation again.

If form input may be lost, consider draft saving or input restoration.
Security and user experience are not opposites. Clear explanations alone can greatly reduce inquiries and anxiety.

12. Rate Limiting: Protect Login, Search, APIs, and Contact Forms

Rate limiting prevents large numbers of requests from being sent in a short period of time.
It is effective for login, password reset, contact forms, APIs, search, and similar features.

Route::post('/contact', [ContactController::class, 'store'])
    ->middleware('throttle:5,1');

This means up to 5 times per minute.

For APIs, consider separating limits by user ID or IP address.
When a user hits a rate limit, return 429 and explain it as follows:

Too many operations were performed in a short time.
Please wait a little and try again.

Here too, it is important to briefly explain what the user should do, rather than relying only on technical terms.

13. File Uploads: Check MIME, Size, Storage Location, and Public Scope

File upload is an area where security incidents easily occur.
Always check the following:

Allowed MIME types
Maximum size
Whether the storage location is public or private
Do not use the original file name as-is
Consider removing EXIF data for images
Run virus scanning when necessary
Check authorization at download time

Validation example:

$request->validate([
    'avatar' => [
        'nullable',
        'file',
        'mimetypes:image/jpeg,image/png,image/webp',
        'max:2048',
    ],
]);

Use a random stored name.

$path = $request->file('avatar')->store('avatars', 'private');

Manage files that can be public separately from files that only authenticated users can see.
When distributing private files, perform authorization checks in the controller before returning them.

public function download(Document $document)
{
    $this->authorize('view', $document);

    return Storage::disk('private')->download($document->path);
}

14. API Security: Align Authentication, Authorization, Scopes, and Error Format

In APIs, response consistency is even more important than in screens.
Even when using Sanctum or similar tools, do not rely only on authentication. Always confirm authorization for each operation.

Route::middleware('auth:sanctum')->get('/user', function (Request $request) {
    return $request->user();
});

If you attach abilities to tokens, keep them to the minimum necessary.

$token = $user->createToken('api-token', ['orders:read'])->plainTextToken;

Standardize API errors into a format that the frontend can handle easily.

{
  "message": "You do not have permission to perform this action.",
  "code": "forbidden"
}

Validation errors should also be linked clearly to input fields.

{
  "message": "Please check your input.",
  "errors": {
    "email": [
      "Email address is required."
    ]
  }
}

This allows the screen side to implement error summaries and field-level error displays consistently.

15. Webhooks: Add Signature Verification and Replay Protection

When receiving webhooks from external services, do not trust incoming requests as-is.
At minimum, check the following:

Signature verification
Timestamp verification
Prevention of duplicate processing for the same event ID
Pass processing to a job after receipt and respond quickly
Record event ID and result in logs

Conceptual example of signature verification:

$payload = $request->getContent();
$timestamp = $request->header('X-Webhook-Timestamp');
$signature = $request->header('X-Webhook-Signature');

abort_if(abs(time() - (int) $timestamp) > 300, 401);

$expected = hash_hmac(
    'sha256',
    $timestamp . '.' . $payload,
    config('services.webhook.secret')
);

abort_unless(hash_equals($expected, $signature), 401);

Also prevent duplicate processing of the same event.

$eventId = $request->input('id');

if (! Cache::add("webhook:event:{$eventId}", true, 3600)) {
    return response()->json(['status' => 'already_processed']);
}

HandleWebhookEvent::dispatch($request->all());

Webhooks depend heavily on external services, so it is safer to define retry and reprocessing procedures for failures.

16. Security Headers: Protect from Outside the Application Too

You can strengthen defenses not only with Laravel code, but also with HTTP response headers.
Representative examples include:

Content-Security-Policy
X-Content-Type-Options: nosniff
X-Frame-Options or CSP frame-ancestors
Referrer-Policy
Strict-Transport-Security

CSP is especially powerful, but it can affect existing JavaScript and external tags, so gradual introduction is recommended.
It is safer to start in report mode, observe the impact, and then enforce it in production.

17. Logs and Audits: Security Also Depends on Being Traceable Later

When a security incident or suspicious operation occurs, investigation is impossible without logs.
For important operations, it is safer to keep audit logs separately from normal logs.

Items to record in audit logs:

User ID of the actor
Target ID
Action
Before / after changes
IP address
User-Agent
trace_id
Execution timestamp

Example:

AuditLog::create([
    'actor_user_id' => auth()->id(),
    'action' => 'user.role.updated',
    'target_type' => User::class,
    'target_id' => $user->id,
    'before' => ['role' => $beforeRole],
    'after' => ['role' => $user->role],
    'ip' => request()->ip(),
    'user_agent' => request()->userAgent(),
]);

However, avoid putting too much personal or secret information in logs.
Tokens, passwords, card information, and similar data should never be recorded in logs.

18. Dependency Packages: Update and Check Regularly

Laravel applications depend on Composer packages and npm packages.
Even if the application itself is safe, vulnerabilities in dependencies can be dangerous.

Operational tasks include:

Running composer audit
Checking npm package vulnerabilities
Defining update policies for Laravel itself and major packages
Removing unused packages
Running vulnerability checks in CI

Updates are not something to fear; leaving vulnerabilities unattended can be more dangerous.
However, do not apply them suddenly to production. Test them in staging first.

19. Security Testing: Prevent Permission Leaks with Feature Tests

Security should not be protected only by reviews; it should also be fixed through tests.
Authorization is especially valuable to test with Feature tests.

public function test_user_cannot_update_other_users_post()
{
    $user = User::factory()->create();
    $other = User::factory()->create();

    $post = Post::factory()->create([
        'user_id' => $other->id,
    ]);

    $this->actingAs($user);

    $this->patch(route('posts.update', $post), [
        'title' => 'Unauthorized update',
        'body' => 'Body',
    ])->assertForbidden();

    $this->assertDatabaseMissing('posts', [
        'id' => $post->id,
        'title' => 'Unauthorized update',
    ]);
}

For APIs, also check 403 and 401 responses.

public function test_api_requires_authentication()
{
    $this->getJson('/api/orders')
        ->assertUnauthorized();
}

A single authorization gap can lead to a major incident.
Start adding tests from important screens first.

20. Accessible Security UI: Communicate Denials, Warnings, and Failures Carefully

Security measures often create moments where users feel “I cannot do this,” “I was stopped,” or “I have to enter it again.”
That is why UI communication matters.

20.1 Error Summary

@if ($errors->any())
    <div id="error-summary" role="alert" tabindex="-1" class="border p-3 mb-4">
        <h2>Please check your input.</h2>
        <ul>
            @foreach ($errors->all() as $error)
                <li>{{ $error }}</li>
            @endforeach
        </ul>
    </div>
@endif

20.2 Linking Errors to Input Fields

<label for="email">Email Address</label>
<input
    id="email"
    name="email"
    type="email"
    value="{{ old('email') }}"
    aria-invalid="{{ $errors->has('email') ? 'true' : 'false' }}"
    aria-describedby="{{ $errors->has('email') ? 'email-error' : 'email-help' }}"
>

<p id="email-help">Example: hanako@example.com</p>

@error('email')
    <p id="email-error">{{ $message }}</p>
@enderror

20.3 Wording on Failure

Wording to avoid:

Invalid operation.

Improved example:

This page has expired.
Please log in again and try the operation once more.

The more serious the denial or warning, the more important it is to use wording that helps users calmly move to the next action.

21. Common Pitfalls and How to Avoid Them

21.1 Thinking Authorization Is Done Just Because a Button Is Hidden

@can is display control.
Always use authorize() at execution time.

21.2 Saving `request()->all()` As-Is

Unintended fields may be saved.
Use FormRequest and $fillable.

21.3 Using `{!! !!}` Carelessly

Using it with user input creates XSS risk.
Normally, use {{ }}.

21.4 Building Raw SQL with String Concatenation

This creates SQL injection risk.
Use Eloquent, the query builder, or placeholders.

21.5 Unhelpful 403 and 419 Pages

Users do not know what to do.
Clearly show the next action.

21.6 Logging Secret Information

Do not log tokens, passwords, or card information.
Mask them if absolutely necessary.

22. Checklist for Distribution

Environment Configuration

[ ] APP_DEBUG=false in production
[ ] .env is not managed in Git
[ ] Secret information is not displayed in logs or screens

Input and Output

[ ] Input is validated with FormRequest
[ ] Blade basically uses {{ }}
[ ] Uses of {!! !!} are reviewed
[ ] Raw SQL uses placeholders

Authentication and Authorization

[ ] Passwords are stored with Hash::make()
[ ] Login attempts are rate-limited
[ ] Policy / Gate is used
[ ] Controllers call authorize()

Files and APIs

[ ] File MIME type and size are validated
[ ] Private files are distributed only after authorization
[ ] API authentication and authorization are checked separately
[ ] Webhooks have signature verification

Operations

[ ] Important operations have audit logs
[ ] Dependency vulnerabilities are checked
[ ] Security tests are included in Feature tests

Accessibility

[ ] There is an error summary
[ ] Input errors are linked with aria-describedby
[ ] Explanations for 403 / 419 / 429 are easy to understand
[ ] Warnings and failures are not indicated by color alone

23. Conclusion

Laravel is a framework with a strong foundation for security. However, safety is not completed automatically. For risks such as CSRF, XSS, SQL injection, Mass Assignment, authorization gaps, file uploads, APIs, and webhooks, Laravel’s features must be used correctly.

First, reliably set up APP_DEBUG=false, FormRequest, @csrf, Blade escaping, Policy, $fillable, and rate limiting. Then expand to files, APIs, audit logs, and dependency management to move closer to production-ready security.

Security UI is not for rejecting users, but for helping them proceed with confidence to the next action. Errors and warnings should be short, specific, and accessible. By combining technical defenses with clear guidance, you can grow your Laravel application into one that is safe and trusted.

Practical Complete Guide: Laravel Security Design — From CSRF, XSS, SQL Injection, Authentication and Authorization, Rate Limiting, Audit Logs, to Accessible Error Display

1. Introduction: Laravel Has a Secure Foundation, but Incorrect Use Can Be Dangerous

2. Production Settings to Check First: APP_DEBUG=false and .env Management

3. CSRF Protection: Always Include @csrf in Forms

4. XSS Protection: Trust Blade Escaping and Avoid Dangerous Output

4.1 Be Careful with Attribute Values

5. SQL Injection Protection: Use Eloquent and the Query Builder by Default

6. Validation: The Basic Rule Is “Do Not Trust Input”

7. Mass Assignment Protection: Explicitly Define $fillable

8. Authentication: Handle Passwords, Login Attempts, and Sessions Carefully

9. Authorization: Being Logged In Does Not Mean a User Can Do Anything

10. 403 Pages: When Denying Access, Explain Clearly

11. 419 Pages: Do Not Blame Users for Session Expiration

12. Rate Limiting: Protect Login, Search, APIs, and Contact Forms

13. File Uploads: Check MIME, Size, Storage Location, and Public Scope

14. API Security: Align Authentication, Authorization, Scopes, and Error Format

15. Webhooks: Add Signature Verification and Replay Protection

16. Security Headers: Protect from Outside the Application Too

17. Logs and Audits: Security Also Depends on Being Traceable Later

18. Dependency Packages: Update and Check Regularly

19. Security Testing: Prevent Permission Leaks with Feature Tests

20. Accessible Security UI: Communicate Denials, Warnings, and Failures Carefully

20.1 Error Summary

20.2 Linking Errors to Input Fields

20.3 Wording on Failure

21. Common Pitfalls and How to Avoid Them

21.1 Thinking Authorization Is Done Just Because a Button Is Hidden

21.2 Saving request()->all() As-Is

21.3 Using {!! !!} Carelessly

21.4 Building Raw SQL with String Concatenation

21.5 Unhelpful 403 and 419 Pages

21.6 Logging Secret Information

22. Checklist for Distribution

23. Conclusion

Reference Links

Comparte esto:

2. Production Settings to Check First: `APP_DEBUG=false` and `.env` Management

3. CSRF Protection: Always Include `@csrf` in Forms

7. Mass Assignment Protection: Explicitly Define `$fillable`

21.2 Saving `request()->all()` As-Is

21.3 Using `{!! !!}` Carelessly