Laravel API absichern Rate Limiting & Security in der Praxis

Wir haben in den letzten 13 Kapiteln ein absolutes Monster von einer Web-Applikation erschaffen. Unser Next.js-Frontend liefert dank React Server Components blitzschnelles HTML aus. Unser Laravel-Backend nutzt Redis aus dem flüchtigen Arbeitsspeicher, um langsame Datenbank-Abfragen komplett zu umgehen. Und schwere Aufgaben wie Bildkomprimierung oder Newsletter-Versand haben wir elegant in asynchrone Queues verlagert. Deine Schnittstelle ist jetzt eine Hochleistungsmaschine, die in wenigen Millisekunden antwortet.

Aber genau hier lauert die Gefahr im freien Internet. Beim Thema Laravel API absichern Rate Limiting zu ignorieren, wäre ein fataler Fehler für jede moderne Architektur. Eine API, die so unfassbar schnell antwortet und ungeschützt ist, ist nämlich ein gefundenes Fressen für automatisierte Skripte, bösartige Bots und Scraping-Tools.

Der unsichtbare Feind: Warum Geschwindigkeit gefährlich sein kann

Stell dir vor, ein Angreifer entdeckt den API-Endpunkt, über den wir in Teil 11 unsere Kommentare speichern (POST /api/comments). Da unser Server so schnell antwortet, schreibt der Angreifer ein simples Python-Skript, das diesen Endpunkt in einer Endlosschleife aufruft.

Plötzlich prasseln nicht mehr 10, sondern 10.000 Kommentare pro Sekunde auf deine Laravel-API ein.

Was passiert in unserer aktuellen Architektur?

1. Laravel nimmt jeden einzelnen dieser 10.000 Requests freudig entgegen.

2. Für jeden Request wird ein neuer Spam-Kommentar in die Datenbank geschrieben.

3. Für jeden Request feuert unser Observer ein Cache::forget(), um den Redis-Cache zu leeren.

4. Für jeden Request generiert Laravel einen neuen Job in der Queue, falls wir E-Mail-Benachrichtigungen für neue Kommentare aktiviert haben.

Deine Infrastruktur funktioniert exakt so, wie wir sie programmiert haben – sie arbeitet die Anfragen blitzschnell ab. Aber die rohe Masse an bösartigem Traffic wird deinen Redis-Speicher überlaufen lassen, deine Queue verstopfen und deine Datenbank-Festplatte an ihr absolutes Limit treiben. Am Ende stürzt dein Server ab, weil wir ihm nicht beigebracht haben, wann er einfach mal "Nein" sagen muss.

Wir haben ein fantastisches Haus gebaut, aber wir haben vergessen, eine Tür mit einem intelligenten Türsteher einzubauen. Jeder darf aktuell hereinspazieren, so oft er will.

Das ändern wir heute. Wir härten unser System ab und verwandeln es in eine Festung. Wir widmen uns dem Rate Limiting (der Drosselung von Anfragen) und den essenziellen Security-Headern, die deine Laravel-API kugelsicher machen.

Der eiserne Türsteher: Rate Limiting in Laravel

Um unsere API vor dem Zusammenbruch zu bewahren, greifen wir auf ein Konzept zurück, das in der Enterprise-Welt absoluter Standard ist: Rate Limiting (zu Deutsch etwa "Ratenbegrenzung" oder "Drosselung").

Das Prinzip ist simpel: Wir stellen einen unsichtbaren Türsteher vor unsere API-Endpunkte. Dieser Türsteher merkt sich die IP-Adresse jedes Besuchers und zählt mit, wie oft diese IP in einem bestimmten Zeitfenster anklopft. Wenn ein normaler Nutzer einen Kommentar schreibt, winkt der Türsteher ihn freundlich durch. Wenn aber ein Skript versucht, 50 Kommentare in einer einzigen Minute abzusenden, fährt der Türsteher den Arm aus, blockiert den Request komplett und schickt dem Angreifer den gefürchteten HTTP-Statuscode 429 Too Many Requests zurück.

