Bewährte Verfahren und Lösungen zur Laravel-Sicherheit für Entwickler (2026)

Wichtigste Erkenntnisse

• Ein Packagist-Angriff im Mai 2026 hat gezeigt, dass eine Versionsnummer allein nicht ausreicht, um zu belegen, dass eine Composer-Installation sauber ist.
• Laravel 13 wird vollständig unterstützt, für Laravel 12 werden nur noch Sicherheitsupdates bereitgestellt, und alle älteren Versionen sind nicht mehr unterstützt.
• CVE-2026-48019 betrifft alle Laravel-Versionen unterhalb von 12.60.0 sowie Laravel 13 vor Version 13.10.0.
• Die meisten Risiken bei Laravel liegen in den Opt-outs, den rohen Abfragen und den Abhängigkeiten, die niemand aktualisiert hat.

Die Sicherheit von Laravel hängt weniger vom Framework selbst ab als vielmehr davon, was nach der Installation geschieht. Eine deaktivierte Standardeinstellung, eine ungeschützte Abfrage oder eine nicht aktualisierte Abhängigkeit reichen in der Regel schon aus, um eine Sicherheitslücke zu schaffen.

Dieser Leitfaden gibt einen Überblick über die Bedrohungen, die nach wie vor in der Produktionsumgebung auftreten, die Maßnahmen zu ihrer Behebung, die Sicherung Ihrer APIs und die Vorgehensweise, falls Sie weiterhin eine Version nutzen müssen, deren Lebenszyklus bereits abgelaufen ist.

Warum Sicherheit in Laravel-Anwendungen wichtig ist

Ein einziger Sicherheitsverstoß kann jahrelanges Kundenvertrauen zunichte machen, rechtliche Haftung nach sich ziehen und Angreifern die Server-Zugangsdaten in die Hände spielen, mit denen sie Zugriff auf alle anderen von Ihnen betriebenen Systeme erhalten. Und die Art und Weise, wie Angreifer eindringen, hat sich verändert. Der Verizon DBIR 2026 ergab, dass die Ausnutzung einer Sicherheitslücke mittlerweile der häufigste Einstiegsvektor für Sicherheitsverletzungen ist und bei 31 % der Fälle auftritt – gegenüber 20 % im Vorjahr –, während der Missbrauch von Anmeldedaten auf 13 % zurückging.

Laravel schließt zwar von Haus aus ganze Problemkreise aus. Eloquent parametrisiert Abfragewerte, Blade führt standardmäßig eine Escape-Verarbeitung der Ausgabe durch, und die „Request Forgery“-Middleware ist in der Web-Gruppe integriert, ohne dass jemand darum gebeten hat. Nichts davon bleibt bestehen, wenn ein Entwickler es deaktiviert, und nichts davon deckt Autorisierung, Fehlkonfigurationen, serverseitige Request-Fälschungen, Geschäftslogik oder anfällige Abhängigkeiten ab. Das bleibt dauerhaft Ihre Aufgabe.

Häufige Sicherheitsrisiken bei Laravel

Cross-Site-Scripting über nicht maskierte Blade-Ausgabe

Blades {{ }} Syntax führt automatisch zu einer Ausgabeumgehung. Das {!! !!} Syntax tut dies nicht, und genau darauf greifen Nutzer zurück, wenn sie gespeichertes HTML aus einem CMS-Feld oder einem Rich-Text-Editor darstellen müssen.

Wenn dieser gespeicherte HTML-Code ein Script-Tag enthält, wird es im Browser jedes Nutzers ausgeführt, der die Seite lädt. Bereinigen Sie es daher zunächst serverseitig mit einer Bibliothek wie HTMLPurifier, bevor es überhaupt {!! !!}.

SQL-Injection durch „Raw“-Ausdrücke

Eloquent und der Query Builder parametrisieren Abfragewerte, sodass bei gewöhnlichen Abfragen keine Gefahr von Injektionen besteht. Das Problem tritt jedoch sofort wieder auf, sobald Benutzereingaben in DB::raw(), wobei `Raw()`, havingRaw()oder orderByRaw().

