horizonchapter/checklist-lancement-web

Checkliste für den Web-Launch

Ziel: Niemals eine Website, einen Shopify-Shop, eine App oder einen SaaS mit einer Sicherheitslücke, einem rechtlichen Mangel oder einem defekten Kaufprozess veröffentlichen. Der Launch bleibt eine Entscheidung des Nutzers: Du prüfst und bereitest vor, du veröffentlichst nichts.

Entscheidungsregel (blockierend)

NICHT VERÖFFENTLICHEN, wenn einer dieser Punkte bestehen bleibt:

• Ein privater Schlüssel oder Geheimnis ist exponiert (Frontend-Code, Git-Repository, Build).
• Ein Benutzer kann die Daten eines anderen lesen oder ändern.
• HTTPS fehlt oder ist defekt.
• RLS (oder die Entsprechung) fehlt oder ist falsch konfiguriert bei privaten Daten.
• Zustimmungspflichtige Tracker werden vor der Einwilligung gesetzt.
• Gebühren sind versteckt oder irreführend.
• Der Kauf- oder Zahlungsprozess ist defekt.

Methode

1. Identifiziere den Projekttyp (Visitenkarten-Website, Shop, App mit Konten, SaaS mit Zahlung) und ignoriere die nicht zutreffenden Prüfungen, indem du dies erwähnst.
2. Gehe die 5 Blöcke unten in der Reihenfolge durch. Für jede Prüfung: Status OK / ZU KORRIGIEREN / NICHT ANWENDBAR / NICHT ÜBERPRÜFBAR, mit dem Nachweis oder dem durchgeführten Test.
3. Wenn du Zugriff auf den Code oder die Datenbank hast (Supabase, Vercel, Shopify), überprüfe selbst; andernfalls gib dem Nutzer den genauen Test, den er durchführen soll.
4. Beende mit dem Bericht (Format unten).

Block 1 — Technische Sicherheit

• HTTPS für die gesamte Domain, HTTP umgeleitet, kein gemischter Inhalt; HSTS erst nach Validierung. Test: http:// leitet weiter.
• Sicherheitsheader: CSP angepasst, nosniff, Referrer-Policy, iframe-Schutz. Test: SecurityHeaders.com.
• Secrets nur serverseitig (private Schlüssel, Zahlungstoken, geheime API-Schlüssel). Test: Build-JS und Git-Repository ohne Secret.
• Serverseitige Validierung (Typ, Größe, Felder); alleinige Frontend-Validierung kann umgangen werden. Test: Eine modifizierte Anfrage wird abgewiesen.
• Rechte für jede Ressource: Identität UND Zugriffsrecht auf jedes Objekt. Test: Konto B liest oder ändert nichts von A.
• SQL-Injection / XSS: parametrisierte Abfragen, Framework-Escaping, niemals rohes Benutzer-HTML. Test: HTML-Text wird angezeigt, aber nicht ausgeführt.
• CSRF und Cookies: Secure, HttpOnly, SameSite, Anti-CSRF-Schutz bei Cookie-Authentifizierung.
• Abhängigkeiten aktuell, keine kritischen Warnungen, unnötige Pakete entfernt.
• CORS auf die notwendigen Ursprünge beschränkt (keine Zugangsbarriere).
• Upload kontrolliert: Größe, tatsächliches Format, Erweiterungen, Umbenennung, isolierte Speicherung.
• Anti-Missbrauch: Rate Limiting bei Anmeldung, E-Mails und Formularen; Turnstile oder CAPTCHA falls nötig.
• Admin-Konten: MFA, eingeschränkter Zugriff, kein internes Panel sichtbar.
• Produktionsmodus: kein Debug, kein veröffentlichtes .env, keine ausführlichen Logs.
• E-Mails mit der Domain gesendet: SPF, DKIM, DMARC.

Block 2 — Daten (Supabase oder Äquivalent)