Das absolut Geniale daran: Laravel nutzt für das Zählen dieser Anfragen im Hintergrund standardmäßig deinen Cache. Da wir in Teil 12 unser gesamtes Caching auf den extrem schnellen In-Memory-Speicher Redis umgestellt haben, kostet dieser Türsteher deinen Server buchstäblich null Performance. Redis zählt die IP-Adressen atomar in Bruchteilen einer Millisekunde hoch.

Den Türsteher konfigurieren

In Laravel 11 und 12 definieren wir unsere maßgeschneiderten Rate Limiter zentral im AppServiceProvider. Öffne die Datei app/Providers/AppServiceProvider.php und erweitere die boot-Methode:

1<?php
2
3namespace App\Providers;
4
5use Illuminate\Cache\RateLimiting\Limit;
6use Illuminate\Http\Request;
7use Illuminate\Support\Facades\RateLimiter;
8use Illuminate\Support\ServiceProvider;
9
10class AppServiceProvider extends ServiceProvider
11{
12    public function register(): void
13    {
14        //
15    }
16
17    public function boot(): void
18    {
19        // 1. Der globale API-Türsteher (Oft schon standardmäßig von Laravel angelegt)
20        // Er erlaubt maximal 60 Anfragen pro Minute pro IP-Adresse für das allgemeine Surfen.
21        RateLimiter::for('api', function (Request $request) {
22            return Limit::perMinute(60)->by($request->user()?->id ?: $request->ip());
23        });
24
25        // 2. UNSER SPEZIAL-TÜRSTEHER FÜR KOMMENTARE!
26        // Wir sind hier extrem restriktiv: Niemand tippt schneller als 3 Kommentare pro Minute.
27        // Wenn eine IP mehr versucht, wird sie gnadenlos geblockt.
28        RateLimiter::for('comments', function (Request $request) {
29            return Limit::perMinute(3)->by($request->ip())->response(function (Request $request, array $headers) {
30                // Wir können sogar eine eigene, saubere JSON-Fehlermeldung für Next.js definieren
31                return response()->json([
32                    'message' => 'Wow, nicht so schnell! Bitte warte einen Moment, bevor du den nächsten Kommentar schreibst.',
33                ], 429, $headers);
34            });
35        });
36    }
37}

Schau dir an, wie elegant diese Syntax ist. Wir definieren einen Limiter namens comments und sagen klar: Maximal 3 Requests pro Minute, gebunden an die IP-Adresse ($request->ip()).

Den Türsteher vor die Tür stellen

Jetzt haben wir die Regeln definiert, aber wir müssen dem Türsteher noch sagen, an welcher Tür er eigentlich stehen soll. Dazu öffnen wir unsere Routing-Datei, in der unsere API-Endpunkte liegen (in Laravel 11/12 meist routes/api.php).

Wir weisen der Route für das Erstellen von Kommentaren einfach das throttle-Middleware zu und übergeben den Namen unseres Limiters:

1<?php
2
3use Illuminate\Support\Facades\Route;
4use App\Http\Controllers\CommentController;
5
6// ... andere Routen ...
7
8// Unser geschützter Endpunkt!
9Route::post('/comments', [CommentController::class, 'store'])
10    ->middleware('throttle:comments'); // HIER WIRD DER TÜRSTEHER AKTIVIERT

BÄM! Deine API ist an diesem kritischen Nadelöhr ab sofort kugelsicher.

Wenn du jetzt in dein Next.js-Frontend gehst und versuchst, wie ein Verrückter auf den "Kommentar senden"-Button zu klicken (selbst wenn du das Formular manipulierst, um Spam zu senden), wird beim vierten Klick Folgendes passieren: Der Laravel-Controller wird gar nicht erst aufgerufen. Keine Datenbank-Query, kein Spam-Filter, kein Queue-Job. Der Request prallt hart am Türsteher ab. Dein Next.js-Frontend erhält den 429-Fehler und kann dem Nutzer sauber anzeigen: "Wow, nicht so schnell!"

Deine Infrastruktur kann aufatmen. Der Angreifer verbrennt nur noch seine eigene Bandbreite, nicht mehr deine Server-Ressourcen.

Der rote Browser-Fehler: CORS endgültig besiegen

