Sicherheit
Sicherheit in Schichten.
Für Agenturen und IT-Verantwortliche: wie KLXM Studio System und Daten schützt – jede Anfrage passiert mehrere Schutzschichten, Daten verlassen den Server nur verschlüsselt. Open SourceSoftware, deren Quellcode offenliegt und unter einer freien Lizenz genutzt, geprüft und verändert werden darf. Das schafft Transparenz und macht unabhängig von einzelnen Herstellern.opensource.org (öffnet in neuem Tab) und nachprüfbar.
Der Weg einer Anfrage
Sieben Schichten zwischen Angreifer und Daten.
Fällt eine Schicht, halten die nächsten. Jede ist für sich wirksam – zusammen ergeben sie das Konzept.
Verbindung
HTTPSDie verschlüsselte Variante von HTTP: Seiten und Formulardaten werden per TLS geschützt übertragen. Erkennbar an „https://“ in der Adresse.de.wikipedia.org (öffnet in neuem Tab) mit HSTSAngabe des Servers, mit der Browser eine Website für eine festgelegte Zeit nur noch über HTTPS aufrufen. Das verhindert, dass Angreifer die Verbindung auf unverschlüsseltes HTTP herabstufen.developer.mozilla.org (öffnet in neuem Tab) (ein Jahr), Sicherheits-HeaderZusätzliche Angaben, die der Webserver mit jeder Seite mitschickt, etwa HSTS oder Content-Security-Policy. Sie weisen den Browser an, bestimmte Angriffe zu unterbinden.developer.mozilla.org (öffnet in neuem Tab) gegen Einbetten, Sniffing und Zugriff auf Kamera oder Standort.
- HTTPS mit Strict-Transport-Security für ein Jahr
- Hinter einem Proxy zählt X-Forwarded-Proto nur von eingetragenen, vertrauenswürdigen Adressen
- ClickjackingAngriff, bei dem Ihre Seite unsichtbar in eine fremde Seite eingebettet wird, damit Besucher unbemerkt darauf klicken. Abhilfe: „frame-ancestors“ in der Content-Security-Policy oder „X-Frame-Options“.developer.mozilla.org (öffnet in neuem Tab): kein Einbetten in fremde Seiten
- X-Content-Type-OptionsHeader mit dem Wert „nosniff“: Der Browser behandelt Dateien nur als den angegebenen Typ und rät nicht selbst. Das verhindert, dass etwa ein hochgeladenes Bild als Skript ausgeführt wird.developer.mozilla.org (öffnet in neuem Tab) und Referrer-PolicyLegt fest, wie viel von der aktuellen Adresse der Browser beim Klick auf einen Link an die nächste Website weitergibt. Ohne Angabe gilt „strict-origin-when-cross-origin“ (bei fremden Seiten nur die Domain).developer.mozilla.org (öffnet in neuem Tab); Permissions-PolicyHeader, mit dem eine Website Browser-Funktionen wie Kamera, Mikrofon oder Standort für sich und eingebettete Inhalte abschaltet.developer.mozilla.org (öffnet in neuem Tab) ohne Kamera, Mikrofon und Standort
Inhalt
Strenge Content Security Policy: nur eigene Skripte, kein Inline-Code, keine fremden Quellen ohne Freigabe.
- Content Security Policy auf jeder Seite: Skripte und Stile nur vom eigenen Server
- Kein Inline-Code, keine style-Attribute, keine Event-Handler im HTMLAuszeichnungssprache für den Aufbau von Webseiten: Überschriften, Absätze, Links und Bilder werden darin beschrieben.
- Erweiterungen dürfen Quellen ergänzen – nie unsafe-inline oder unsafe-eval
- Rich-Text nur über eine Positivliste, Ausgaben grundsätzlich maskiert
Anmeldung
Passwörter mit bcrypt, Sperre nach 8 Fehlversuchen je IP-AdresseNummer, unter der ein Gerät im Internet erreichbar ist – als IPv4 (z. B. 203.0.113.7) oder als längere IPv6-Adresse., zweiter Faktor per App oder PasskeyAnmeldung ohne Passwort: Ein Schlüsselpaar wird auf Ihrem Gerät gespeichert und per Fingerabdruck, Gesichtserkennung oder PIN freigegeben. Passkeys sind gegen Phishing weitgehend immun.fidoalliance.org (öffnet in neuem Tab) – je Rolle verpflichtend.
- Passwörter mit bcrypt, automatische Umstellung auf stärkere Verfahren
- 8 Fehlversuche je IP und 20 je Konto in 15 Minuten, danach Pause
- Zweiter Faktor: Authenticator-App (Zwei-Faktor-AnmeldungAnmeldung mit zwei Nachweisen, etwa Passwort plus sechsstelliger Code aus einer App (TOTP). Selbst wenn das Passwort bekannt wird, bleibt das Konto so geschützt.de.wikipedia.org (öffnet in neuem Tab)) oder Passkey (WebAuthn), je Rolle verpflichtend, auch „nur Passkey“
- Sitzungs-CookieKleine Datei, die eine Website im Browser speichert, etwa für die Anmeldung oder Einstellungen. Für Cookies, die nicht unbedingt nötig sind (z. B. Statistik, Werbung), brauchen Sie eine Einwilligung.de.wikipedia.org (öffnet in neuem Tab) HttpOnly, Secure, SameSite=Lax; ein neues Passwort beendet alle Sitzungen
Rechte
Frei zusammenstellbare Rollen, Rechte je DatentabelleStrukturierte Inhalte wie Team, Termine, Produkte oder Referenzen: gleich aufgebaute Einträge mit festen Feldern, die auf mehreren Seiten erscheinen können – oft mit eigener Detailseite je Eintrag., CSRF-Schutz und Rechteprüfung bei jeder Aktion der Verwaltung.
- Frei zusammenstellbare Rollen, Rechte je Datentabelle
- Jede Route der Verwaltung prüft Anmeldung, Recht und CSRF-Token
- Rollen vergibt nur, wer sie selbst hat
- APIProgrammierschnittstelle: Über sie tauschen Programme Daten aus, ohne die Bedienoberfläche zu nutzen – etwa um Einträge aus einem anderen System zu übernehmen.de.wikipedia.org (öffnet in neuem Tab)- und MCPModel Context Protocol: offener Standard, über den KI-Assistenten auf Werkzeuge und Daten zugreifen. Über einen MCP-Server können solche Assistenten zum Beispiel Inhalte einer Website lesen oder Entwürfe anlegen.modelcontextprotocol.io (öffnet in neuem Tab)-Schlüssel an das Konto gebunden, nur mit dessen Rechten
Daten
Anfragen aus Formularen verschlüsselt – Klartext erreicht die Datenbank nie. Zugangsdaten verschlüsselt gespeichert.
- Formulardaten beim Eingang verschlüsselt (libsodium) – lesbar nur mit dem Schlüssel der Redaktion
- SMTP-Passwort und Zugangsdaten verschlüsselt gespeichert
- Uploads nach Positivliste, SVGs bereinigt, Dateien mit PHPWeit verbreitete Programmiersprache für Websites. KLXM Studio ist in PHP geschrieben und läuft deshalb auf fast jedem üblichen Webhosting.php.net (öffnet in neuem Tab)-Code abgelehnt
- Geschützte Medien außerhalb des Webroots, nur nach Anmeldung
Überwachung
Stündliche Integritätsprüfung von Code, Konfiguration und Datenbank, Aktionslog, Hinweis per E-Mail.
- Stündlich: Prüfsummen von Code, .htaccess und Konfiguration
- Ausführbare Dateien in Medien, Trigger in der Datenbank, neue Administratoren und Schlüssel
- Hinweis per E-Mail bei neuen Funden
- Aktionslog: wer was wann geändert, veröffentlicht oder gelöscht hat
Sicherung
Jede Nacht gesichert, auf Wunsch verschlüsselt außer Haus – WebDAV, SFTP, FTPS. Wiederherstellung erprobt.
- Jede Nacht: Datenbank und Medien jeder Website, geteilte Medien und Tabellen
- Auf Wunsch außer Haus: WebDAV, SFTP, FTPS oder NAS – verschlüsselt mit XChaCha20-Poly1305
- Schlüssel bleibt beim Betreiber, nicht in der Sicherung
- Wiederherstellung auf einem neuen Server mit einem Befehl
Aufbau einer Installation
Öffentlich ist nur ein Ordner.
Code, Schlüssel und Daten liegen außerhalb des Webroots. Was der Webserver ausliefern darf, ist klar abgegrenzt – und wird überwacht.
Installation
httpdocs/app/Kern – Prüfsummen, stündlich geprüftconfig/Schlüssel – nicht öffentlichstorage/Datenbanken, Daten – nicht öffentlichbackups/nächtliche Sicherungenpools/geschützte Medien – nur mit Anmeldungextensions/Erweiterungen – geprüft wie der Kernpublic/einziger öffentlicher Ordnerindex.phpeinzige ausführbare Dateiassets/gebautes CSSSprache für das Aussehen von Webseiten: Farben, Schriften, Abstände und das Verhalten auf verschiedenen Bildschirmgrößen. und JavaScriptmedia/Bilder und Dateien – nie ausführbar
Was das bedeutet
-
Ein Einstieg
Der Webserver führt nur public/index.php aus. Jede weitere PHP-Datei unter public/ meldet die Integritätsprüfung als Fehler – außer bewusst eingebundenen Anwendungen wie Matomo.
-
Daten außerhalb
Datenbanken (SQLiteDatenbank in einer einzigen Datei, ohne eigenen Datenbank-Server. Ideal für kleine und mittlere Websites: einfach zu sichern und umzuziehen.sqlite.org (öffnet in neuem Tab) oder MySQLVerbreitete Datenbank-Server für Websites. MariaDB ist eine weitgehend kompatible, freie Weiterentwicklung von MySQL.mariadb.org (öffnet in neuem Tab)), Schlüssel, Sitzungen und Sicherungen liegen in storage/ und config/ – nicht über das Web erreichbar.
-
Saubere Uploads
SVGs werden nach einer Positivliste bereinigt, Dateien mit PHP-Code abgelehnt, Office-Dateien nur auf Wunsch der Administration angenommen.
-
Geschützte Medien
Dateien für Mitgliederbereiche liegen in storage/pools und werden erst nach Prüfung der Anmeldung ausgeliefert – sie haben keine öffentliche Adresse.
Grundsätze
Was das Konzept trägt.
-
Wenig Angriffsfläche
Kein großes Framework, kein Plugin-Markt mit fremdem Code. Erweiterungen greifen nur über dokumentierte Schnittstellen ein.
- Ein öffentlicher Einstieg
- Strenge Content-Security-PolicyAngabe des Servers, aus welchen Quellen eine Seite Skripte, Stile, Bilder usw. laden darf. Sie erschwert Angriffe wie Cross-Site-Scripting erheblich.developer.mozilla.org (öffnet in neuem Tab) auf jeder Seite
- Neue Funktionen standardmäßig aus, wenn sie Daten nach außen schicken
-
Daten bleiben bei Ihnen
Kein Tracking und keine Dienste Dritter ab Werk. Karten, Schriften und Videos laufen über den eigenen Server bzw. erst nach Klick.
- Karten über den eigenen Server
- Schriften selbst gehostet
- YouTube und Vimeo erst nach Zustimmung
-
Nachprüfbar statt versprochen
Der Quellcode ist offen (MIT). Statische Analyse, Selbsttests und eine Prüfung auf bekannte Lücken in Bibliotheken gehören zu jeder Änderung.
- PHPStan Stufe 5 ohne Funde
- Selbsttests für Kern und Erweiterungen
- composer audit und pnpm audit
Ihr Teil als Betreiber
- Zweiten Faktor für die Administration verlangen (Benutzer & Rollen → Anmeldung & Sicherheit)
- Sicherung außer Haus einrichten und den Schlüssel an einem anderen Ort aufbewahren
- Server, PHP und KLXM Studio aktuell halten
- Meldungen der Integritätsprüfung ernst nehmen
Im Detail
Alle Maßnahmen auf einen Blick.
Für die Prüfung durch Ihre IT – jede Angabe ist im Quellcode nachvollziehbar.
| Bereich | Technik | Details |
|---|---|---|
| Transport | HTTPS, HSTS | Strict-Transport-Security mit einem Jahr; hinter einem Proxy nur mit eingetragenen vertrauenswürdigen Adressen. |
| Header | X-Frame-Options, nosniff, Referrer- und Permissions-Policy | Kein Einbetten in fremde Seiten, kein MIME-Sniffing, kein Zugriff auf Kamera, Mikrofon oder Standort. |
| Inhalt | Content Security Policy | script-src und style-src nur vom eigenen Server; Erweiterungen dürfen Quellen ergänzen, nie unsafe-inline oder unsafe-eval. |
| Sitzung | Cookie HttpOnly, Secure, SameSite=Lax | Abmelden überall durch eine Versionsnummer je Konto – ein neues Passwort beendet alle Sitzungen. |
| Passwörter | bcrypt (password_hash) | Automatische Umstellung, wenn PHP ein stärkeres Verfahren als Standard setzt. |
| Anmeldeschutz | Begrenzung je IP und je Konto | 8 Versuche je IP und 20 je Konto in 15 Minuten; der zweite Faktor hat eine eigene Begrenzung. |
| Zweiter Faktor | TOTP (Authenticator-App), Passkeys (WebAuthn) | Je Rolle verpflichtend einstellbar, auch „nur Passkey“; für Netzwerk-Konten in Produktion immer verlangt. |
| Rechte | Rollen, Rechte je Datentabelle, CSRF | Jede Route der Verwaltung prüft Anmeldung, Recht und CSRF-Token; Rollen lassen sich nur vergeben, wenn man sie selbst hat. |
| Schnittstellen | API- und MCP-Schlüssel | An das Konto gebunden, nur mit den Rechten des Besitzers; neue Schlüssel meldet die Integritätsprüfung. |
| Uploads | Positivliste, SVG-Bereinigung, PHP-Erkennung | Gefährliche Typen gesperrt, SVGs ohne Skripte und externe Verweise, Office-Dokumente nur auf Wunsch. |
| Anfragen | libsodium (Sealed Box) | Formulardaten werden beim Eingang verschlüsselt; lesbar nur mit dem Schlüssel der Redaktion, nicht für den Webhoster. |
| Geheimnisse | libsodium (Secretbox) | SMTP-Passwort, Zugangsdaten externer Quellen und Sicherungsziele verschlüsselt gespeichert. |
| Integrität | Prüfsummen, signierte Vergleichsstände | Stündlich: Code, .htaccess, Konfiguration, ausführbare Dateien in Medien, Trigger, neue Administratoren und Schlüssel. |
| Protokoll | Aktionslog | Wer hat wann Seiten, Datensätze und Medien angelegt, geändert, veröffentlicht oder gelöscht. |
| Sicherung | Nächtlich lokal, außer Haus verschlüsselt | XChaCha20-Poly1305 (libsodium); Ziele WebDAV, SFTP, FTPS oder Ordner; Schlüssel nur auf dem Server. |
| Entwicklung | PHPStan, Selbsttests, Audits | Statische Analyse Stufe 5, Selbsttests je Bereich, composer audit und pnpm audit ohne bekannte Lücken. |
Lücke gefunden? Bitte vertraulich melden – über „Report a vulnerability“ im Repository auf GitHub oder per E-Mail an info@klxm.de (Betreff „Security: KLXM Studio“).
Fragen
Häufige Fragen zur Sicherheit
Wo liegen die Daten?
Auf dem Server, auf dem KLXM Studio läuft – bei Ihnen oder bei uns. Datenbanken, Medien und Sicherungen liegen in derselben Installation; ohne Ihre Einstellung geht nichts an Dritte.
Wer kann Anfragen aus Formularen lesen?
Nur Personen mit dem Schlüssel für Anfragen. Die Daten werden beim Eingang verschlüsselt gespeichert – auch der Webhoster sieht in der Datenbank nur verschlüsselte Werte.
Was passiert, wenn jemand eindringt?
Die Integritätsprüfung meldet innerhalb einer Stunde veränderte Dateien, neue Administrator-Konten oder Schlüssel per E-Mail. Mit der Sicherung außer Haus lässt sich der letzte saubere Stand auf einem neuen Server wiederherstellen.
Ist ein zweiter Faktor Pflicht?
Für Netzwerk-Konten in Produktion immer. Für die Rollen einer Website stellen Sie es selbst ein – wir empfehlen ihn mindestens für die Administration, auf Wunsch „nur Passkey“.
Können wir den Code prüfen lassen?
Ja. Der Quellcode ist offen (MIT) und auf GitHub einsehbar – Ihre IT oder ein Dienstleister kann ihn vollständig prüfen.
Wie melden wir eine Sicherheitslücke?
Vertraulich über „Report a vulnerability“ im Repository auf GitHub oder per E-Mail an info@klxm.de mit dem Betreff „Security: KLXM Studio“ – bitte nicht in öffentlichen Issues.
Kontakt
Sprechen Sie mit KLXM Crossmedia.
Vorführung, Einsatz in Ihrem Projekt oder eine Erweiterung nach Ihren Wünschen – sprechen Sie uns an. Wir antworten persönlich.
Am Schürmannshütt 40g
47441 Moers
Deutschland
- Telefon
- +49 2841 889998-0
- info@klxm.de