So erkennst du in 5 Minuten, ob deine Website sicher ist

Du musst kein Sicherheitsexperte sein, um zu wissen, ob deine Website die häufigsten Schwachstellen hat. Mit einem Browser, einem Terminal und fünf Minuten kannst du prüfen, was ein automatisierter Angreifer in den ersten Sekunden ausprobiert: ob der Verkehr verschlüsselt ist, ob Header fehlen, ob Schlüssel im Code stecken, ob deine API Anfragen von überall akzeptiert und ob Dateien da sind, die dort nicht hingehören. Dieser Guide führt dich Schritt für Schritt, mit dem exakten Befehl, was jedes Ergebnis bedeutet und was du je nach Fund tust. Am Ende steht, wie du priorisierst und was dieser Test nicht erkennt.

Minute 1: HTTPS und Weiterleitung

Tipp deine Domain mit http:// davor ein, ohne das s. Sie muss dich sofort zur https://-Version bringen. Im Terminal:

curl -sI http://deinedomain.com | head -3
curl -sI http://deinedomain.com/preise | head -3

Beide Antworten müssen ein 301 mit Location: https://... sein. Leitet die zweite nicht um, deckt deine Weiterleitung nur die Startseite ab. Schau danach mit https://, ob der Header Strict-Transport-Security erscheint: Er sagt dem Browser, nie wieder HTTP zu nutzen. Bei Vercel, Netlify oder Cloudflare ist die Weiterleitung schon da, HSTS musst du selbst ergänzen. Was jedes Detail des Zertifikats bedeutet, steht in was deine TLS-Note wirklich bedeutet.

Minute 2: Sicherheits-Header

curl -sI https://deinedomain.com | grep -iE "strict-transport|content-type-options|frame-options|referrer-policy|content-security-policy|permissions-policy"

Es sollten mindestens fünf Zeilen herauskommen. Jede fehlende ist ein Schutz, den der Browser nicht anwenden kann: Ohne X-Frame-Options lässt sich deine Website in eine andere einbetten, um deine Nutzer zu täuschen; ohne X-Content-Type-Options rät der Browser Dateitypen; ohne Content-Security-Policy läuft jedes eingeschleuste Skript ungebremst. Wenn du das Terminal nicht magst, füg deine URL in den Header-Analyzer ein. Die Bedeutung jedes einzelnen steht in HTTP-Header für Menschen erklärt.

Minute 3: Geheimnisse im JavaScript

Öffne deine Website, Rechtsklick, „Seitenquelltext anzeigen". Such nach .js, um zu sehen, welche Skriptdateien geladen werden, öffne die Hauptdatei und nutz die Browser-Suche mit diesen Begriffen:

sk_live   sk_test   service_role   AKIA   eyJhbGci   api_key   apiKey   secret   password

Im Terminal geht das in einem Rutsch über alle Skripte der Startseite:

