Warum Headless-Architektur der sicherste Weg zur nDSG-Compliance ist

#Das neue Schweizer Datenschutzgesetz macht dich haftbar.

Seit dem 1. September 2023 gilt das neue Datenschutzgesetz (nDSG) in der Schweiz. Anders als die DSGVO der EU kennt das nDSG keine Übergangsfrist. Es gilt sofort. Und es hat Zähne.

Bei Verstössen drohen Bussen bis zu CHF 250'000 – und zwar gegen die verantwortliche natürliche Person, nicht nur gegen das Unternehmen. Das bedeutet: Als Geschäftsführer trägst du persönliche Verantwortung.

Die meisten Schweizer Webseiten sind nicht compliant. Nicht aus böser Absicht, sondern aus Unwissenheit. Und viele dieser Webseiten laufen auf WordPress.

Das ist ein Problem.

#Die Bedrohung: Warum WordPress ein Sicherheits-Alptraum ist

Lass mich direkt sein:

"Ein Plugin ist eine Hintertür, die du nicht selbst gebaut hast."

WordPress betreibt über 40% des Internets. Das macht es zum grössten Ziel für Hacker weltweit. Jeden Tag werden tausende WordPress-Seiten kompromittiert. Nicht weil WordPress per se schlecht ist, sondern wegen seiner Architektur.

#Das Problem der Monolithen

WordPress ist ein Monolith. Frontend, Backend, Datenbank, Admin-Panel – alles läuft auf demselben Server, in derselben Applikation. Das bedeutet:

• Jedes Plugin hat Zugriff auf die Datenbank
• Jedes Theme kann PHP-Code ausführen
• Jede Schwachstelle öffnet das gesamte System

Die häufigsten Angriffsvektoren:

#Die Plugin-Epidemie

Eine durchschnittliche WordPress-Seite hat 20-30 Plugins. Jedes Plugin ist Code, den du nicht geschrieben hast, nicht reviewt hast, und dem du blind vertraust.

2023 wurden über 4'000 Sicherheitslücken in WordPress-Plugins gemeldet. Viele davon in "Premium"-Plugins von namhaften Anbietern.

Das Problem: Du weisst nie, wann ein Update eine neue Lücke öffnet – oder wann der Plugin-Entwickler aufhört, sein Produkt zu pflegen.

#Kapitel 1: Die Angriffsfläche – Ein visueller Vergleich

#WordPress: Das offene Scheunentor

┌─────────────────────────────────────────────────────────┐
│                    ÖFFENTLICHES INTERNET                │
│                                                         │
│    ┌─────────────────────────────────────────────┐     │
│    │            WordPress Server                  │     │
│    │  ┌───────────────────────────────────────┐  │     │
│    │  │  wp-admin/    ← Login-Endpoint        │  │     │
│    │  │  wp-login.php ← Brute-Force Ziel      │  │     │
│    │  │  xmlrpc.php   ← API-Exploit           │  │     │
│    │  │  /wp-content/plugins/ ← Vulnerabilities│  │     │
│    │  │  MySQL Database ← SQL Injection       │  │     │
│    │  │  PHP Runtime ← Code Execution         │  │     │
│    │  └───────────────────────────────────────┘  │     │
│    └─────────────────────────────────────────────┘     │
│                                                         │
│    Angriffsfläche: ENORM                               │
└─────────────────────────────────────────────────────────┘

#Jamstack (Astro/Next.js): Die verschlossene Tür

┌─────────────────────────────────────────────────────────┐
│                    ÖFFENTLICHES INTERNET                │
│                                                         │
│    ┌─────────────────────────────────────────────┐     │
│    │         CDN (Vercel/Netlify)                │     │
│    │  ┌───────────────────────────────────────┐  │     │
│    │  │  Statische HTML/CSS/JS Dateien        │  │     │
│    │  │  Keine Datenbank                       │  │     │
│    │  │  Kein Login-Endpoint                   │  │     │
│    │  │  Kein PHP                              │  │     │
│    │  │  Kein Server-Code                      │  │     │
│    │  └───────────────────────────────────────┘  │     │
│    └─────────────────────────────────────────────┘     │
│                                                         │
│    ┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐     │
│    │         PRIVATES NETZWERK                  │     │
│    │  ┌───────────────────────────────────────┐ │     │
│    │  │  API Backend (FastAPI/Supabase)       │ │     │
│    │  │  ← Nur authentifizierte Requests      │ │     │
│    │  │  ← Firewall-geschützt                 │ │     │
│    │  │  ← Nicht öffentlich erreichbar        │ │     │
│    │  └───────────────────────────────────────┘ │     │
│    └ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘     │
│                                                         │
│    Angriffsfläche: MINIMAL                             │
└─────────────────────────────────────────────────────────┘

Der Unterschied ist fundamental:

Bei WordPress ist alles öffentlich erreichbar. Bei Jamstack ist das Frontend pure Dekoration – statische Dateien, die nichts Sensitives enthalten. Die echten Daten leben hinter einer Firewall, in einem separaten System.

#Die "Unhackable" Behauptung

Kann man statische HTML-Dateien hacken?

Nein.

Es gibt keinen Code, der ausgeführt wird. Es gibt keine Datenbank, die abgefragt werden kann. Es gibt keinen Server, der kompromittiert werden kann. Die Dateien liegen auf einem CDN, werden weltweit gespiegelt, und sind unveränderlich.

Selbst wenn jemand es schafft, eine statische Datei zu verändern (was praktisch unmöglich ist), enthält sie keine Nutzerdaten. Die Daten leben woanders.

#Kapitel 2: Keine Cookies nötig – Ethisches Tracking