Spalten- und Richtungsnamen werden häufig übersehen, da sie nicht als Parameter gebunden werden können. Fügen Sie sie stattdessen in eine Whitelist für ein festes Array ein. Auch dies ist keineswegs Laravel-spezifisch. Es handelt sich um denselben Fehler, den PHP-Entwickler seit zwanzig Jahren bei der Erstellung von SQL-Abfragen aus Zeichenketten begehen.

Fehler bei der Authentifizierung und Sitzungsverwaltung

Das Authentifizierungs-Scaffolding von Laravel ist solide. Die Probleme treten in den umliegenden Bereichen auf: keine Ratenbegrenzung bei der Anmeldung, Reset-Token, die niemals ablaufen, Sitzungen, die nach einer Berechtigungsänderung nicht neu generiert werden, und benutzerdefinierte Abläufe zum Passwortwechsel, bei denen „setRememberToken“ übersprungen wird, sodass „Remember-me“-Sitzungen auch nach der Passwortänderung gültig bleiben. 

Die Autorisierung sollte getrennt von der Authentifizierung geprüft werden. Ein funktionierender Anmeldevorgang, der es jedem authentifizierten Benutzer ermöglicht, /admin aufrufen kann, stellt eine Autorisierungslücke dar und ist kein Fehler im Anmeldeformular.

Bewährte Verfahren für die Sicherheit in Laravel

1. Halten Sie Laravel und seine Abhängigkeiten auf dem neuesten Stand

Ausführen „composer outdated“ alle ein bis zwei Wochen aus, um zu sehen, für welche Pakete neuere Versionen verfügbar sind, und führe anschließend „composer update“ aus, um sie unter Berücksichtigung der Einschränkungen, die du in composer.jsonfestgelegt haben. Behalten Sie die die Release-Notes von Laravel sowie die Sicherheitshinweise auf GitHub im Auge, denn dort tauchen neu bekannt gewordene Sicherheitslücken im Framework als Erstes auf.

Gemäß der aktuellen Richtlinie von Laravel werden für jede Version ab dem Veröffentlichungsdatum 18 Monate lang Fehlerbehebungen und zwei Jahre lang Sicherheitsupdates bereitgestellt. Es gibt auch keine LTS-Stufe mehr. Laravel 6 war die letzte LTS-Version, und die Zeiträume haben sich während der Umstellung von halbjährlichen Minor-Releases auf jährliche Major-Releases verschoben, weshalb die älteren Zeilen unten nicht alle dem gleichen Muster folgen.

CVE-2026-48019 zeigt, welche Folgen es haben kann, wenn man den Anschluss verliert. Es handelt sich um eine CRLF-Injektion in der Standard-E-Mail-Validierungsregel von Laravel, die in Kombination mit der Art und Weise, wie Symfony Mailer und Symfony Mime bestimmte Zeichenfolgen behandeln, es einem nicht authentifizierten Angreifer ermöglicht, ausgehende E-Mails zu manipulieren, einen Bcc-Header einzufügen, den Inhalt der Nachricht zu ändern oder die Anwendung in einen Relay-Server zu verwandeln. Der Sicherheitshinweis stuft alle Versionen unterhalb von 12.60.0 als betroffen ein, ebenso wie Laravel 13 bis einschließlich 13.9.0; die Korrekturen wurden in den Versionen 12.60.0 und 13.10.0 implementiert. Das Sicherheitsfenster für Laravel 11 war bereits im März 2026 geschlossen worden, sodass Version 11 und alle darunter liegenden Zweige in diesem Bereich liegen, ohne dass es eine gepatchte Version vom Upstream gibt.

Falls ein umfassendes Upgrade derzeit nicht realistisch ist, bietet TuxCare mit seinem „Endless Lifecycle Support“ für Laravel Sicherheitskorrekturen über Composer auf bestimmte Baseline-Versionen zurückportiert, derzeit 5.4.36 bis 12.58.0, wobei weitere Versionen auf Anfrage verfügbar sind.

2. Behandeln Sie jede Abmeldung vom Datenschutz als Meilenstein bei der Codeüberprüfung