Wenn du schon einmal versucht hast, ein separates Frontend (wie React, Vue oder Next.js) mit einem Laravel-Backend zu verbinden, bist du mit einer 99-prozentigen Wahrscheinlichkeit über diesen absoluten Albtraum gestolpert. Du schickst einen sauberen Axios-Request ab, aber anstatt deiner Daten spuckt die Browser-Konsole einen riesigen, blutroten Fehler aus:

Blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Dieser Fehler hat schon unzählige Entwickler in den Wahnsinn (und zu StackOverflow) getrieben. Aber lass uns kurz verstehen, was hier eigentlich passiert. Der Fehler geht nicht von Laravel aus. Es ist dein eigener Browser (Chrome, Firefox, Safari), der dich hier extrem aggressiv beschützen will.

Das Web basiert auf der sogenannten Same-Origin Policy (Gleiche-Herkunft-Richtlinie). Das bedeutet: Ein Skript, das auf localhost:3000 (dein Next.js) geladen wurde, darf aus Sicherheitsgründen nicht einfach heimlich im Hintergrund mit localhost:8000 (dein Laravel) kommunizieren. Der Browser geht davon aus, dass das böswillig ist – es könnte ja ein bösartiges Skript sein, das versucht, Daten von deiner Online-Banking-API abzugreifen.

Um diese strikte Grenze kontrolliert zu öffnen, wurde CORS (Cross-Origin Resource Sharing) erfunden. Wenn Next.js bei Laravel anklopft, fragt der Browser zuerst bei Laravel nach: "Hey, hier ist jemand von localhost:3000. Darf der das?" Wenn Laravel diese Frage nicht mit einem lauten und deutlichen "Ja, der gehört zu mir!" (über spezielle HTTP-Header) beantwortet, blockiert der Browser die Antwort gnadenlos.

Die Festung hochziehen: CORS in Laravel konfigurieren

Viele Entwickler geraten bei CORS in Panik und installieren dubiose Browser-Erweiterungen oder setzen in Laravel einfach alle Zugriffsrechte auf den Platzhalter * (Jeder darf alles). Das ist in einer Produktionumgebung ein absoluter Sicherheits-Selbstmord. Deine API wäre für jede andere Webseite der Welt komplett offen!

Wir machen das jetzt wie echte Profis. In Laravel 11/12 ist das CORS-Handling bereits tief im Kern integriert, aber wir müssen die Konfigurationsdatei sichtbar machen, um sie perfekt auf unser Next.js-Frontend abzustimmen.

Öffne dein Terminal und veröffentliche die CORS-Konfiguration:

php artisan config:publish cors

Laravel erstellt nun die Datei config/cors.php. Öffne sie. Hier definieren wir die exakten Spielregeln für unsere holografische Brücke. Wir konfigurieren sie so, dass sie ausschließlich Anfragen von unserer Next.js-Domain akzeptiert.

1<?php
2
3return [
4
5    /*
6    |--------------------------------------------------------------------------
7    | Cross-Origin Resource Sharing (CORS) Configuration
8    |--------------------------------------------------------------------------
9    |
10    | Hier definieren wir, wer mit unserer API sprechen darf.
11    |
12    */
13
14    // Welche API-Routen sollen von den CORS-Regeln geschützt werden?
15    // Wir sagen: Alle Routen, die mit 'api/' beginnen, und später unsere Sanctum-Login-Routen.
16    'paths' => ['api/*', 'sanctum/csrf-cookie', 'login', 'logout'],
17
18    // Welche HTTP-Methoden sind erlaubt? (GET, POST, PUT, DELETE etc.)
19    // Wir erlauben alle Methoden von unserem eigenen Frontend.
20    'allowed_methods' => ['*'],
21
22    // DIE WICHTIGSTE ZEILE: Wer darf anfragen?
23    // NIEMALS '*' in Produktion nutzen! Wir holen uns die URL sicher aus der .env Datei.
24    'allowed_origins' => [env('FRONTEND_URL', 'http://localhost:3000')],
25
26    // Sollen Subdomains (Regex) erlaubt sein? (In unserem Fall nein)
27    'allowed_origins_patterns' => [],
28
29    // Welche Header darf das Next.js Frontend mitsenden?
30    'allowed_headers' => ['*'],
31
32    // Welche Header dürfen wir im Browser per JavaScript auslesen?
33    'exposed_headers' => [],
34
35    // Wie lange (in Sekunden) darf der Browser die "Erlaubnis" zwischenspeichern?
36    // Das spart uns bei jedem Request den sogenannten "Preflight"-Check (OPTIONS Request).
37    'max_age' => 0,
38
39    // EXTREM WICHTIG FÜR TEIL 15 (Authentifizierung):
40    // Wenn das Frontend Cookies (z.B. für Logins) mitsenden soll, muss das auf 'true' stehen!
41    'supports_credentials' => true,
42
43];

