Diese Seite beschreibt die Maßnahmen, auf die der Auftragsverarbeitungsvertrag verweist. Sie ist so geschrieben, dass man sie überprüfen kann: Jede Maßnahme nennt, was sie durchsetzt. So kann die Sicherheitsprüfung eines Interessenten kontrollieren, statt nur zu vertrauen.

Verschlüsselung

Der gesamte Datenverkehr läuft über TLS. OAuth-Tokens von Drittanbietern (Shopify, Google, Meta, Klaviyo, Notion, Figma) werden mit AES-256-GCM verschlüsselt gespeichert, mit einem Schlüssel, der rotiert werden kann. Ein Datenbank-Dump liefert also keine brauchbaren Zugangsdaten. Berichte aus der Identitätsprüfung werden nach demselben Verfahren verschlüsselt und im Produkt nie angezeigt.

Mandantentrennung

Jede Abfrage, die auf Daten einer Organisation oder eines Shops zugreift, wird auf die Mitgliedschaft eingegrenzt. Diese Eingrenzung sichern Tests ab, die den Build abbrechen, nicht bloß die Sorgfalt beim Review. Die Rollen sind Inhaber, Admin, Mitglied und Betrachter, und Berechtigungen werden bei jeder Anfrage auf dem Server geprüft, nie im Client.

Authentifizierung

Die Anmeldung erfolgt mit einem sechsstelligen Einmalcode per E-Mail. Es gibt kein Passwort, das abhandenkommen kann, und keinen Magic Link, den man weiterleiten könnte. Sitzungen liegen in einem Cookie mit dem Präfix __Secure-, laufen nach 30 Tagen ab und verkürzen sich auf 24 Stunden, wenn du dich anmeldest, ohne angemeldet bleiben zu wollen.

Audit-Protokoll

Sicherheits- und Abrechnungsereignisse werden in ein unveränderliches Protokoll geschrieben, das du in der Aktivität deines Kontos einsehen kannst. Administrative Aktionen der Plattform werden separat erfasst. Rohdaten von Webhooks werden früher gelöscht als die Ereignisse selbst: Das Protokoll bleibt, die Rohdaten nicht.

Secrets

Keine Zugangsdaten liegen im Repository. Das Betreiber-Dashboard zur Umgebungskonfiguration zeigt nur, ob ein Schlüssel gesetzt ist, nie seinen Wert. Ein Test lehnt jeden Wert in der versionierten MCP-Konfigurationsdatei ab, der wie ein Secret aussieht.

Integrität und Änderungskontrolle

Änderungen am Datenbankschema werden automatisch abgeleitet und idempotent angewendet. Eine Prüfung lehnt jede Änderung ab, die in der Produktion scheitern könnte, sobald eine Tabelle Zeilen enthält. Ein Pre-Push-Hook führt schnelle Offline-Prüfungen aus (Schema, Angaben in der Dokumentation, Texte, Versionen), bevor eine Änderung das Remote-Repository erreicht. Lint, Typprüfung und die komplette Testsuite laufen in der CI bei jedem Pull Request. Auch die Dokumentation, die du gerade liest, wird geprüft: Veröffentlichte Zahlen werden mit dem Code abgeglichen, der sie umsetzt.

Infrastruktur

Die Plattform läuft auf Vercel mit einer verwalteten PostgreSQL-Datenbank bei Neon, die fortlaufende Backups und die Wiederherstellung zu einem beliebigen Zeitpunkt bietet. Cache und Warteschlangen laufen auf Upstash. Zahlungen berühren unsere Server nie: Kartendaten verarbeitet Stripe. Die Region jedes Anbieters steht auf der Seite zu den Unterauftragsverarbeitern.

Überwachung

Die Plattform veröffentlicht eine Live-Statusseite mit 90 Tagen Historie und einem monatlichen Verfügbarkeitsbericht. Störungen werden dort gemeldet, mit RSS-Feed und E-Mail-Abo. Probleme auf Plattformebene (Registrierungen, fehlgeschlagene Zahlungen) gehen stündlich als Zusammenfassung an den Betreiber.

Eine Schwachstelle melden

Schreib an contact@boostecom.app, mit genug Details, um das Problem nachzustellen. Wir bestätigen den Eingang innerhalb von drei Werktagen. Gegen Forschung in gutem Glauben, die die Privatsphäre der Nutzer respektiert, keine Daten zerstört und den Dienst nicht beeinträchtigt, gehen wir nicht rechtlich vor. Teste bitte nicht am Konto oder Shop eines anderen Nutzers.

Zuletzt aktualisiert 12. September 2026