Wer ein bestehendes Laravel-Projekt übernimmt, übernimmt nicht nur Code. Im System liegen bereits Benutzerkonten, Datenflüsse, Hintergrundjobs, Integrationen und über Jahre gewachsene Annahmen. Die Anwendung kann funktional stabil wirken und trotzdem Sicherheitsgrenzen besitzen, die niemand mehr vollständig beschreiben kann.
Eine Sicherheitsprüfung gehört deshalb nicht automatisch als maximaler Pentest in jede Übernahme. Sie gehört aber in die Risikobewertung. Besonders relevant wird sie, wenn personenbezogene oder geschäftskritische Daten verarbeitet werden, mehrere Kunden denselben Dienst nutzen, öffentlich erreichbare APIs existieren oder unmittelbar größere Änderungen geplant sind.
Meine Kombination aus Laravel-Entwicklung und offensiver Sicherheitsprüfung ist für diese Situation praktisch: Ich kann Daten- und Kontrollflüsse im Framework nachvollziehen und zugleich prüfen, ob die Annahmen im laufenden System aus Angreifersicht halten. Ziel ist kein beliebig langer Mängelkatalog. Ziel ist eine belastbare Antwort auf die Frage: Welche Sicherheitsrisiken muss das übernehmende Team kennen, bevor es Verantwortung und Änderungen übernimmt?
Erst Systemgrenzen verstehen, dann Payloads senden
Ein Pentest ohne Systemverständnis kann sichtbare Endpunkte prüfen, übersieht aber leicht die fachlich wichtigen Grenzen. Eine reine Codeanalyse findet verdächtige Stellen, beweist jedoch nicht automatisch deren Erreichbarkeit oder Auswirkung. Bei einer Übernahme sollten beide Perspektiven schrittweise verbunden werden.
Der Einstieg beginnt mit einer kompakten Systemkarte:
- Welche Nutzer- und Administrationsrollen gibt es?
- Wo beginnt und endet ein Mandant?
- Welche Daten kommen über Web, API, Import oder Webhook in das System?
- Welche Dateien werden hochgeladen, erzeugt oder ausgeliefert?
- Welche Aktionen laufen später über Queues oder den Scheduler?
- Welche Drittanbieter besitzen Zugriff oder erhalten Daten?
- Welche Verwaltungswege existieren außerhalb der normalen Oberfläche?
Diese Karte muss nicht vollständig sein, bevor Tests beginnen. Sie macht aber sichtbar, welche Lücken im Verständnis selbst ein Risiko darstellen. Wenn niemand weiß, welcher Job einen Export erzeugt oder welche Middleware eine interne Route schützt, wird genau dieser Pfad priorisiert untersucht.
Authentifizierung ist nur die Eingangstür
Laravel bietet robuste Bausteine für Sessions, Passwort-Hashing und Autorisierung. Ihre Existenz garantiert jedoch keine sichere Produktlogik. Viele relevante Fehler entstehen hinter einem gültigen Login: Ein Benutzer verändert eine ID, ruft eine Aktion im falschen Zustand auf oder erhält über einen Export mehr Daten als in der Oberfläche sichtbar sind.
Bei der Übernahme sollte die Authentifizierung trotzdem zuerst kartiert werden. Relevant sind nicht nur Login und Passwort-Reset, sondern alle Vertrauensübergänge:
- Einladungs- und Registrierungslinks,
- E-Mail-Verifikation und Änderung der E-Mail-Adresse,
- Single Sign-on und Account-Verknüpfung,
- API-Tokens, persönliche Tokens und Service-Zugänge,
- Impersonation oder Support-Zugriffe,
- Wiederherstellung und Deaktivierung von Konten.
Die Prüffrage lautet jeweils: Welche Eigenschaft beweist dieser Schritt wirklich, wie lange gilt der Beleg und kann er für einen anderen Zweck wiederverwendet werden? Ein signierter Link kann technisch korrekt signiert und fachlich trotzdem zu weitreichend oder zu lange gültig sein.
Berechtigungen und Mandantengrenzen getrennt prüfen
In SaaS-Anwendungen werden drei Regeln häufig vermischt: Gehört ein Datensatz zum richtigen Mandanten? Darf die aktuelle Rolle diesen Datensatz sehen? Ist die gewünschte Aktion im aktuellen fachlichen Zustand erlaubt? Ein globaler Scope oder eine Policy kann einen Teil davon lösen, aber selten alle drei.
Ein belastbarer Test arbeitet deshalb mit mehreren Konten und negativen Fällen. Für eine Funktion wie einen Rechnungsdownload wären beispielsweise folgende Versuche relevant:
- berechtigte Rechnung im eigenen Mandanten,
- fremde Rechnung mit derselben Rolle,
- eigene Rechnung mit schwächerer Rolle,
- eigener Datensatz in einem Zustand ohne Downloadfreigabe,
- direkter Dateipfad statt vorgesehener Downloadroute,
- Export oder Queue-Job, der dieselbe Datenmenge indirekt erzeugt.
Besonders wichtig sind Pfade außerhalb normaler Controller. Policies helfen nur, wenn sie konsequent aufgerufen werden. Jobs, Console Commands, Livewire-Aktionen, API-Endpunkte oder temporäre Storage-URLs können dieselbe fachliche Grenze auf anderen Wegen berühren.
Der Laravel-Dokumentationsabschnitt zur Autorisierung beschreibt Gates und Policies. Für die Übernahme ist die zentrale Frage jedoch nicht, ob diese Mechanismen irgendwo verwendet werden, sondern ob jede relevante Zugriffsstrecke dieselbe Regel erzwingt.
Mass Assignment ist nicht die ganze Eingabeprüfung
Laravel-Teams kennen meist $fillable, $guarded und Form Requests. Kritische Eingaben entstehen dennoch oft durch Kombinationen. Ein Feld kann formal validiert sein und eine Aktion auslösen, die für diese Rolle oder diesen Zustand nicht erlaubt ist. Eine URL kann syntaktisch gültig sein und später serverseitig interne Ziele abrufen. Ein Dateiname kann bereinigt werden, während der tatsächliche Dateityp unpassend bleibt.
Bei der Sicherheitsprüfung werden Eingaben entlang ihres gesamten Weges verfolgt:
- Wo wird ein Wert normalisiert und validiert?
- Wird er später in SQL, Templates, Headern, Dateipfaden oder Shell-Aufrufen verwendet?
- Löst er einen asynchronen Job aus?
- Wird die Berechtigung vor dem Dispatch und erneut bei der Ausführung geprüft?
- Kann sich die zugrunde liegende Ressource zwischen Prüfung und Nutzung ändern?
Dieses Denken ist bei gewachsenem Code wichtiger als die Suche nach einem einzelnen unsicheren Methodenaufruf. Framework-Schutz reduziert viele Standardfehler, aber Geschäftslogik und Integrationsgrenzen bleiben anwendungsspezifisch.
Dateien, Exporte und temporäre Links priorisieren
Dateipfade sind bei Übernahmen besonders ergiebig, weil sie mehrere Schichten verbinden: Uploadvalidierung, Storage-Konfiguration, Zugriffskontrolle, Webserver und manchmal externe Objektspeicher. Die Oberfläche kann einen Download korrekt verstecken, während eine erratbare URL oder zu großzügige Signatur direkten Zugriff ermöglicht.
Für Uploads sollte geklärt werden, ob Größe, Inhalt und zulässiger Typ serverseitig geprüft werden, ob Dateinamen kontrolliert sind und ob aktive Inhalte in einem passenden Auslieferungskontext landen. Für Exporte zählen Datenumfang, Mandantenbezug, Lebensdauer, Protokollierung und Widerruf. Für temporäre URLs ist entscheidend, was genau signiert wird und ob der Empfänger nach Erstellung noch berechtigt sein muss.
Ein Pentest versucht nicht nur, „eine Datei hochzuladen“. Er prüft die Kette: Kann der Inhalt gespeichert, verarbeitet, von einem privilegierten Prozess geöffnet oder in einer riskanten Herkunft ausgeliefert werden? Erst die erreichbare Auswirkung bestimmt die Bedeutung.
Queues und Integrationen als Vertrauensgrenzen behandeln
Hintergrundjobs übernehmen häufig bereits geprüfte IDs und führen später privilegierte Aktionen aus. Zwischen Dispatch und Verarbeitung können sich Rolle, Mandant, Status oder Daten ändern. Deshalb gehört zur Übernahme die Frage, ob der Job seine Voraussetzungen selbst erneut erzwingt oder blind auf den früheren Kontext vertraut.
Ähnliches gilt für Webhooks und Drittanbieter. Eine gültige Signatur beantwortet nur, ob die Nachricht zum erwarteten Schlüssel passt. Zusätzlich müssen Wiederholungen, Reihenfolge, Zuordnung zum richtigen Konto und erlaubte Zustandswechsel betrachtet werden. Idempotenz ist dabei nicht nur eine Zuverlässigkeitsfrage: Doppelte Gutschriften, wiederholte Einladungen oder mehrfach ausgelöste Berechtigungsänderungen können Sicherheitsauswirkungen haben.
Die OWASP Web Security Testing Guide liefert dafür breite Testperspektiven. Projektspezifische Geschäftslogik muss darüber hinaus aus Code, Produktwissen und beobachtetem Verhalten abgeleitet werden.
Prüfung nach Risiko staffeln
Nicht jede Übernahme benötigt sofort denselben Aufwand. Ein sinnvolles Vorgehen kann in drei Stufen organisiert werden.
Sicherheitsorientierte Bestandsaufnahme
Zuerst werden Architektur, Rollen, Datenklassen, externe Flächen und vorhandene Tests kartiert. Dazu kommen wenige gezielte Stichproben an den kritischsten Grenzen. Das Ergebnis ist eine priorisierte Prüfkarte, kein Pentest-Zertifikat.
Fokussierter Anwendungstest
Danach werden die risikoreichsten Workflows dynamisch und, wenn vereinbart, mit Quellcodeunterstützung geprüft. Beispiele sind Mandantenwechsel, Administrationsaktionen, Zahlungs- oder Freigabeprozesse, Dateiwege und externe Integrationen. Findings benötigen reproduzierbare Belege und eine klare Auswirkung.
Breiter Pentest oder Teamprüfung
Wenn der Scope neben der Laravel-Anwendung auch mobile Clients, Cloud-Infrastruktur, Netzwerke oder mehrere Systeme umfasst, ist ein größeres Testmodell angemessen. Solche umfassenden Projekte werden über DSecured geplant. Die Bestandsaufnahme bleibt trotzdem nützlich, weil sie Scope und Risikoschwerpunkte konkreter macht.
Ergebnisse in die Übernahme integrieren
Ein Sicherheitsbericht darf nicht neben dem technischen Übernahmeplan liegen bleiben. Jedes bestätigte Finding braucht eine Entscheidung: sofort beheben, kontrolliert einplanen, kompensierende Maßnahme umsetzen oder Risiko ausdrücklich akzeptieren. Verantwortlichkeit und Retest-Termin gehören dazu.
Die nachhaltigsten Korrekturen verbinden drei Ebenen:
- eine zentrale Regel im Anwendungscode,
- einen negativen automatisierten Regressionstest,
- einen Retest des ursprünglichen Angriffspfads im laufenden System.
So wird das gewonnene Wissen Teil der neuen Wartungsbasis. Gleichzeitig sollten Sicherheitsannahmen dokumentiert werden: Welche Tenant-ID ist maßgeblich? Welche Rolle darf einen Export erzeugen? Welche Webhook-Ereignisse sind wiederholbar? Solche kurzen Invarianten helfen dem übernehmenden Team bei jeder späteren Änderung.
Fazit
Die Übernahme eines Laravel-Projekts ist ein guter Zeitpunkt, unbekannte Sicherheitsannahmen sichtbar zu machen. Nicht jede Anwendung braucht sofort einen maximalen Pentest. Aber jede verantwortungsvolle Übernahme sollte klären, welche Daten und Rollen kritisch sind, wo Vertrauen die Systemgrenze wechselt und welche Risiken vor der nächsten großen Änderung geprüft werden müssen.
Ich kann diese Arbeit als Laravel-Entwickler und Pentest-Freelancer verbinden: erst den technischen Kontext aufbauen, dann die wichtigen Grenzen aus Angreifersicht prüfen und die Ergebnisse so formulieren, dass sie in Code und Tests übergehen. Wenn du ein bestehendes System übernimmst oder externe Unterstützung für die Übernahme suchst, kannst du den Projektkontext vertraulich schildern. Für einen breiteren multidisziplinären Pentest planen wir stattdessen den passenden Weg über DSecured.