4.3 KiB
Verbindliche Sicherheitsregeln für Module
(Quelle: docs/core/hubrobotix-manifest.md Gesetz 1–4, docs/core/security-checklist.md,
interne Vorfall-Referenzen entfernt)
Diese Regeln sind Prüf-Kriterium in der automatisierten Pipeline (Stufe 3, statische Sicherheitsanalyse) — ein Verstoß führt zum automatischen Scheitern, unabhängig davon, ob er absichtlich oder versehentlich ist.
1. Kein direkter Datenbankzugriff — auch nicht auf dein eigenes Schema
Kein pg, mysql2, kein Connection-String, keine rohe SQL-Query irgendwo in deinem Code. Jeder
Datenzugriff läuft über die Core-API (02-core-api-reference.md). Dein Modul hält nie ein
Datenbank-Credential.
2. Nur die Core-API + deklarierte externe Hosts
Dein Modul-Code darf ausgehend ausschließlich die Core-API sowie die in manifest.json
unter external_hosts[] explizit gelisteten Drittanbieter-Hosts erreichen. Das wird nicht nur
geprüft, sondern zur Laufzeit netzwerkseitig erzwungen (deine Modul-Instanz hat schlicht keinen
Netzwerkpfad zu irgendetwas anderem).
3. Keine hartcodierten Secrets
Kein API-Key, kein Passwort, kein Token im Quellcode oder in einer committeten Datei — Secrets kommen ausschließlich über named Credentials in deinem Workflow, die bei Installation automatisch gegen echte, scoped Tokens ausgetauscht werden.
4. XSS-Schutz
Jeder Datenbankwert (auch aus deinem eigenen Schema), der in innerHTML oder ein
Template-Literal für HTML-Ausgabe eingesetzt wird, muss escaped werden (Standard-Escape-Funktion
aus dem Frontend-Baustein-Kit, siehe UI-Guidelines).
5. Auth-Guard fail-closed
Jede API-Route deines Moduls muss den Nutzerkontext serverseitig selbst prüfen — nie nur im Frontend filtern. Nicht authentifizierte Requests werden abgelehnt, nicht stillschweigend durchgelassen.
6. Owner-/Tenant-Check bei ID-Operationen
Jede Operation, die eine ID entgegennimmt (Update/Delete/Get), muss zusätzlich prüfen, dass diese ID tatsächlich zum aufrufenden Mandanten gehört — nie nur auf die ID selbst vertrauen.
7. Keine Client-seitigen JS-Popups
Kein alert()/confirm()/prompt() — nutze das bereitgestellte Modal-/Overlay-Muster (UI-Kit,
siehe 04-ui-design-guidelines.md).
8. Kein Auth-/Session-Token in URL-Parametern
Token niemals als URL-Parameter (?t=...) übergeben — ausschließlich sessionStorage.
URL-Parameter landen in Server-Zugriffslogs, Browser-History und Referrer-Headern und sind damit
faktisch unverschlüsselt gespeichert, selbst wenn die Verbindung TLS nutzt.
9. Datenbankzugriffs-Funktionen nur über SECURITY DEFINER + explizites GRANT
Wenn dein Modul eigene SQL-Funktionen für Datenzugriffe anlegt (z.B. um Core-API-Endpunkte
technisch zu implementieren), müssen diese als SECURITY DEFINER deklariert und dein Zugriff
per GRANT EXECUTE ... TO <deine_rolle> explizit erteilt sein — nie ein direktes SELECT/
INSERT/UPDATE auf eine Tabelle gewähren, auch nicht rein lesend. Das ist keine Stilfrage: ein
direkter Tabellenzugriff wird von der Datenbank mit "permission denied" verweigert, selbst wenn
dein Code inhaltlich korrekt ist.
10. Keine neuen externen Script-Abhängigkeiten ohne Absicherung
Neue CDN-Scripts entweder lokal in deinem eigenen Modul-Ordner ablegen ODER mit
integrity="sha384-..." + crossorigin="anonymous" einbinden. Ohne das würde eine kompromittierte
CDN-Quelle beliebigen Code im Browser jedes Nutzers ausführen, der dein Modul verwendet.
11. Meta-Robots-Pflicht für jede neue Seite
Jede neue, eigenständig aufrufbare HTML-Seite deines Moduls bekommt im <head>:
<meta name="robots" content="noindex, nofollow, noarchive">
Ohne diesen Tag werden Seiten von Suchmaschinen und KI-Crawlern indexiert, auch wenn sie eigentlich nur intern/für eingeloggte Nutzer gedacht sind.
Was passiert bei einem Fund
- Statischer Scan (Stufe 3): automatisches Scheitern mit konkretem Fundort im Prüfbericht.
- Laufzeit-Test (Stufe 4): selbst wenn eine Regel im Code umgangen würde (Verschleierung),
greift die Ausführungsisolation der Sandbox — ein Modul, das z.B.
require('pg')versucht, hat schlicht keinen Netzwerkpfad zu einer echten Datenbank. Das ist die eigentliche Garantie, nicht der Scan allein.
Weiter mit 04-ui-design-guidelines.md.