Is Laravel secure by default?

The framework ships strong defaults: CSRF protection, hashed passwords, SQL injection protection through the query builder, and escaped Blade output. Most real-world incidents come from deployment mistakes — debug mode on, exposed .env files, unpatched PHP, weak SSH — which is why server hardening matters as much as application code.

What is the single most important Laravel security setting?

APP_DEBUG=false in production. An exposed debug page leaks environment variables, credentials and paths, and it is still the most common self-inflicted Laravel breach. Verify it now, then automate the check in your deploy pipeline.

How often should I update PHP and my dependencies?

Apply security patches as soon as practical — automate detection with composer audit in CI and Renovate or Dependabot for update PRs. For PHP itself, use a managed mechanism rather than memory: Cipi, for example, checks weekly and applies PHP security patches via cipi php upgrade.

Do I need a WAF for a Laravel app?

A WAF is a useful extra layer, not a substitute for the basics. Close the fundamentals first: TLS, patched software, hardened SSH, validated input, rate limiting. After that, a CDN-level WAF adds defense in depth against automated attacks.

What should I do first if I suspect a compromised server?

Isolate the machine from traffic, rotate every secret it held (database passwords, API tokens, APP_KEY), restore the application onto a clean server from a known-good backup, and only then investigate the entry point. Patching the live compromised host and hoping is how attackers keep their foothold.

Cybersicherheit · PHP & Laravel

Das Praktische Laravel Sicherheit Checkliste

Von Andrea Pollastri · Letzte Aktualisierung: 4. August 2026 · Kostenlose Lektüre, keine Paywall

Die meisten Laravel-Apps werden nicht von cleveren Zero-Days gehackt. Sie werden durch offengelegte .env-Dateien, aktivierten Debug-Modus, ungepatchtes PHP und schwaches SSH gehackt. Diese Checkliste deckt zunächst die langweiligen, wirkungsvollen Arbeiten ab – Server, Anwendung, Abhängigkeiten, Geheimnisse und Reaktion – und bietet eine Möglichkeit, jeden Schritt zu automatisieren.

In diesem Ratgeber

Was tatsächlich dazu führt, dass Laravel Apps gehackt werden
Checkliste zur Serverhärtung
Checkliste zur Anwendungshärtung
Abhängigkeiten und Lieferkette
Geheimnisse & Datenschutz
Erkennung, Überwachung und Reaktion
FAQ

Was tatsächlich dazu führt, dass Laravel Apps gehackt werden

Geordnet danach, wie oft sie bei realen Vorfällen auftauchen, nicht danach, wie interessant sie sind:

Offengelegte Debug-Ausgabe. APP_DEBUG=true in Produktionsleckumgebungen Variablen, Datenbankanmeldeinformationen und Dateipfade an jeden weitergeben, der einen Fehler auslöst.
Lesbar .env oder .git/. Ein falsch konfiguriertes Dokument verursacht dies Serve Dotfiles übergibt Ihren APP_KEY und Ihre Anmeldeinformationen.
Ungepatchtes PHP, Framework oder Pakete mit bekannten CVEs.
Schwaches SSH: Passwortauthentifizierung, Root-Login aktiviert, kein Brute-Force-Schutz.
Unsichere Datei-Uploads die ausführbare Inhalte in über das Internet bereitgestellte Pfade ermöglichen.
Einspritzung in die Notluken: Roh-SQL ohne Bindungen, ohne Escapezeichen {!! !!} Klingenausgang.
Admin-Panels ohne MFA und ohne Ratenbegrenzung.

Langweilig schlägt clever: Wenn Sie diese sieben Türen schließen, sind Sie der überwiegenden Mehrheit der Produktion voraus PHP Bereitstellungen.

Checkliste zur Serverhärtung

SSH: nur Schlüssel, kein Root.Deaktivieren Sie die Passwortauthentifizierung und die Root-Anmeldung. benutze a dedizierter Admin-Benutzer. Fügen Sie Fail2ban hinzu, um wiederholte Fehler zu verhindern. (Eine frische Cipi install wendet standardmäßig genau dies an: Root-Login deaktiviert, Nur-Schlüssel-Administratorzugriff, Fail2ban und UFW aktiviert.)
Firewall-Standardverweigerung. Nur 22, 80 und 443 sollten antworten. Datenbanken und Valkey/Redis Hören Sie auf localhost – überprüfen Sie mit ss -tlnp.
TLS überall, erzwungen. Kostenlose Let's Encrypt-Zertifikate, HTTP umgeleitet zu HTTPS (cipi ssl install dann cipi ssl force), HSTS aktiviert.
Patchen Sie nach einem Zeitplan, nicht nach einem Speicher. Unbeaufsichtigte Sicherheitsupdates für das Betriebssystem; a bewusster Mechanismus für PHP (Cipi führt eine wöchentliche PHP-Sicherheitspatchprüfung durch – cipi php upgrade).
Fingerabdrücke reduzieren: expose_php = Off, server_tokens off.
Isolieren Sie Apps voneinander. Pro-App-Systembenutzer und PHP-FPM-Pools begrenzen die Explosion Radius, wenn eine App gefährdet ist – Cipi stellt diese Isolierung automatisch pro App bereit.
Reste entfernen: phpinfo-Dateien, Adminer, veraltete Subdomains, die auf alt verweisen Boxen.