Every Laravel security default ships with an escape hatch, and each one deserves a second pair of eyes before it goes out. {!! !!} in Blade turns off output escaping. DB::raw() and whereRaw() accept raw SQL, so any untrusted input has to arrive as a binding rather than concatenated into the string. Model::unguard(), $guarded = [],and Laravel 13’s #[Unguarded] attribute all open mass assignment on every column. 

Der Schutz vor Request-Forgery verfügt über eine eigene Hintertür, und die API wurde verschoben. In Laravel 13 schließt man Routen mit preventRequestForgery(except: […]) in bootstrap/app.phpaus; in den Versionen 11 und 12 heißt die entsprechende Methode validateCsrfTokens(), und in allen älteren Versionen wird die Methode $except der CSRF-Middleware-Klasse. Eine Route kann sich auch davon abmelden, indem sie die entsprechende Middleware-Klasse zur Abwehr gefälschter Anfragen an withoutMiddleware().

Füge all diese Punkte zu einer grep-basierten CI-Prüfung hinzu und fordere den Autor jedes Pull-Requests, der einen dieser Punkte enthält, auf, in der Beschreibung zu erläutern, warum dieser Punkt vorhanden ist.

3. Serverseitige Validierung und separate Autorisierung

Bei der Validierung wird geprüft, ob die Daten korrekt formatiert sind. Bei der Autorisierung wird geprüft, ob dieser Benutzer berechtigt ist, darauf zuzugreifen. Das Bestehen der einen Prüfung sagt nichts über die andere aus.

Verwenden Sie Formularanforderungsklassen, damit Validierungsregeln an einem Ort gespeichert werden, der überprüft werden kann, sowie Richtlinien oder Gates für jede Modellaktion. Die clientseitige Validierung verbessert zwar die Benutzererfahrung, trägt jedoch in keiner Weise zur Sicherheit bei.

4. Konfiguration und Geheimnisse sichern

Set APP_DEBUG=false in der Produktionsumgebung ausnahmslos. Die Dokumentation von Laravel selbst weist unmissverständlich auf das Risiko hin, den Debug-Modus aktiviert zu lassen: Sensible Konfigurationswerte können für Endbenutzer sichtbar werden, und die Debug-Fehlerseite liefert detaillierte Stack-Traces an denjenigen, der den Fehler ausgelöst hat.

Speichern .env aus der Versionskontrolle heraus und stellen Sie sicher, dass Ihr Web-Stammverzeichnis auf /public, und aktualisieren Sie APP_KEY , falls er jemals festgeschrieben wurde. Jeder verschlüsselte Wert und jedes signierte Cookie in der Anwendung hängt von diesem Schlüssel ab; listen Sie den alten Schlüssel daher in APP_PREVIOUS_KEYS auf. Ohne diese Angabe können zuvor verschlüsselte Daten nicht mehr entschlüsselt werden, und jede authentifizierte Sitzung wird abgemeldet. 

5. Überprüfen Sie Abhängigkeiten planmäßig und nicht erst nach dem Auftreten von Vorfällen

Ausführen „composer audit“ in der CI aus, damit ein Paket mit bekannter Sicherheitslücke den Build zum Scheitern bringt, anstatt erst im Quartalsbericht aufzutauchen.

composer audit –format=summary

Auch die offiziellen Pakete von Laravel erhalten CVEs. CVE-2026-39976 war eine Umgehung der Authentifizierung in laravel/passport, die in Version 13.7.1 behoben wurde. Dabei wurde ein client_credentials Token zu einem echten Benutzerkonto führen konnte. Das Problem tritt nur auf, wenn UUID-Client-IDs deaktiviert wurden – genau die Art von Detail, die verloren geht, wenn ein Scanner lediglich meldet, dass ein Paket markiert ist. Kombinieren Sie planmäßige Scans mit regelmäßigen Sicherheitsaudits sowie mit einem dokumentierten Prozess zur das Beheben von Sicherheitslücken.

Achtung: Am 22. und 23. Mai 2026 hat ein Angreifer bösartigen Code unter historischen Release-Tags für vier Laravel-Lang-Pakete auf Packagist erneut veröffentlicht. Jeder bestehende Tag wurde auf einen neuen Commit umgeleitet, sodass die Versionsnummer in Ihrer composer.json keinen Aufschluss darüber gab, was tatsächlich installiert worden war. Um herauszufinden, ob Sie betroffen waren, mussten Sie den aufgelösten Commit in der Datei composer.lock, den Zeitpunkt der Ausführung Ihrer Builds sowie die damals veröffentlichten Indikatoren für eine Kompromittierung zu überprüfen.

