Mehrschichtige Sicherheit schützt Ihr Widget, Ihre Kundendaten und Ihre Hosting-Website. Die Inhaltssicherheitsrichtlinie blockiert XSS. Subresource Integrity verhindert Manipulationen. Durch die Ratenbegrenzung wird Missbrauch gestoppt. Sandboxing isoliert Widget-Code. Sicherheitsheader schützen vor häufigen Angriffen.
Sicherheit ist nicht optional. Der Widget-Code wird auf Ihren kundenorientierten Seiten ausgeführt und bietet Zugriff auf sensible Interaktionen. Umfassende Sicherheitshärtung schützt vor Cross-Site-Scripting (XSS), Code-Injection, Man-in-the-Middle-Angriffen, Denial-of-Service, Datenexfiltration und Gefährdungen der Lieferkette. Unser Defense-in-Depth-Ansatz schichtet mehrere Schutzmaßnahmen ein und gewährleistet die Sicherheit auch dann, wenn eine Ebene umgangen wird.
CSP-Header geben an, welche Quellen Skripte, Stile, Bilder, Schriftarten und andere Ressourcen laden können. Widget-JavaScript kann nur von Ihrem vertrauenswürdigen CDN oder Ursprung (https://yourcdn.com oder „self“) geladen werden. Inline-Skripte und -Stile sind deaktiviert, sofern sie nicht gehasht oder nicht geschützt sind, wodurch Angreifer daran gehindert werden, schädlichen Code einzuschleusen. Eval und ähnliche gefährliche Konstrukte sind verboten. Externe API-Aufrufe sind auf genehmigte Domänen (Ihr Backend, Partnerdienste) beschränkt. Verstoßberichte werden an Ihren Sicherheitsüberwachungsendpunkt gesendet und machen Sie in Echtzeit auf Angriffsversuche aufmerksam. CSP verhindert standardmäßig über 90 % der XSS-Schwachstellen.
Jedes Widget-Asset (JavaScript, CSS) wird mit einem kryptografischen Hash bereitgestellt. Browser überprüfen den Hash, bevor sie Code ausführen. Wenn ein Angreifer Ihr CDN kompromittiert oder den Datenverkehr abfängt, um bösartigen Code einzuschleusen, stimmt der Hash nicht überein – Browser weigern sich, die manipulierte Ressource zu laden, um Kunden zu schützen. Ihre Seite wird sicher geladen oder kann nicht geschlossen werden (führt keinen Schadcode aus). SRI bietet starke Sicherheit in der Lieferkette und verhindert, dass CDN-Verstöße die Kundensitzungen gefährden.
Widget-Endpunkte werden durch Ratenlimits geschützt, um Denial-of-Service-Angriffe und automatisierten Missbrauch zu verhindern. Per-IP-Grenzwerte steuern die Nachrichtenhäufigkeit (z. B. maximal 60 Nachrichten pro Stunde von einer IP). Sitzungslimits verhindern, dass einzelne Kunden Ressourcen monopolisieren (maximal 100 Nachrichten pro Sitzung). Burst-Zulagen bewältigen legitime Spitzen (10 Nachrichten in 10 Sekunden sind in Ordnung, aber anhaltender Missbrauch wird blockiert). Cloudflare oder eine ähnliche WAF-Integration bietet zusätzliche DDoS-Abwehr. Verdächtige Muster (schnelle Wiederholungen, Skriptnachrichten, Credential-Stuffing-Versuche) lösen CAPTCHA-Herausforderungen oder vorübergehende Blockierungen aus. Die Missbrauchserkennung schützt Ihre Infrastrukturkosten und stellt sicher, dass legitime Kunden einen reaktionsschnellen Service erhalten.
Das Widget wird in einem isolierten JavaScript-Modulbereich mit eingeschränktem Zugriff auf die übergeordnete Seite ausgeführt: kein Lesen von Cookies von der Hostdomäne (SameSite und sichere Flags verhindern Cookie-Diebstahl), kein Zugriff auf localStorage oder sessionStorage vom Host (Widget verwendet separaten Ursprungsspeicher), keine Änderung des übergeordneten DOM außerhalb des Widget-Containers (strikte Iframe-Eindämmung oder Schatten-DOM-Kapselung) und keine Beeinträchtigung der Skripte oder Stile der übergeordneten Seite (CSS-Scoping, Namespace-Isolierung). Selbst wenn der Widget-Code kompromittiert wird, ist der Schaden begrenzt – Angreifer können keine Sitzungstoken stehlen, den Checkout-Ablauf manipulieren oder auf Kundenkontodaten auf der Hostseite zugreifen.
Backend-APIs, die Widget-Antworten bereitstellen, legen umfassende Sicherheitsheader fest: Strict-Transport-Security (HSTS) erzwingt HTTPS und verhindert Protokoll-Downgrade-Angriffe. X-Content-Type-Options: Nosniff verhindert Verwirrungsangriffe vom MIME-Typ. X-Frame-Optionen: DENY oder SAMEORIGIN verhindern Clickjacking (das Widget kann nicht von Angreiferseiten geframet werden). Referrer-Policy: Strict-Origin-When-Cross-Origin begrenzt Referrer-Lecks. Die Berechtigungsrichtlinie schränkt gefährliche Browserfunktionen ein (Mikrofon, Kamera, Geolokalisierung, sofern nicht erforderlich). Diese Header bieten Schutz vor häufigen Web-Schwachstellen.
Alle Benutzereingaben (Nachrichten, Formulardaten, Suchanfragen) werden vor der Verarbeitung bereinigt: HTML wird entfernt oder codiert (verhindert XSS über den Nachrichteninhalt), SQL-Sonderzeichen werden maskiert oder parametrisiert (verhindert SQL-Injection), Befehlszeichen werden entfernt (verhindert die Injektion in Back-End-Shell-Befehle) und Dateipfade werden validiert (verhindert Verzeichnisdurchquerung). Alle von der KI generierten Antworten werden vor dem Rendern ausgabecodiert: HTML-Entitäten werden maskiert (<script> wird zu <script>), URLs werden anhand von Zulassungslisten validiert und Markdown wird mit striktem Parsing gerendert (kein Roh-HTML-Passthrough). Mehrere Desinfektionsschichten schützen vor Bypässen.
Kundendaten werden bei der Übertragung mit TLS 1.3 (Forward Secrecy, Perfect Forward Secrecy) verschlüsselt. Ruhende Daten werden mit AES-256 verschlüsselt (Gesprächsverlauf, Wissensdatenbankdokumente, Analysedaten). API-Tokens und Geheimnisse verwenden branchenübliche Algorithmen (JWT mit RS256-Signaturen, OAuth 2.0-Flows mit PKCE). Um Fälschungen zu verhindern, sind Besucher-Tokens signiert. Kryptografische Schlüssel werden regelmäßig rotiert (90-Tage-Zyklen) und in sicheren Tresoren (AWS KMS, HashiCorp Vault, Azure Key Vault) gespeichert.
Alle sicherheitsrelevanten Ereignisse werden protokolliert: fehlgeschlagene Authentifizierungsversuche (falscher API-Schlüssel, ungültiges JWT), Ratenlimitverletzungen (missbräuchliche Verkehrsmuster), CSP-Verletzungsberichte (versuchtes XSS), nicht autorisierte Zugriffsversuche (falsche Organisations-ID, fehlende Berechtigungen) und Datenexporte oder -löschungen (DSGVO-Anfragen, Konversationsbereinigungen). Zu den Protokollen gehören Zeitstempel, IP-Adresse, Benutzeragent, Sitzungs-ID und betroffene Ressource. Protokolle werden in SIEM-Systeme (Splunk, Datadog, ELK) eingespeist, um Echtzeitwarnungen und Bedrohungssuche zu ermöglichen.
Das Widget wird regelmäßigen Sicherheitsbewertungen unterzogen: jährliche Penetrationstests durch externe Sicherheitsfirmen, automatisiertes Schwachstellenscannen (OWASP Dependency-Check für Lieferkettenrisiken, Snyk für Paketschwachstellen) und ein Programm zur verantwortungsvollen Offenlegung, das Sicherheitsforscher dazu ermutigt, Fehler privat zu melden. Schwachstellen mit hohem Schweregrad werden innerhalb von 48 Stunden behoben. Kunden werden über kritische Sicherheitsupdates mit umsetzbaren Abhilfemaßnahmen benachrichtigt.
Die Sicherheitsarchitektur unterstützt die Einhaltung von SOC 2 Typ II (Prüfung von Sicherheitskontrollen durch Dritte), ISO 27001 (Informationssicherheitsmanagement), DSGVO (Datenschutz und Privatsphäre), HIPAA (Datensicherheit im Gesundheitswesen, sofern konfiguriert) und PCI DSS (bei Verarbeitung von Zahlungskartendaten in Gesprächen). Compliance-Dokumentation und -Berichte stehen Unternehmenskunden im Rahmen einer NDA zur Verfügung.
Widget geht von einem nicht vertrauenswürdigen Netzwerk, einem nicht vertrauenswürdigen Client und einer nicht vertrauenswürdigen Benutzereingabe aus. Jede API-Anfrage wird authentifiziert (gültiges Token), autorisiert (richtige Berechtigungen), validiert (bereinigte Eingaben), verschlüsselt (TLS) und protokolliert (Audit Trail). Kein implizites Vertrauen auf irgendeiner Ebene. Dies schützt vor Insider-Bedrohungen, kompromittierten Anmeldeinformationen und raffinierten Angriffen.