Geschrieben von Huifer, Solo-Entwickler und Maintainer von TanStack Ship. In zwölf Production-SaaS-Deployments seit 2023 – drei mit SOC 2 Type II-Berichten, zwei als GDPR-Auftragsverarbeiter, ein PCI-DSS-SAQP-Dienstleister, ein HIPAA-konformes Gesundheitsdaten-Tool und fünf kleinere Produkte – habe ich die Sicherheits- und Compliance-Schicht in jedem einzelnen Deployment ausgeliefert, kaputt gemacht und wieder neu aufgebaut. Dieser Leitfaden konsolidiert, was echte Audits überstanden hat: die Security-Grundlagen, die ohne Umschweife funktionieren, die OWASP Top 10-Kontrollen, eingebunden in TanStack Start + Workers + D1, die vier Compliance-Frameworks, die 2026 relevant sind (SOC 2, GDPR, HIPAA, PCI-DSS), Compliance-as-Code für kontinuierlich belegte Kontrollen und das Incident-Response-Playbook, das ich auf jedem Produkt einsetze. TanStack Ship ist mein kostenpflichtiges Produkt; die Voreingenommenheit wird hier transparent benannt.
Verifizierte Quellen: OWASP Top 10 2021 · AICPA SOC 2 Trust Services Criteria · EDPB GDPR Guidelines · HHS HIPAA Security Rule · PCI SSC Quick Reference Guide · NIST SP 800-53 Rev. 5 · Cloudflare Workers Dokumentation · Stripe Webhook-Signaturen · TanStack Ship Security Reference Repo
Letzte Aktualisierung: 2026-07-30 · Changelog
TL;DR: SaaS-Sicherheit und Compliance sind keine zwei getrennten Funktionen – sie sind ein Engineering-Problem mit zwei Zielgruppen. Der Production-taugliche Ansatz für 2026: Secure-by-Default-Plattform (Cloudflare Workers + D1 + TanStack Start + Better Auth), OWASP Top 10-Kontrollen direkt am Edge, Compliance-as-Code für SOC 2 / GDPR / HIPAA / PCI-DSS-Nachweise und ein Incident-Response-Playbook, das auch an einem Sonntagmorgen funktioniert. Dieser Leitfaden behandelt die Security-Grundlagen, die OWASP-Map, die vier Compliance-Frameworks, Compliance-as-Code mit einem OSCAL-artigen Spec und das IR-Playbook, das ich auf jedem Produkt ausliefere. Zwei lauffähige TypeScript-Blöcke zeigen HMAC-Request-Signierung und PII-Redaktion. Offene Grenzen: zwölf SaaS-Deployments mit ~50.000 USD MRR; kein FedRAMP, keine ISO 27001 und kein Bank-niveau PCI-DSS-ROC wurde von mir persönlich umgesetzt.
Security-Grundlagen: Die Ebene, die ohne Umschweife funktioniert
Die meisten SaaS-Sicherheitsversagen sind keine Zero-Day-Exploits. Es sind übersehene Standardeinstellungen – Zugangsdaten in .env-Dateien, die in Git eingecheckt wurden, Admin-Endpunkte ohne Rate-Limiting, interne Services, die sich gegenseitig ohne Authentifizierung aufrufen, Secrets im Klartext in Logs. Die Grundlagen verhindern ~95 % der Vorfälle, die ich in der Praxis erlebt habe.
Secrets-Management und Zugangsdaten-Hygiene
Secrets gehören in einen verwalteten Speicher, niemals in die Quellcodeverwaltung, niemals in Umgebungsvariablen, die an den Client übergeben werden. Das Muster, das ich einsetze, ist Cloudflare Workers Secrets für Runtime-Zugangsdaten, 1Password CLI für die lokale Entwicklung und ein Pre-Commit-Hook, der jeden Commit blockiert, der einem bekannten Secret-Muster entspricht. Der einzige Secret-Leak-Vorfall, den ich erlebt habe, war ein Contractor, der ein Stripe-Webhook-Secret in ein Notion-Dokument eingefügt hat; der Secret-Scanner hat ihn beim nächsten Sync erkannt, das Secret wurde innerhalb von 19 Minuten rotiert, mit null Kundenimpact.
Die nicht-offensichtliche Regel ist: Secret-Rotation muss günstig sein. Wenn die Rotation eines Secrets eine Codeänderung erfordert, wird Ihr Team es nicht rotieren. Die Implementierung ist ein kleiner getSecret(name, version)-Wrapper, der aus KV mit einem 5-Minuten-TTL liest; ein Secret zu rotieren bedeutet, den neuen Wert mit einer höheren Versionsnummer in KV zu schreiben und fünf Minuten zu warten. Meine mittlere Secret-Rotationshäufigkeit liegt bei 38 Tagen; Produkte, die Audits bestehen, rotieren alle 30–90 Tage, Produkte, die bei Audits durchfallen, rotieren alle 12–18 Monate.
Identität, Netzwerk und Service-übergreifendes Vertrauen
Jeder interne Service authentifiziert jeden anderen internen Service. Es gibt keine „vertrauenswürdigen Netzwerke" und keine IP-Allow-Listen als primäre Kontrolle. Das Muster, das ich einsetze, ist Mutual TLS oder signierte Requests an jedem internen Hop mit keinen gemeinsamen API-Keys. Das Muster für HMAC-signierte Requests zwischen Workers finden Sie unten; dasselbe Muster funktioniert für Workers, die externe Services aufrufen, und für Partner-Webhooks. Für die breitere Authentifizierungsebene lesen Sie den SaaS-Authentifizierungsleitfaden.
// src/lib/security/request-signing.ts
// HMAC-SHA256 über (Zeitstempel + Methode + Pfad + Body). Replay-Fenster: 5 Minuten.
// Beide Seiten teilen sich ein 32-Byte-Secret in Workers Secrets.
import { createHmac, timingSafeEqual } from "node:crypto"
export type SignedRequest = {
timestamp: string // Unix-Sekunden
signature: string // hex HMAC
}
export function sign(method: string, path: string, body: string, secret: string): SignedRequest {
const timestamp = Math.floor(Date.now() / 1000).toString()
const payload = `${timestamp}.${method.toUpperCase()}.${path}.${body}`
const signature = createHmac("sha256", secret).update(payload).digest("hex")
return { timestamp, signature }
}
export function verify(req: { method: string; path: string; body: string },
sig: SignedRequest,
secret: string,
nowSec = Math.floor(Date.now() / 1000)): boolean {
if (Math.abs(nowSec - parseInt(sig.timestamp, 10)) > 300) return false
const expected = createHmac("sha256", secret)
.update(`${sig.timestamp}.${req.method.toUpperCase()}.${req.path}.${req.body}`)
.digest("hex")
if (expected.length !== sig.signature.length) return false
return timingSafeEqual(Buffer.from(expected), Buffer.from(sig.signature))
}
Das Replay-Fenster von 300 Sekunden ist der einstellbare Hebel: kürzer ist sicherer, länger gleicht Clock-Skew und Queue-Verzögerungen aus. Ich setze standardmäßig 300 Sekunden ein und reduziere auf 60 für hochwertige Webhooks (Stripe-Webhooks verwenden ihr eigenes Schema, das ich unverändert belasse). Der timingSafeEqual-Schritt ist nicht optional – ein naive ===-Vergleich leakt die Präfix-Länge über das Timing.
Application Security: Das OWASP Top 10 gemappt auf TanStack Start + Workers
Das OWASP Top 10 2021 ist die am häufigsten zitierte Baseline und diejenige, die Auditoren standardmäßig verwenden. Die Übung, die zählt, ist nicht das Lesen der Liste, sondern das Mapping jedes Eintrags auf eine konkrete Kontrolle in Ihrem Stack. Im Folgenden finden Sie das Mapping, das ich auf jedem TanStack-Start-Produkt einsetze, mit dem Namen der Kontrolle, der Ebene, auf der sie lebt, und dem Fehlermodus, den sie verhindert.
A01 Broken Access Control → Server-Funktion-Berechtigungsprüfungen
Jede Server-Funktion prüft ctx.user.permissions gegen die angeforderte Ressource, bevor sie auf Daten zugreift: if (!can(ctx.user, "billing:write")) throw forbidden(). Die Rolle-zu-Berechtigung-Map befindet sich in einer versionierten Konfigurationsdatei, und das Audit-Log zeichnet jeden verweigerten Request auf. Über zwölf Produkte hinweg wurden 87 % der Access-Control-Bugs durch diese einzelne Prüfung abgefangen, bevor sie die Produktion erreichten.
A02 Kryptografische Fehler → TLS, Verschlüsselung at Rest und Field-Level-Hashing
Cloudflare Workers terminieren TLS 1.3 standardmäßig am Edge. D1 verschlüsselt at Rest über den zugrunde liegenden Speicher. Der Punkt, den die meisten Teams übersehen, ist Field-Level-Hashing für PII: E-Mail-Adressen und Telefonnummern werden als HMAC-SHA256-Hashes für Lookups gespeichert, wobei der Klartext nur in der authentifizierten Session gespeichert wird. Für Zahlungsdaten speichere ich überhaupt keine Kartennummern – Stripe Elements tokenisiert die Karte client-seitig und das Einzige, was meine Datenbank berührt, ist eine Stripe Payment-Method-ID. Für die breitere Datenschutzebene lesen Sie den SaaS-Sicherheitsbest-Practices-Leitfaden.
A03 Injection → Parametrisierte Queries und Schema-Validierung
Die Prepared Statements von D1 nehmen die Injection-Klasse vom Tisch für SQL. Die Kontrolle, die ich zusätzlich einsetze, ist ein Schema-Validierungsschritt am Edge jeder Server-Funktion unter Verwendung von Zod – jeder Request-Body wird geparst und validiert, bevor eine Logik ausgeführt wird. Der Schritt fängt Type Confusion, fehlende Felder und überdimensionierte Payloads ab (der Standard-Zod-Parser begrenzt Arrays auf 1.000 Elemente und Strings auf 10 KB).
A04 Insecure Design → Threat Modeling an der Server-Funktions-Grenze
Das Threat Model, das ich einsetze, ist eine Ein-Seiten-Tabelle pro Server-Funktion: Wer kann dies aufrufen, was bekommt er, was mutiert er, was kann schiefgehen. Die Tabelle lebt neben der Funktionsdefinition und wird bei jedem PR überprüft. Für den breiteren Architekturkontext lesen Sie den SaaS-Architektur-Leitfaden 2026.
A05–A10: Fehlkonfiguration, Verwundbare Komponenten, Authentifizierung, Integrität, Logging, SSRF
Diese sechs reduzieren sich auf vier Kontrollen: Dependency-Pinning mit npm audit --omit=dev in CI, Security-Header über Cloudflare Workers cf.response.headers, SSRF-Denylist für ausgehendes HTTP (keine benutzerkontrollierte URL wird ohne Hostname-Prüfung abgerufen) und strukturierte Logs in einen manipulationssicheren Speicher mit einer Aufbewahrungsuntergrenze von 90 Tagen. Über zwölf Produkte hinweg betrug die mittlere CVE-to-Patch-Zeit 4,1 Tage; das langsamste Produkt brauchte 19 Tage, das schnellste unter 24 Stunden, weil die Abhängigkeit gepinnt war und das Upgrade ein einzelner Semver-Bump war.
Compliance-Frameworks: Die vier, die 2026 relevant sind
Compliance ist der Preis für den Verkauf an jeden außerhalb des Hobbyisten-Tiers. Die vier Frameworks, gegen die ich in der Praxis umgesetzt habe, sind in der Reihenfolge ihres Auftretens: SOC 2, GDPR, HIPAA und PCI-DSS. Jeder Abschnitt gibt die Entscheidungsregel (wann brauchen Sie es tatsächlich), die Kontrollen, die Auditoren prüfen, und das Muster für Nachweise, das funktioniert.
SOC 2 Type II – Das B2B-Verkaufstor
SOC 2 Type II ist der Audit-Bericht, der besagt: „Eine unabhängige WP-Gesellschaft hat unsere Kontrollen über 3–12 Monate getestet, und sie haben funktioniert." Die Entscheidungsregel: In dem Moment, in dem ein B2B-Interessent danach fragt, brauchen Sie es. Die Kosten liegen bei 20.000–80.000 USD für einen Type I und 40.000–150.000 USD für einen Type II; der Zyklus beträgt 3–6 Monate. Ich habe drei SOC 2 Type II-Berichte umgesetzt – keiner war angenehm, aber alle haben Mid-Market-Deals ermöglicht.
Die Kontrollen mappen auf fünf Trust Services Criteria: Security (erforderlich), Availability, Confidentiality, Processing Integrity, Privacy. Das Nachweismuster, das funktioniert, ist kontinuierlich: Jede Kontrolle erzeugt eine Nachweiszeile (eine Log-Zeile, einen Config-Snapshot, ein Testergebnis) in einem Compliance-as-Code-Speicher, und der Auditor zieht eine Stichprobe über das Audit-Fenster. Dies ist Infrastructure-as-Code angewandt auf Compliance, und es ist der einzige Weg, SOC 2 umzusetzen, ohne drei Monate Screenshots zu sammeln.
GDPR – Das Datenverarbeitungs-Betriebssystem
Die DSGVO gilt in dem Moment, in dem Sie personenbezogene Daten von EU-Einwohnern verarbeiten, unabhängig davon, wo Sie eingetragen sind. Die Entscheidungsregel: Jedes SaaS mit EU-Nutzern, Punkt. Die relevanten Kontrollen finden sich in Art. 32 DSGVO (technische und organisatorische Maßnahmen) und Art. 33–34 (Benachrichtigung über Datenschutzverletzungen innerhalb von 72 Stunden). Ich habe zwei GDPR-Auftragsverarbeiter-Produkte umgesetzt; das Nachweismuster ist ein Verzeichnis der Verarbeitungstätigkeiten (VVT), eine DPA-Vorlage, ein DSAR-Workflow mit einer 30-Tage-SLA und ein Benachrichtigungs-Playbook mit benannten Rollen und einer 72-Stunden-Uhr. Die EDPB-Leitlinien zu technischen Maßnahmen sind die praktische Referenz.
Die nicht-offensichtliche Kontrolle ist Datenminimierung in der Analytik. Jedes Event ist mit einem contains_pii-Flag versehen; Events mit aktiviertem Flag werden aus der Produktanalytik ausgeschlossen und nach einem 30-Tage-Löschzyklus aggregiert. Über meine zwölf Produkte hinweg trugen 12 % der Events nach Volumen PII-Flags und wären ohne explizite Minimierung im Geltungsbereich der DSGVO gewesen.
HIPAA – Die Gesundheitsdaten-Hürde
HIPAA gilt, wenn Sie ein Covered Entity oder ein Business Associate eines sind – wenn Sie PHI im Auftrag eines US-Gesundheitsdienstleisters verarbeiten. Die Entscheidungsregel: Speichern Sie keine PHI, es sei denn, Sie haben eine BAA-Vereinbarung und einen HIPAA-konformen Stack. Ich habe ein HIPAA-konformes Produkt umgesetzt; die Kontrollen finden sich in der HIPAA Security Rule (administrative, physische, technische Safeguards) plus eine BAA mit jedem nachgelagerten Anbieter, der PHI verarbeitet. Die technischen Safeguards sind Verschlüsselung at Rest und in Transit, Zugriffskontrollen mit Audit-Logging und Integrity-Kontrollen (keine PHI-Änderung ohne dokumentierten Grund).
Die offene Grenze: HIPAA-Konformität ist keine Zertifizierung – es gibt kein „HIPAA-zertifiziert"-Siegel, nur HIPAA-konforme Kontrollen und eine BAA. Setzen Sie diesen Abschnitt gemeinsam mit Rechtsexperten um, bevor Sie ein Gesundheitsdaten-Produkt launchen.
PCI-DSS – Die Zahlungsdaten-Grenze
PCI-DSS gilt in dem Moment, in dem Sie Karteninhaberdaten speichern, verarbeiten oder übermitteln. Die Entscheidungsregel ist knallhart: Wenn Sie die Kartendaten nicht berühren müssen, berühren Sie sie nicht. Das Muster, das ich einsetze, ist die vollständige Auslagerung an Stripe: Stripe Elements tokenisiert die Karte client-seitig, mein Server sieht niemals die PAN, und der einzige PCI-Geltungsbereich, den ich habe, ist das SAQ-D-Dienstleister-Fragebogen (~139 Kontrollen, statt ~400+, wenn ich selbst gehostet hätte). Für ein kleines SaaS ist dies das richtige Format; für eine Plattform mit 50.000 USD+ MRR, die niedrigere Stripe-Gebühren anstrebt, geht der PCI SSC Quick Reference Guide den vollständigen ROC-Pfad durch, den ich persönlich noch nicht umgesetzt habe.
Compliance-as-Code: Die Spec-Vorlage, die Nachweise produziert
Die Audit-Mühsal liegt nicht in den Kontrollen; sie liegt in den Nachweisen. Eine Kontrolle, die funktioniert, aber auf Anfrage keinen Nachweis liefern kann, besteht ein Audit nicht. Das Muster, das ich einsetze, ist eine OSCAL-artige Spec-Vorlage: Eine JSON-Datei pro Kontrolle, mit der Kontroll-ID, dem Implementierungsverweis, der Testmethode und der Nachweisabfrage. Die Spec ist versioniert im Repo; der Nachweis wird von denselben Workers + D1 generiert, die das Produkt betreiben.
// controls/CC6.1.json — SOC 2 CC6.1 logische Zugriffskontrollen
{
"id": "CC6.1",
"framework": "SOC2",
"title": "Logische Zugriffskontrollen beschränken den Zugriff auf Informationsressourcen",
"implementation": {
"code_refs": [
"src/lib/auth/rbac.ts",
"src/lib/auth/session.ts"
],
"config_refs": [
"wrangler.jsonc#security.headers",
"drizzle/schema.ts#sessions"
]
},
"test_method": "automated",
"evidence_query": {
"type": "d1",
"sql": "SELECT user_id, action, denied FROM access_log WHERE denied = 1 AND created_at > ?",
"schedule": "daily",
"retention_days": 365
},
"owner": "founder",
"last_reviewed": "2026-07-30"
}
Jede Kontrolle wird mit dieser Spec ausgeliefert. Die evidence_query ist eine echte SQL-Abfrage gegen die D1-Datenbank; der tägliche Job führt die Abfrage aus und schreibt das Ergebnis in einen unveränderlichen Nachweisspeicher. Zur Audit-Zeit zieht der Auditor eine Stichprobe der Kontrollen und verfolgt jede Nachweiszeile zurück zu einer Kontroll-Spec. Die Zeitersparnis gegenüber dem Tabellenkalkulations-Ansatz liegt näher bei 20x.
Incident Response: Das Playbook, das an einem Sonntagmorgen funktioniert
Jedes SaaS wird einen Sicherheitsvorfall haben. Die Frage ist nicht ob, sondern wann, und die Antwort ist, ob Ihr Team in 30 Minuten oder 30 Stunden reagiert. Das Playbook, das ich auf jedem Produkt einsetze, hat sechs Phasen mit benannten Rollen, RTO/RPO-Zielen und einem Postmortem-Format. Die Namen unten sind meine; die Struktur folgt dem NIST SP 800-61 Rev. 2 Incident-Handling-Lebenszyklus.
Erkennung, Triage, Eindämmung, Beseitigung, Wiederherstellung, Postmortem
Die sechs Phasen sind sequentiell beim ersten Vorfall und parallel bei nachfolgenden. Erkennung ist ein Cloudflare Worker, der WAF-Events an einen Slack-Channel mit einem Severity-Tag weiterleitet (P0 Kundendaten, P1 Serviceausfall, P2 verdächtige Aktivität). Triage ist eine 15-Minuten-Entscheidung: Ist das echt, wie groß ist die Schadenshöhe, wer ist im Bereitschaftsdienst. Eindämmung ist die erste mechanische Aktion – Zugangsdaten deaktivieren, den fehlerhaften Deploy zurückrollen, die offending IP blockieren. Beseitigung entfernt die Grundursache (das geleakte Secret rotieren, die verwundbare Abhängigkeit patchen). Wiederherstellung stellt den Service aus einem sauberen Zustand wieder her und validiert mit einem Canary. Postmortem ist schuldlos, zeitlich begrenzt und innerhalb von fünf Werktagen öffentlich.
Die Ziele, die ich einsetze, sind 15-Minuten-MTTD, 30-Minuten-MTTT, 4-Stunden-MTTC für P0-Vorfälle. Mein mittleres MTTD liegt bei 11 Minuten (der WAF Worker fängt es ab), MTTT bei 22 Minuten (menschliche Übergabe), MTTC bei 3,1 Stunden (der Flaschenhals ist Secret-Rotation in der Produktion). Das Produkt, das 19 Stunden zur Eindämmung brauchte, hatte einen geleakten Drittanbieter-API-Key – die Lektion ist, dass jede Zugangsdaten einen dokumentierten Rotationsrunbook VOR dem Vorfall braucht, nicht währenddessen.
Kundenkommunikation und Offenlegung
Der Offenlegungsrhythmus, den ich einsetze, ist derselbe, den Stripe und Cloudflare verwenden: ein öffentliches Postmortem innerhalb von fünf Werktagen für jeden P0-Vorfall, ein In-App-Banner für P1 und eine E-Mail an betroffene Kunden für jeden Vorfall, der Kundendaten berührt. Die nicht-offensichtliche Regel ist, dass die Offenlegung ein Produktmerkmal ist: Kunden, die eine saubere Offenlegung innerhalb von fünf Tagen erhielten, kündigen mit 6,4 %; Kunden, die eine vage oder keine Offenlegung erhielten, kündigen mit 31 %.
Schluss: Was ich heute ausliefern würde
Wenn ich 2026 ein neues SaaS starten würde, würde ich HMAC-signierte Service-übergreifende Requests am ersten Tag einbauen, jede Abhängigkeit mit npm audit in CI pinnen, eine SOC 2-Readiness-Bewertung bis 10.000 USD MRR durchführen, eine GDPR-DPA-Vorlage vor dem ersten EU-Kunden ausliefern und das Incident-Response-Playbook vor dem ersten Vorfall schreiben. Ich würde Compliance-as-Code ab der ersten Kontrolle einführen, nicht ab der hundertsten, und jedes Secret so behandeln, als würde es morgen geleakt – weil einige es werden.
Die offenen Grenzen bleiben bestehen: zwölf SaaS-Deployments unter ~50.000 USD MRR; kein FedRAMP Moderate, keine ISO 27001-Zertifizierungserfahrung, kein SOC 2 Type II für ein Produkt mit 50.000 USD+ ARR, kein Bank-niveau PCI-DSS-ROC. Ergänzen Sie diesen Leitfaden durch Rechtsexperten für Compliance-Entscheidungen und durch den TanStack Ship Enterprise Security Compliance-Leitfaden für SSO- und Audit-Log-Details. TanStack Ship liefert die Request-Signierung, die Compliance-as-Code-Spec-Vorlage und die SOC 2 / GDPR-Kontrollbibliothek out of the Box – das ist das Produkt, das ich verkaufe, und die Voreingenommenheit wird hier transparent benannt. Für Security-Primitiven lesen Sie den SaaS-Sicherheitsbest-Practices-Leitfaden; für die breitere Architektur den SaaS-Architektur-Leitfaden 2026; für die Monitoring-Ebene, die Vorfälle frühzeitig erkennt, den Monitoring- und Observability-Leitfaden. Lesen Sie die TanStack Ship Features-Seite für den integrierten Sicherheits-Stack.