Checkliste zur Anwendungshärtung

APP_ENV=production, APP_DEBUG=false – nicht verhandelbar.
Erzwinge HTTPS auf App-Ebene auch (vertrauenswürdige Proxys + erzwungenes Schema), also signierte URLs und Cookies verhalten sich.
Überprüfen Sie alles mit Formularanfragen; Vertrauen Sie niemals Client-Eingaben, einschließlich Headern und Dateinamen.
Masseneinsatzwächter: explizit $fillable bei jedem Modell.
Autorisieren Sie mit Richtlinien auf jeder Route, die die Daten einer anderen Person berührt; hinzufügen Route::can() / middleware, not ad-hoc ifs.
Ratenbegrenzung Anmeldung, Registrierung, Passwort-Reset und öffentliche APIs mit Laravel RateLimiter.
Sitzungs- und Cookie-Flags: secure, http_only, same_site konfiguriert in config/session.php.
Bleiben Sie in eloquenten Bindungen. Wenn Sie es verwenden müssen whereRaw, Passbindungen – Interpolieren Sie niemals Eingaben in SQL-Zeichenfolgen.
Standardmäßig Escape. Behandeln {!! !!} als Code-Geruch, der einer Begründung bedarf und Desinfektion.
Datei-Uploads: MIME-Typ und -Größe validieren, außerhalb speichern public/ mit Zufällige Namen, Bereitstellung über signierte URLs oder einen Controller.
Sicherheitsheader: X-Frame-Options, X-Content-Type-Options, Referrer-Policy und ein CSP passend zu Ihrem Frontend.

Abhängigkeiten und Lieferkette

Ihre App besteht größtenteils aus dem Code anderer Personen. Behandeln Sie die Abhängigkeitshygiene daher als erstklassige Sicherheitskontrolle:

Sperrdateien festschreiben (composer.lock, package-lock.json) also Die Produktion läuft genau so, wie Sie es getestet haben.
Lauf composer audit im CI bei jeder Pull-Anfrage – der Build schlägt fehl, wenn Eine Abhängigkeit verfügt über eine bekannte Empfehlung. (Die Verkabelung in eine Pipeline dauert fünf Minuten – siehe unsere CI/CD Anleitung.)
Automatisieren Sie Update-PRs mit Renovate oder Dependabot; Kleine wöchentliche Ausschläge schlagen vierteljährlich Mega-Upgrades.
Suchen Sie nach Laravel-spezifischen Fehlkonfigurationen. Kontrollpunkt ist ein open-source Laravel Sicherheitsscanner, den Sie Ihrer Toolchain hinzufügen können, um Fehler auf Framework-Ebene zu erkennen, bevor sie auftreten Schiff.
Scannen Sie auch von außen. Eine Plattform wie Hackly Läuft wiederkehrend Schwachstellenscans auf Ihrer öffentlichen Oberfläche – der Sicht des Angreifers auf Ihren Stack, nach einem Zeitplan.

Geheimnisse & Datenschutz

.env betritt Git nie. Verteilen Sie Geheimnisse über Ihre Bereitstellungstools. nicht das Repository.
Datenbankbenutzer mit den geringsten Rechten: ein Benutzer pro App, nein GRANT ALL auf *.*. (Cipi erstellt eine dedizierte Datenbank und einen Benutzer pro App.)
Verschlüsseln Sie die Infrastrukturkonfiguration im Ruhezustand. Cipi speichert seine Server- und App-Konfiguration verschlüsselt mit AES-256 auf Ihrem VPS – Infrastrukturmetadaten verlassen niemals den Computer.
Geltungsbereich API Token (Sanctum-Fähigkeiten) und wechselnde Anmeldeinformationen, wenn Leute das Heiligtum verlassen.
Anonymisieren Sie Produktionsdaten vor der Weitergabe. Übergeben Sie niemals Produktionsdeponien an die Bereitstellung oder externe Entwickler roh; die Cipi Agent Das Paket Laravel enthält a Datenbank-Anonymisierer für genau diesen Workflow.
Verschlüsselte Offsite-Backups – und testen Sie den Wiederherstellungspfad (siehe Bereitstellungsanleitung für die Sicherung Setup).