Um diese Festung komplett abzuriegeln, gehst du jetzt in deine .env-Datei im Laravel-Projekt und stellst sicher, dass die FRONTEND_URL exakt definiert ist:

# In der lokalen Entwicklung:
FRONTEND_URL=http://localhost:3000

# Wenn du später auf deinem Live-Server bist, änderst du das auf:
# FRONTEND_URL=https://mein-genialer-blog.de

Der Sieg über die Konsole

Das war’s. Du hast den roten Endgegner besiegt.

Wenn dein Next.js-Frontend jetzt einen Request an Laravel schickt, antwortet Laravel dem Browser mit einem speziellen Header: Access-Control-Allow-Origin: http://localhost:3000. Der Browser nickt zufrieden, lässt den Request passieren und deine Daten fließen nahtlos.

Sollte aber ein Hacker versuchen, von böse-hacker-seite.com per JavaScript auf deine API zuzugreifen, schaut Laravel in die cors.php, sieht, dass die Domain nicht auf der VIP-Liste steht, und verweigert den speziellen Header. Der Browser des Hackers blockiert die Anfrage sofort. Deine Datenbank bleibt absolut unantastbar.

Die unsichtbare Rüstung: HTTP Security Header

Wir haben unsere API mit Rate Limiting vor roher Gewalt geschützt und mit CORS die Brücke zu unserem Next.js-Frontend abgeriegelt. Aber Hacker greifen selten nur mit dem Holzhammer an. Oft nutzen sie extrem raffinierte, kleine Tricks.

Zwei der berüchtigtsten Angriffsvektoren im Web sind XSS (Cross-Site Scripting) und Clickjacking. Bei einem XSS-Angriff versucht ein Hacker, bösartigen JavaScript-Code (z.B. über ein manipuliertes Kommentarfeld) in unsere Datenbank zu schmuggeln. Wenn ein ahnungsloser Nutzer diesen Kommentar später in Next.js lädt, führt sein Browser das unsichtbare Skript aus und klaut beispielsweise sein Session-Cookie. Beim Clickjacking legt der Angreifer eine unsichtbare Schicht über deine Webseite. Der Nutzer denkt, er klickt auf ein lustiges Katzenvideo, klickt aber in Wirklichkeit unsichtbar auf den "Account löschen"-Button deiner API.

Um diese fiesen Angriffe im Keim zu ersticken, nutzen wir sogenannte HTTP Security Header. Das sind kleine, unsichtbare Instruktionen, die dein Laravel-Server bei absolut jeder Antwort an den Browser des Nutzers mitsendet. Sie sagen dem Browser knallhart, was er darf und was nicht.

Die Rüstung schmieden: Eine eigene Middleware

In Laravel rüsten wir jeden ausgehenden Request am besten mit einer eigenen Middleware aus. Öffne dein Terminal und schmiede deine neue Rüstung:

php artisan make:middleware SecurityHeaders

Laravel erstellt die Datei app/Http/Middleware/SecurityHeaders.php. Wir öffnen sie und fügen unsere Schutzschilde hinzu. Schau dir an, wie wir dem Response-Objekt vor dem Ausliefern einfach ein paar Header anheften:

