90 lines
4.3 KiB
Markdown
90 lines
4.3 KiB
Markdown
# 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>`:
|
||
```html
|
||
<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](04-ui-design-guidelines.md).
|