Fehlende Sicherheitsheader: wann sie wirklich zählen

Dein Scan kommt zurück und fast jede Zeile ist grün. Eine ist bernsteinfarben: einige Browser-Sicherheitsheader fehlen. Es ist das Einzige auf der Seite mit einer Farbe, also liest es sich wie die Sache, um die du dich zuerst kümmern musst.

Hier ist der Teil, den die meisten Ratgeber dazu falsch machen. Fehlende Sicherheitsheader ist der Befund, den wir am häufigsten ausgeben, und für sich genommen sagt er dir fast nichts darüber, ob jemand an deine Daten kommt. Ihn wie einen Einbruch zu behandeln heißt entweder, ihn panisch vor den Dingen zu beheben, die tatsächlich entscheiden, wer deine Datenbank liest, oder zu lernen, dass bernsteinfarbene Zeilen Rauschen sind, was schlimmer ist.

Zwischen dem 12. und 14. August 2026 haben wir dieselben neun externen Prüfungen über 30.998 aktive Apps laufen lassen, gebaut mit Lovable, Bolt, v0, Replit und Base44. Von den Apps, bei denen diese Prüfung eine Antwort bekam, fehlte 30.756 von 30.981 mindestens ein Header. Die vollständigen Zahlen stehen in unserem Scan-Bericht.

Sind fehlende Sicherheitsheader ein Problem?

Es ist eine echte Lücke und fast immer die unwichtigste Zeile in deinem Bericht.

Ein Sicherheitsheader ist eine kurze Anweisung, die dein Server jeder Seite mitgibt, die er ausliefert, und die sich an den Browser des Besuchers richtet statt an den Besucher. Lass keine andere Website diese Seite in einen Rahmen setzen. Rate nicht, was für eine Art Datei das ist. Gib meine vollständige Adresse nicht weiter, wenn jemand auf einen Link nach draußen klickt. Es sind Notizen an einen Helfer, der tut, was jede Website ihm sagt.

Im Rest deines Berichts geht es um Schlösser. Ob Row Level Security an ist, ob ein geheimer Schlüssel in deinem Code liegt, ob ein Storage-Bucket seinen Inhalt auflistet: das entscheidet, wer überhaupt an deine Daten kommt. Notizen und Schlösser will man beide haben, und die Notiz, die du nie geschrieben hast, ist nicht der Grund, warum Leute eine Datenbank verlieren.

Unsere Bewertung behandelt das genauso. Ein fehlender Header zieht fünf Punkte von hundert ab und deckelt nichts, also kommt eine App, deren einziger Befund dieser ist, mit 95 und der Note A heraus.

Was wir in 30.998 Apps gefunden haben

Fehlende Header tauchten fast überall auf, und sie bewegten sich kaum mit dem Rest des Berichts.

25.821 dieser Apps bekamen von allen neun Prüfungen eine Antwort, und das ist die Gruppe, in der "sonst war nichts" etwas bedeutet. Von ihnen fehlte 25.606 mindestens ein Header, und 215 hatten alle fünf.

Von den 25.606 Apps, denen mindestens ein Header fehlte, hatten 17.043 sonst überhaupt nichts. Zwei von drei. Es war das einzige Problem in ihrem Bericht.

Lies jetzt die andere Zeile, und das ist der Teil, der uns überrascht hat. Von den 215 Apps, die alle fünf Header gesetzt hatten, hatten 145 etwas anderes im Argen. Das ist eine höhere Rate echter Probleme als bei den Apps mit fehlenden Headern, keine niedrigere.

Wir haben nicht gemessen, warum, und die ehrliche Lesart ist eng: was diese Scans sonst noch fanden, der Header-Befund hat es nicht vorhergesagt. Eine App mit einem perfekten Satz Header war in unseren Daten keine sicherere App. Die wahrscheinlichste Erklärung ist, dass Header überhaupt zu setzen bedeutet, dass jemand einen echten Host konfiguriert hat, was meist eine größere App bedeutet, bei der mehr schiefgehen kann, aber das ist eine Vermutung und wir haben sie nicht geprüft.

Wenn du sehen willst, welche dieser Zeilen deine eigene App erzeugt: der Scan ist kostenlos, dauert etwa 20 Sekunden und braucht kein Konto. App scannen.

Was jeder Header tatsächlich tut

Jeder schaltet ein Browser-Verhalten ab, das standardmäßig an ist.

Zwei davon überschneiden sich, und der Scanner rechnet das ein. Eine Content-Security-Policy, die frame-ancestors enthält, erledigt dieselbe Aufgabe wie X-Frame-Options, also zählt unsere Prüfung eines von beiden und verlangt nicht beide.

Wann ein fehlender Header das ganze Problem ist

Wenn es in deiner App etwas gibt, das anzuklicken sich lohnt, während jemand angemeldet ist.