1<?php
2
3namespace App\Http\Middleware;
4
5use Closure;
6use Illuminate\Http\Request;
7use Symfony\Component\HttpFoundation\Response;
8
9class SecurityHeaders
10{
11    public function handle(Request $request, Closure $next): Response
12    {
13        // Wir lassen den Request zuerst ganz normal durch Laravel laufen
14        $response = $next($request);
15
16        // Dann heften wir dem fertigen Response unsere Panzerplatten an:
17
18        // 1. Clickjacking-Schutz: Verbietet es fremden Seiten, unsere API in einem <iframe> zu laden.
19        $response->headers->set('X-Frame-Options', 'DENY');
20
21        // 2. XSS-Schutz: Zwingt den Browser, seinen eingebauten XSS-Filter zu aktivieren.
22        $response->headers->set('X-XSS-Protection', '1; mode=block');
23
24        // 3. MIME-Sniffing-Schutz: Verhindert, dass der Browser z.B. eine manipulierte Bilddatei plötzlich als ausführbares Skript interpretiert.
25        $response->headers->set('X-Content-Type-Options', 'nosniff');
26
27        // 4. HSTS (Strict-Transport-Security): Zwingt den Browser für das nächste Jahr (31536000 Sekunden), 
28        // AUSSCHLIESSLICH über verschlüsseltes HTTPS mit uns zu sprechen. Kein unverschlüsseltes HTTP mehr!
29        $response->headers->set('Strict-Transport-Security', 'max-age=31536000; includeSubDomains');
30
31        return $response;
32    }
33}

Das sind die vier absoluten Basis-Header, die heutzutage auf jede moderne API gehören. Sie kosten null Performance, aber sie schließen massenhaft Sicherheitslücken auf der Client-Seite.

Die Rüstung anlegen

Jetzt haben wir diese mächtige Middleware, aber Laravel nutzt sie noch nicht. Da wir wollen, dass jede einzelne API-Anfrage diese Rüstung trägt, registrieren wir sie global für unsere API-Routen.

In Laravel 11 und 12 machen wir das im zentralen Routing- und Middleware-Hub: der Datei bootstrap/app.php.

Öffne die bootstrap/app.php und weise Laravel an, unsere neue Rüstung an die API-Gruppe anzuhängen:

1<?php
2
3use Illuminate\Foundation\Application;
4use Illuminate\Foundation\Configuration\Exceptions;
5use Illuminate\Foundation\Configuration\Middleware;
6
7return Application::configure(basePath: dirname(__DIR__))
8    ->withRouting(
9        web: __DIR__.'/../routes/web.php',
10        api: __DIR__.'/../routes/api.php',
11        commands: __DIR__.'/../routes/console.php',
12        health: '/up',
13    )
14    ->withMiddleware(function (Middleware $middleware) {
15        
16        // BÄM! Wir hängen unsere SecurityHeaders Middleware an JEDEN API-Request an.
17        $middleware->api(append: [
18            \App\Http\Middleware\SecurityHeaders::class,
19        ]);
20        
21    })
22    ->withExceptions(function (Exceptions $exceptions) {
23        //
24    })->create();

Das war’s. Ab diesem Moment verlässt kein einziges JSON-Paket mehr deinen Server, ohne von Kopf bis Fuß gepanzert zu sein. Wenn du jetzt deine Next.js-App öffnest und im Browser die Netzwerkanalyse (Network Tab) aufrufst, wirst du bei jeder API-Antwort diese neuen Header stolz präsentiert sehen.

Deine API ist nun gegen rohe Gewalt (Rate Limiting), unbefugte Fremdzugriffe (CORS) und listige Skript-Attacken (Security Header) gewappnet.

Zusammenfassung: Die uneinnehmbare API-Festung

Lehn dich zurück und betrachte, was wir in diesem vierzehnten Teil erschaffen haben. Du hast nicht einfach nur eine schnelle API gebaut – du hast sie heute in einen echten Hochsicherheitstrakt verwandelt.

Wir haben einen unbestechlichen Rate Limiting-Türsteher aufgestellt, der aggressive Skripte und Bots sofort in die Schranken weist und deine hart erarbeiteten Server-Ressourcen schont. Wir haben mit CORS eine exklusive, holografische Brücke gebaut, die nur dein eigenes Next.js-Frontend überqueren darf. Und wir haben jede einzelne HTTP-Antwort mit einer unsichtbaren Rüstung aus Security Headern versehen, die deine Infrastruktur vor XSS, Clickjacking und gefährlichem MIME-Sniffing schützt.

Dein System ist jetzt pfeilschnell, asynchron skalierbar und absolut kugelsicher. Es ist bereit für die wilde, unberechenbare Realität des Internets.