curl -s https://deinedomain.com/ | grep -oE 'src="[^"]+\.js[^"]*"' | cut -d'"' -f2 | while read s; do
  case "$s" in http*) u="$s";; /*) u="https://deinedomain.com$s";; *) u="https://deinedomain.com/$s";; esac
  curl -s "$u" | grep -oE "sk_live_[A-Za-z0-9]+|service_role|AKIA[A-Z0-9]{16}|eyJhbGciOi[A-Za-z0-9_-]{20,}" | head -3
done

Manches ist normal zu finden: Der öffentliche Stripe-Schlüssel (pk_live), der anon-Schlüssel von Supabase oder die Firebase-Konfiguration sind dafür gemacht, im Browser zu liegen. Was nie erscheinen darf: sk_live, service_role, AWS-Schlüssel (AKIA), OpenAI-Tokens oder irgendetwas, das secret heißt. Findest du so etwas, betrachte es als kompromittiert und rotiere es, bevor du es aus dem Code entfernst. Die vollständige Liste steht in Geheimnisse, die deine App im Browser preisgibt.

Minute 4: CORS und Cookies

CORS entscheidet, welche anderen Websites aus dem Browser Anfragen an deine API stellen dürfen. Fordere einen deiner Endpunkte an und tu so, als kämst du von einer anderen Domain:

curl -sI -H "Origin: https://evil.example" https://deinedomain.com/api/me | grep -i "access-control"

Antwortet er mit Access-Control-Allow-Origin: https://evil.example oder * zusammen mit Access-Control-Allow-Credentials: true, kann jede Website die Daten deiner Nutzer mit deren Sitzung lesen. Der erlaubte Origin muss deiner sein und nur deiner. Wo du schon dabei bist, schau dir die Cookies in der Login-Antwort oder in den Browser-Tools an: Sitzungs-Cookies brauchen Secure, HttpOnly und SameSite=Lax oder Strict. Details in falsch konfiguriertes CORS.

Minute 5: offengelegte Dateien

Tools und halbfertige Deployments hinterlassen Spuren. Probier diese Pfade und schau, welchen Code sie liefern:

for p in .env .env.local .env.production .git/config .DS_Store config.json backup.zip database.sql phpinfo.php server-status api/debug api/seed swagger.json; do
  printf "%-20s " "$p"; curl -s -o /dev/null -w "%{http_code}\n" "https://deinedomain.com/$p"
done

Was du sehen willst, ist 404 (oder 301 auf deine Fehlerseite). Ein 200 bei .env oder .git/config ist ernst: Die erste enthält deine Zugangsdaten, die zweite erlaubt, den kompletten Quellcode herunterzuladen. Ein 200 bei swagger.json oder api/debug ist an sich kein Leak, gibt einem Angreifer aber die Landkarte deiner API.

Bonusminute: was die Bots sehen

Bleibt dir eine Minute, schau dir /robots.txt und /sitemap.xml an: dass sie existieren, dass sie nicht alle aussperren und dass die Sitemap nur Seiten enthält, die du indexiert haben willst. Das ist keine Sicherheit im engeren Sinn, aber ein aus der Testphase vergessenes Disallow: / kostet Monate an Ranking.

Wie du priorisierst, was du findest

Nicht alles wiegt gleich. Das ist die Reihenfolge, die wir nutzen:

Kritisch, noch heute. Ein geheimer Schlüssel im JavaScript; .env oder .git erreichbar; eine API, die jeden Origin mit Credentials akzeptiert. Rotieren, löschen, schließen. Danach prüfen, ob jemand es genutzt hat.
Hoch, diese Woche. Keine Weiterleitung auf HTTPS; Sitzungs-Cookies ohne HttpOnly oder Secure; Debug-Routen in Produktion.
Mittel, diesen Monat. Fehlende Header; kein HSTS; Zertifikat, das bald abläuft, ohne automatische Erneuerung.
Niedrig. Offengelegte API-Dokumentation, vernachlässigte robots.txt und sitemap, Header, die die Serverversion verraten.

Was diese fünf Minuten nicht erkennen

Sei ehrlich mit den Grenzen. Dieser Test betrachtet die Oberfläche, die jeder von außen sehen kann. Er prüft nicht, ob deine Datenbank Zeilen anderer Nutzer lesen lässt (bei Supabase ist das RLS, bei Firebase sind es die Regeln), ob deine Abhängigkeiten bekannte Schwachstellen haben, ob deine Geschäftslogik erlaubt, eine Zahlung zu überspringen, oder ob ein Formular jede Eingabe akzeptiert. Für Ersteres erklären der Supabase-Guide und der zu Firebase, wie du es testest. Für den Rest musst du in den Code schauen, und die Checkliste vor dem Launch versammelt das Wesentliche.

Scanaris macht das und vierzig weitere Dinge in 30 Sekunden

Die fünf Schritte oben sind der Kern dessen, was Scanaris prüft, plus rund vierzig Tests, die nicht in fünf Minuten passen: jeder Header einzeln, Geheimnisse mit Mustern von Dutzenden Diensten, offengelegte Dateien mit einer viel längeren Liste, vollständiges TLS, Cookies, CORS auf mehreren Routen und dazu den Zustand deines SEO und deiner KI-Sichtbarkeit. Für jeden Fehler bekommst du einen Fix-Prompt zum Einfügen in Lovable, Bolt, Cursor oder v0 mit der exakten Änderung, und es kann den Scan täglich wiederholen und dich warnen, wenn sich etwas verschlechtert. Alles reine Lesezugriffe auf das, was auf deiner Website schon öffentlich ist.

Häufige Fragen

Ist es legal, meine eigene Website so zu scannen?

Ja. Alles hier sind normale Anfragen, wie sie jeder Browser stellt; du liest nur, was dein Server ohnehin jedem antwortet. Mach es ausschließlich auf eigenen Domains oder mit Erlaubnis.

Und wenn ich das Terminal nicht bedienen kann?

Die Schritte 1, 3 und 5 gehen im Browser (URLs eintippen und Quelltext anzeigen), Schritt 2 mit dem kostenlosen Header-Analyzer, und Schritt 4 ist der einzige, der es braucht. Oder du lässt einen Scanner das für dich erledigen.

Wie oft sollte ich es wiederholen?

Bei jedem relevanten Deployment und mindestens einmal im Monat. Mit KI gebaute Apps ändern sich schnell, und eine Code-Neugenerierung kann einen Fehler wieder einbauen, den du schon behoben hattest.