Sicherheit von Laravel-APIs

Die meisten APIs sind zustandslos und tokenbasiert, was das Sicherheitsmodell verändert, anstatt es lediglich zu schwächen. Ein Bearer-Token wird vom Browser nicht automatisch gesetzt, wie es bei einem Session-Cookie der Fall ist, sodass der CSRF-Schutz nicht mehr die entscheidende Kontrollmaßnahme ist. Stattdessen kommt es auf die Authentifizierung, die Autorisierung bei jeder Aktion, eine tatsächlich konfigurierte CORS-Richtlinie, Ratenbegrenzung und den Lebenszyklus der Token an. Zustandsbehaftete Konfigurationen wie der SPA-Modus von Sanctum bilden hier die Ausnahme, da sie Session-Cookies verwenden und einen CSRF-Schutz benötigen.

Eine Sache fehlt allerdings wirklich. Niemand sitzt da und überwacht die Antworten, sodass ein langsamer Abfragevorgang über eine API tagelang laufen kann, bevor es jemand bemerkt.

Entscheiden Sie sich bewusst für „Sanctum“ oder „Passport“

Sanctum ermöglicht die Token- und SPA-Authentifizierung mit minimalem Konfigurationsaufwand und eignet sich für die meisten Anwendungen. Passport implementiert OAuth2 in vollem Umfang und ist nur dann sinnvoll, wenn Sie tatsächlich Autorisierungsabläufe von Drittanbietern benötigen.

Je größer die Fläche von Passport ist, desto größer ist das Risiko. Egal, wofür Sie sich entscheiden: Beschränken Sie den Geltungsbereich von Tokens und legen Sie Ablaufdaten fest. Ein Token ohne Ablaufdatum bleibt so lange gültig, bis jemand daran denkt, es zu widerrufen, was es sehr schwer macht, eine Sicherheitslücke einzudämmen.

Ratenbegrenzung für jeden öffentlichen Endpunkt

Die Throttle-Middleware von Laravel besteht aus einer einzigen Zeile, und es kann leicht passieren, dass man sie bei einer API-Route vergisst. Ohne sie laufen Credential-Stuffing und Enumeration mit der Geschwindigkeit ab, die Ihr Server zulässt.

Ratenbegrenzung pro Benutzer und pro IP-Adresse, mit strengeren Beschränkungen für die Anmeldung, das Zurücksetzen von Passwörtern und alle Vorgänge, bei denen E-Mails oder SMS versendet werden. Es sollte ein 429-Fehlercode zurückgegeben werden, anstatt den Fehler stillschweigend zu ignorieren.

Sichern Sie die Ebene unterhalb Ihrer Anwendung

Eine API ist nur so sicher wie der Server, auf dem sie gehostet wird. Setzen Sie TLS durch, deaktivieren Sie Verzeichnisauflistungen und installieren Sie Patches für das Betriebssystem und die PHP-Laufzeitumgebung unabhängig vom Laravel-Release-Zyklus.

Sicherheit auf Anwendungsebene ist bei einem kompromittierten Server nicht gewährleistet. Ganz gleich, was Sie innerhalb des Laravel-Quellcodes tun – die darunterliegende Infrastruktur muss eigenständig abgesichert und mit Patches versehen werden.

Hinweis: Laravel 13 hat den Schutz vor Request-Forgery offiziell als PreventRequestForgeryformalisiert, wodurch eine Herkunftsprüfung im Sec-Fetch-Site des Browsers. Eine Anfrage aus derselben Herkunft ist ohne Token zulässig, und alles, was die Herkunftsprüfung nicht besteht, wird stattdessen der Token-Validierung unterzogen. In der Laravel-Dokumentation wird darauf hingewiesen, dass der Header nur über HTTPS übertragen wird, sodass reines HTTP weiterhin vollständig auf das Token angewiesen ist. Informieren Sie sich darüber, was die Middleware tatsächlich überprüft, bevor Sie etwas davon ausnehmen.