Erkennung, Überwachung und Reaktion

Ausnahmen zentralisieren. Eine Spitze in 500 Sekunden ist oft das erste Anzeichen einer Sondierung. Boogle gibt dir ein self-hosted Ausnahme-Tracker, sodass Fehler-Payloads (die häufig Benutzerdaten enthalten) in Ihrer Infrastruktur verbleiben.
Gesundheitschecks + Verfügbarkeitswarnungen. Cipi 5 versendet App-Gesundheitsprüfungen; Kombiniere sie mit einem Externer Betriebszeitmonitor für die Außenansicht.
Sehen Sie sich die Authentifizierungsprotokolle an. Fail2ban-Berichte und lastb Sag dir, wer klopft.
Erstellen Sie einen Reaktionsplan, bevor Sie ihn benötigen: Isolieren Sie die Kiste, drehen Sie jedes Geheimnis um (einschließlich APP_KEY-Auswirkungen auf verschlüsselte Daten), Wiederherstellung von einem bekanntermaßen funktionierenden Snapshot (cipi backup run deckt geplante Schnappschüsse ab; Cipi 5 fügt Datenbank-Snapshots vor der Bereitstellung hinzu), Identifizieren Sie den Einstiegspunkt und schreiben Sie dann die Obduktion. Versuchen Sie niemals, ein kompromittiertes Leben zu führen Gastgeber.

Setzen Sie dies mit Cipi in die Praxis um

Cipi ist die kostenlose open-source Bereitstellung CLI, auf die in diesem Handbuch verwiesen wird: Ein Befehl verwandelt einen neuen Ubuntu VPS in einen gehärteten Produktionsserver für Laravel – Nginx, PHP-FPM oder Octane, MariaDB oder PostgreSQL, Warteschlangen, Scheduler, SSL und Git-Bereitstellungen ohne Ausfallzeiten enthalten.

wget -O - https://cipi.sh/setup.sh | bash

Starten Sie kostenlos durch Stern auf GitHub Vergleichen Sie mit anderen Tools

Häufig gestellte Fragen

Ist Laravel standardmäßig sicher?

Das Framework bietet starke Standardeinstellungen: CSRF-Schutz, gehashte Passwörter, SQL-Injection-Schutz durch den Abfrage-Builder und maskierte Blade-Ausgabe. Die meisten Vorfälle in der realen Welt sind auf Bereitstellungsfehler zurückzuführen – aktivierter Debug-Modus, offengelegte .env-Dateien, ungepatchtes PHP, schwaches SSH – weshalb die Serverhärtung genauso wichtig ist wie Anwendungscode.

Was ist die wichtigste Laravel-Sicherheitseinstellung?

APP_DEBUG=false in der Produktion. Eine offengelegte Debug-Seite gibt Umgebungsvariablen, Anmeldeinformationen und Pfade preis und ist immer noch der häufigste selbstverschuldete Laravel-Verstoß. Überprüfen Sie es jetzt und automatisieren Sie dann die Prüfung in Ihrer Bereitstellungspipeline.

Wie oft sollte ich PHP und meine Abhängigkeiten aktualisieren?

Wenden Sie Sicherheitspatches so schnell wie möglich an – automatisieren Sie die Erkennung mit composer Audit in CI und Renovate oder Dependabot für Update-PRs. Verwenden Sie für PHP selbst einen verwalteten Mechanismus anstelle von Speicher: Cipi prüft beispielsweise wöchentlich und wendet PHP Sicherheitspatches über cipi php Upgrade an.

Benötige ich eine WAF für eine Laravel-App?

Eine WAF ist eine nützliche zusätzliche Ebene und kein Ersatz für die Grundlagen. Schließen Sie zunächst die Grundlagen ab: TLS, gepatchte Software, gehärtetes SSH, validierte Eingabe, Ratenbegrenzung. Danach sorgt eine WAF auf CDN-Ebene für einen umfassenden Schutz vor automatisierten Angriffen.

Was soll ich zuerst tun, wenn ich den Verdacht habe, dass ein Server kompromittiert ist?

Isolieren Sie die Maschine vom Datenverkehr, rotieren Sie alle darin enthaltenen Geheimnisse (Datenbankkennwörter, API-Tokens, APP_KEY), stellen Sie die Anwendung aus einem nachweislich funktionierenden Backup auf einem sauberen Server wieder her und untersuchen Sie erst dann den Einstiegspunkt. Den infizierten Live-Host zu patchen und zu hoffen, ist die Möglichkeit für Angreifer, Fuß zu fassen.