Das ist der Clickjacking-Fall, und er ist der eine, der ohne jeden weiteren Fehler funktioniert. Jemand lädt deine App in einem unsichtbaren Rahmen auf einer Seite, die er kontrolliert, und legt seine eigenen Schaltflächen über deine, sodass ein bereits angemeldeter Besucher klickt, was aussieht wie seine Seite, und stattdessen ein Bedienelement von dir trifft: die Schaltfläche, die ein Konto löscht, eine Überweisung freigibt oder eine E-Mail-Adresse ändert.

Der Besucher ist angemeldet, also trägt die Aktion seine Sitzung. An deiner Datenbank muss nichts falsch konfiguriert sein. Was das möglich macht, ist, dass dem Browser nie gesagt wurde, er solle ablehnen.

Referrer-Policy hat eine kleinere Version derselben Form. Wenn eine angemeldete Seite von dir irgendetwas Identifizierendes in der URL trägt und auf einen Bilder-Host oder ein Analytics-Skript hinauslinkt, reist die ganze Adresse mit dem Klick mit. Wer diesen anderen Server betreibt, sieht, wo dein Nutzer war.

Die anderen drei sind an Bedingungen geknüpft. Sie zählen, wenn schon etwas anderes schiefgegangen ist, und ihre Aufgabe ist, es klein zu halten. Eine Content-Security-Policy begrenzt, was ein eingeschleustes Skript mit seinem Zugriff anfangen kann. X-Content-Type-Options zählt, wenn Fremde Dateien zu dir hochladen können. Strict-Transport-Security deckt jemanden ab, der deine App in einem Netz benutzt, das er nicht kontrolliert.

Brauche ich Sicherheitsheader?

Ja. Sie sind billig, und sie kommen nach den Befunden, die entscheiden, wer deine Datenbank lesen kann.

Die Reihenfolge, die aus der Messung oben folgt: alles Kritische oder Hohe in deinem Bericht zuerst, Header danach. Wenn in deinem Bericht nur diese eine Zeile steht, wie bei 17.043 der Apps, die wir gescannt haben, dann stehen Header ohnehin ganz oben auf deiner Liste.

Zwei der fünf kosten nichts, um sie richtig zu machen. X-Content-Type-Options: nosniff und Referrer-Policy: strict-origin-when-cross-origin sind je eine Zeile, haben keinen falschen Wert zu wählen und können eine funktionierende App nicht kaputt machen. X-Frame-Options: DENY ist ebenfalls eine Zeile und einen Blick wert, falls du deine eigene App absichtlich irgendwo einbettest.

Content-Security-Policy ist der, der echte Arbeit macht. Ein erster Versuch blockiert meist etwas, das deine eigene Seite gebraucht hat, und das Symptom ist eine Funktion, die stillschweigend aufhört zu funktionieren. Bring ihn als Content-Security-Policy-Report-Only aus, der dir meldet, was er blockiert hätte, ohne etwas zu blockieren, und lies eine Woche Meldungen, bevor du ihn einschaltest.

Wie du sie hinzufügst

In dem, was deine App tatsächlich ins Internet ausliefert, und das ist oft nicht der Ort, an dem du sie baust.

Die meisten Builder deployen auf einen Host, dem die Antwort gehört, also liegt die Einstellung dort. Bei Vercel ist es headers in vercel.json. Bei Netlify und Cloudflare Pages ist es eine _headers-Datei im Wurzelverzeichnis deiner veröffentlichten Ausgabe. Hinter Cloudflares Proxy ist es eine Transform Rule. Wenn du deinen eigenen Server betreibst, ist es deine nginx- oder Caddy-Konfiguration.

Was man über Header wissen sollte, sobald man sie gesetzt hat: sie verschwinden wieder, ohne dass jemand sie anfasst. Auf eine eigene Domain umziehen, einen Proxy davorsetzen, den Host wechseln, eine Framework-Konfiguration ändern: die Header, die du hinzugefügt hast, liegen an einer dieser Stellen, und jeder dieser Schritte kann sie zurücklassen. Nichts sagt es dir. Die Seite funktioniert weiter, und die Einstellung ist weg.

Für so etwas gibt es Reeve Monitor. Es lässt die vollständige Prüfung jede Stunde für bis zu drei Apps neu laufen, beobachtet die Erreichbarkeit alle 60 Sekunden und sagt dir Bescheid, wenn sich ein Ergebnis ändert, statt zu warten, bis du nachsiehst. Monitor beobachtet und sonst nichts. Wenn du also zusätzlich eine Kopie deiner Datenbank irgendwo haben willst, wo dein Builder nicht hinkommt, dann ist das Care, und es deckt Supabase ab.

Was du jetzt tun kannst

Header sind einen ruhigen Nachmittag wert, sobald der Rest des Berichts sauber ist. Wenn du die ganze Liste lieber der Reihe nach durchgehst: die 10-Minuten-Sicherheitscheckliste deckt ab, was in einer frisch gestarteten App abzuschalten ist, und die Befunde, die tatsächlich entscheiden, wer deine Datenbank liest, sind die, die zuerst weg müssen.