• Publishable/anon-Schlüssel nur im Browser, wenn RLS korrekt ist; service_role-Schlüssel nur serverseitig.
• RLS auf allen exponierten Tabellen aktiviert, unnötige Rechte für anon/authenticated entfernt.
• Richtlinien pro Aktion (SELECT, INSERT, UPDATE, DELETE) verknüpft mit auth.uid(); positive UND negative Tests mit drei Profilen: Besucher, Benutzer A, Benutzer B.
• Storage-Buckets mit angepassten Regeln (ein öffentlicher Avatar hat nicht die Rechte einer Rechnung).
• Auth: erlaubte Weiterleitungs-URLs, Sitzungsablauf, Zurücksetzen und Abmelden getestet.
• Security Advisor: keine unbehandelten kritischen Warnungen.
• Backups: tatsächliche Optionen überprüft, Wiederherstellung getestet.
• Logs und Alarme (5xx-Fehler, Kontingente) ohne jemals Passwörter oder Token zu protokollieren.
• Getrennte Umgebungen (lokal, Staging, Produktion) und Rollback bereit.

Block 3 — Recht und Vertrauen (Frankreich / EU, je nach Tätigkeit zu prüfen)

• Impressum (Identität, Kontaktdaten), Datenschutzerklärung (Daten, Zwecke, Rechtsgrundlage, Aufbewahrung, Rechte, Kontakt).
• AGB; Kaufbedingungen bei Verkauf; Rückerstattungen und Widerrufsrecht (Online-Widerrufsfunktion ab 19.06.2026 für betroffene Verträge); Verbraucherschlichtungsstelle.
• Cookies: Richtlinie, Banner mit gleich einfachem Ablehnen wie Akzeptieren, keine Tracker vor Einwilligung, Wahlmöglichkeit auf jeder Seite änderbar.
• Formulare: Information bei Erhebung, abgewählte Kästchen, Datenminimierung, Löschfristen.
• Inventar der Drittanbieter-Tools (Analytics, Pixel, Chat, CAPTCHA, KI) und der Transfers außerhalb der EU.
• Keine Dark Patterns, keine falsche Dringlichkeit, keine versteckten Kosten (Bruttopreise, Versand, Abonnement vor Zahlung angezeigt).
• Keine falschen Bewertungen, keine nicht nachweisbaren Versprechen oder Zahlen.
• Lizenzen für Bilder, Icons, Videos, Schriftarten.
• Minderjährige: In Frankreich gemeinsame Zustimmung unter 15 Jahren, wenn die Verarbeitung auf Einwilligung beruht.
• Funktionsfähiger Abmelde-Link in Werbe-E-Mails; Verfahren zur Kontolöschung.
• Datenleck-Verfahren (CNIL-Benachrichtigung innerhalb von 72 Stunden bei Risiko).

Block 4 — UX, SEO und Conversion

• Ein klarer primärer CTA, mit dem Daumen auf dem Handy bedienbar.
• Einzigartiger Title und nützliche Meta-Beschreibung pro Seite; og:image getestet; Favicon.
• sitemap.xml, robots.txt, canonical, noindex für private Seiten; Search Console.
• Individuelle 404-Seite, die korrekt den Status 404 zurückgibt; defekte Links überprüft.
• FAQ zu den tatsächlichen Einwänden; eingehaltene Versprechungen; Dankesseite nach Aktion.
• Barrierefreiheit: Kontrast, Tastaturnavigation, sichtbarer Fokus, Alternativtexte, Zoom 200 %.
• Performance: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 (PageSpeed mobil und Desktop); komprimierte Bilder.

Block 5 — Echte Tests vor der Veröffentlichung

• Formulare: leer, ungültig, zu lang, Serverfehler, Doppelklick, Erfolg, Empfang, Mobil.
• Kauf im Testmodus mit anschließender Rückerstattung; Bruttopreis, Gesamtsumme, Rechnung korrekt.
• E-Mails tatsächlich empfangen (Registrierung, Zurücksetzen, Rechnung, Support).
• Webhooks: Signatur überprüft, Wiederholung ohne Duplikat.
• Privater Modus: keine Tracker vor Einwilligung gesetzt.
• Domain und DNS durch MFA geschützt; Rückkehr zur stabilen Version möglich.

Format des Berichts

1. Urteil in einer Zeile: BEREIT ZUR VERÖFFENTLICHUNG / VOR VERÖFFENTLICHUNG ZU KORRIGIEREN / BLOCKIERT (blockierender Punkt genannt).
2. Blockierende Punkte, dann nach Schweregrad geordnete zu korrigierende Punkte, jeweils mit der genauen Korrektur und wo sie durchzuführen ist.
3. Nicht überprüfbare Punkte und der Test, den der Nutzer durchführen muss.
4. Erinnerung: Der Nutzer veröffentlicht selbst. Für rechtliche Fragen ersetzt diese Prüfung keinen Fachmann.