Das nDSG verlangt, dass du informierte Einwilligung einholst, bevor du Cookies setzt, die nicht technisch notwendig sind. Google Analytics? Cookie-Banner. Facebook Pixel? Cookie-Banner. Hotjar? Cookie-Banner.

Aber was, wenn du gar keine Cookies brauchst?

#Unsere Lösung: Plausible Analytics

Wir nutzen Plausible (oder alternativ Umami) für Web-Analytics. Diese Tools:

• Setzen keine Cookies
• Speichern keine persönlichen Daten
• Sind DSGVO- und nDSG-konform ohne Cookie-Banner
• Werden in der EU/Schweiz gehostet (kein US-Datentransfer)

Du bekommst trotzdem alle wichtigen Metriken:

• Seitenaufrufe
• Besucherquellen
• Geräte und Browser
• Conversion-Tracking

Was du nicht bekommst: Individuelle Nutzerprofile, Cross-Site-Tracking, Retargeting-Daten.

Für die meisten Unternehmen ist das mehr als genug. Und du sparst dir das nervige Cookie-Banner, das ohnehin 90% der Nutzer wegklicken.

#Der ethische Aspekt

Es geht nicht nur um Compliance. Es geht um Respekt.

Deine Besucher sind keine Datenpunkte. Sie sind Menschen, die deine Webseite besuchen, weil sie sich für dein Angebot interessieren. Sie verdienen es, nicht überwacht zu werden.

Wir glauben: Du kannst erfolgreiches Marketing betreiben, ohne Menschen zu tracken. Du brauchst guten Content, eine schnelle Seite, und ein überzeugendes Angebot. Nicht Stalker-Technologie.

#Kapitel 3: Wo leben die Daten?

Wenn du Formulare auf deiner Webseite hast – Kontaktformulare, Offerten-Anfragen, Newsletter-Anmeldungen – dann sammelst du personenbezogene Daten. Das nDSG verlangt:

1. Transparenz: Der Nutzer muss wissen, was mit seinen Daten passiert
2. Zweckbindung: Du darfst die Daten nur für den angegebenen Zweck nutzen
3. Datensicherheit: Du musst angemessene Schutzmassnahmen treffen
4. Löschbarkeit: Der Nutzer kann die Löschung seiner Daten verlangen

#Unsere Datenbank-Strategie

Wir nutzen Supabase als Backend-as-a-Service. Supabase bietet:

• Hosting in der EU (Frankfurt) – kein problematischer US-Datentransfer
• Row Level Security (RLS) – Daten sind nur für autorisierte Nutzer sichtbar
• Automatische Backups – Datenverlust ist kein Risiko
• Verschlüsselung at Rest und in Transit – Standard-Sicherheit

Für besonders sensitive Anwendungen (Gesundheitsdaten, Finanzdaten) können wir auch on-premise oder in einem Schweizer Rechenzentrum hosten.

#Formular-Handling ohne Risiko

So funktioniert ein typisches Kontaktformular bei uns:

1. User füllt Formular aus (Frontend)
2. Daten werden direkt an Supabase gesendet (verschlüsselt)
3. Keine Zwischenspeicherung auf dem Frontend-Server
4. Automatische Email-Benachrichtigung an den Kunden
5. Daten sind nur über authentifiziertes Dashboard einsehbar

Es gibt keinen Punkt, an dem unverschlüsselte Daten auf einem öffentlich erreichbaren Server liegen.

#Kapitel 4: Security by Design, nicht by Plugins

Der Unterschied zwischen WordPress-Sicherheit und Jamstack-Sicherheit ist philosophisch:

WordPress: Du baust eine Applikation und versuchst dann, sie abzusichern. Du installierst Security-Plugins, konfigurierst Firewalls, hoffst dass nichts durchrutscht.

Jamstack: Du designst von Anfang an so, dass es nichts zu hacken gibt. Die Sicherheit ist architektonisch eingebaut, nicht nachträglich aufgepfropft.

Das nennt sich Security by Design. Und es ist der einzige Ansatz, der langfristig funktioniert.

#Checkliste: nDSG-konforme Webseite

Hier unsere Checkliste für jedes Projekt:

• Kein Google Analytics – Wir nutzen Plausible oder Umami
• Kein Cookie-Banner nötig – Keine tracking Cookies
• SSL/HTTPS überall – Standard bei Vercel/Netlify
• Datenschutzerklärung – Klar, verständlich, vollständig
• Impressum – Gesetzlich vorgeschrieben in der Schweiz
• Formulare mit Zweckangabe – User weiss, wofür Daten genutzt werden
• Datenbank in EU/CH – Kein US-Datentransfer ohne Rechtsgrundlage
• Lösch-Prozess definiert – User kann Löschung verlangen
• Keine Login-Endpoints öffentlich – Admin nur über separates System
• Regelmässige Audits – Jährliche Überprüfung der Compliance

#Fazit: Investiere in Architektur, nicht in Patches

Du kannst WordPress sicher betreiben. Es ist möglich. Aber es erfordert:

• Ständige Updates
• Security-Audits
• Premium-Plugins für Firewall, Malware-Scan, Login-Schutz
• Einen Entwickler, der sich auskennt
• Glück

Oder du wählst von Anfang an eine Architektur, bei der Sicherheit eingebaut ist. Wo es keine Plugins gibt, die gehackt werden können. Wo es keine Datenbank gibt, die öffentlich erreichbar ist. Wo statische Dateien auf einem CDN liegen, schnell und unangreifbar.

Das ist der Vibe-Weg. Security by Design.

Ist deine Webseite nDSG-konform? Wenn du dir nicht sicher bist, lass uns sprechen. Wir machen einen kostenlosen Quick-Check und zeigen dir, wo die Risiken liegen.

Kostenlosen Security-Check anfragen.