Anbieter und Lösungen für Laravel-Sicherheit

TuxCare – Lebenslanger Support

ELS portiert Sicherheitskorrekturen auf Laravel-Versionen, die vom Kernteam nicht mehr gepflegt werden, und stellt diese über Composer bereit, sodass sich der Workflow für Abhängigkeiten nicht ändert. TuxCare deckt auch PHP-Laufzeitumgebungen ab, deren Support ausgelaufen ist , was wichtig ist, wenn eine ältere Laravel-Anwendung zudem auf einer PHP-Version läuft, für die der Upstream-Entwickler keine Patches mehr bereitstellt.

ELS ist kein Ersatz für eine spätere Aktualisierung. Es handelt sich um langfristigen Sicherheits-Support für Zweige, für die der Upstream-Entwickler keine Patches mehr bereitstellt. So erhalten Sie weiterhin CVE-Korrekturen für einen EOL-Zweig und können die Migration nach Ihrem eigenen Zeitplan planen, anstatt sich nach dem Zeitplan anderer richten zu müssen.

Derzeit unterstützen wir folgende Laravel-Versionen: 5.4.36, 5.5.50, 5.6.40, 5.7.29, 5.8.38, 6.20.45, 7.30.7, 8.12.0, 8.12.1, 8.12.2, 8.12.3, 8.83.29, 9.52.21, 10, 11, 12.58.0.

Abhängigkeitsprüfung

Beginnen Sie mit composer audit, da es kostenlos und bereits installiert ist. Es überprüft Ihre installierten Pakete, sodass auch transitive Abhängigkeiten berücksichtigt werden, und „composer audit –locked“ prüft stattdessen die Lock-Datei, wenn das Vendor-Verzeichnis nicht vorhanden ist. Snyk, GitHub Dependabot und Aikido bieten darüber hinaus kontinuierliche Überwachung, Warnmeldungen und automatisierte Pull-Anfragen für Updates – was sich lohnt, wenn niemand die CI genau im Auge behält. Für ein kleineres Team ist Dependabot eine sinnvolle Basis. Was keines dieser Tools löst, ist das Problem von EOL-Paketen, bei denen es gar keine feste Version gibt, auf die man überhaupt upgraden könnte.

Laufzeitschutz und -überwachung

Eine Webanwendungs-Firewall verschafft lediglich Zeit zwischen der Bekanntgabe einer Sicherheitslücke und der Veröffentlichung eines Patches – mehr nicht. Cloudflare, AWS WAF und ModSecurity können mit einem gepflegten Regelsatz wie dem OWASP Core Rule Set viele gängige Injektions- und XSS-Payloads abwehren, bevor diese PHP erreichen, wobei der Schutzumfang vollständig von den Regeln abhängt, die Sie aktivieren. Kombinieren Sie die Firewall mit einer Protokollüberwachung, damit sich ein Ausnutzungsversuch von einer gewöhnlichen fehlerhaften Anfrage unterscheidet.

Laravel-Anwendungen mit TuxCare absichern

Gerade bei der Aufrechterhaltung der Kompatibilität einer Laravel-Anwendung innerhalb ihres Support-Zeitraums geraten Teams oft in Rückstand. Größere Upgrades bringen kompatibilitätsbrechende Änderungen mit sich und konkurrieren mit der Bereitstellung neuer Funktionen im selben Sprint. Wenn Ihre Version das EOL überschritten hat und die Migration in diesem Quartal nicht stattfindet, sorgt der „Endless Lifecycle Support“ von TuxCare für Laravel sorgt dafür, dass sie auf dem neuesten Stand bleibt, bis Sie bereit für den Wechsel sind.

Zusammenfassung

Artikel Name

Bewährte Verfahren und Lösungen zur Laravel-Sicherheit für Entwickler (2026)

Beschreibung

Lernen Sie die bewährten Verfahren für die Sicherheit in Laravel kennen, um Anwendungen vor XSS, CSRF, SQL-Injection und anderen Bedrohungen zu schützen. Ein praktischer Leitfaden für Entwickler im Jahr 2026.

Autor

Claudia Cejas

Name des Herausgebers

TuxCare

Logo des Herausgebers