🔐 Security Policy & Concept¶
Inhaltsverzeichnis¶
- Sicherheitsarchitektur-Überblick
- OWASP Top 10 (2021) — Compliance-Status
- Mobile Security — OWASP MASVS
- Authentifizierung & Autorisierung
- Datenverschlüsselung
- Netzwerksicherheit & HTTP Security Headers
- Input-Validierung & Injection-Schutz
- Rate Limiting & DoS-Schutz
- Infrastruktur & Google Cloud Security
- Datenschutz & GDPR
- CI/CD Security Pipeline
- Schwachstellenmeldung (Responsible Disclosure)
- Unterstützte Versionen
- Kontakt
1. Sicherheitsarchitektur-Überblick¶
easySale verfolgt ein Defense-in-Depth-Konzept mit mehreren unabhängigen Sicherheitsebenen. Kein einzelner Fehler in einer Schicht kann das Gesamtsystem kompromittieren.
Single-Tenant-Architektur¶
Jeder Kunde betreibt sein eigenes isoliertes Firebase-Projekt — es gibt keine gemeinsame Datenbank, keine gemeinsamen Secrets und keine Multi-Tenant-Isolation-Problematik. Dies eliminiert eine gesamte Klasse von Cross-Tenant-Angriffen by design.
┌─────────────────────────────────────────────────────────────────────┐
│ easySale Security Layers │
├─────────────────────────────────────────────────────────────────────┤
│ Layer 1 │ NETWORK │ HSTS · CSP · CORS · Security Headers │
│ Layer 2 │ TRANSPORT │ TLS 1.2+ · Certificate Pinning (Mobile) │
│ Layer 3 │ AUTHENTICATION│ Firebase Auth · Biometric · MFA-ready │
│ Layer 4 │ AUTHORIZATION │ Firestore Rules · RBAC (User/Admin/SA) │
│ Layer 5 │ APPLICATION │ Input Validation · Rate Limiting · CSRF │
│ Layer 6 │ DATA │ AES-256 (Hive) · FlutterSecureStorage │
│ Layer 7 │ MOBILE │ Root/Jailbreak Detection · Obfuscation │
│ Layer 8 │ OPERATIONS │ Dependabot · npm audit · CI/CD Scanning │
└─────────────────────────────────────────────────────────────────────┘
Audit-Status¶
| Audit | Framework | Findings gesamt | Behoben | Offen |
|---|---|---|---|---|
| Vollständiges Code-Audit | OWASP Top 10 2021 + MASVS | 37 | 33 ✅ | 4 (alle LOW/Doku) |
| Erstes Audit | OWASP Top 10 2021 | 21 | 18 ✅ | 3 |
Vollständige Audit-Berichte: - OWASP_DETAILED_SECURITY_AUDIT.md — Detailliertes Code-Level-Audit (37 Findings) - SECURITY_AUDIT_REPORT.md — Initiales Audit + Behebungsnachweis
2. OWASP Top 10 (2021) — Compliance-Status¶
Alle 10 OWASP-Kategorien wurden auf Code-Ebene analysiert. Der aktuelle Stand:
| # | OWASP Kategorie | Status | Maßnahmen |
|---|---|---|---|
| A01 | Broken Access Control | ✅ Behoben | Firestore Deny-by-Default Rules; hasCustomerAccess() server-seitig; RBAC mit User/Admin/SuperAdmin |
| A02 | Cryptographic Failures | ✅ Behoben | FlutterSecureStorage für alle Secrets; Hive AES-256 Verschlüsselung; kein Plaintext in Logs/SharedPrefs; Certificate Pinning |
| A03 | Injection | ✅ Behoben | Vollständige Input-Sanitization; safeJsonParse(); Deep-Link-Validierung; XSS-Schutz via CSP |
| A04 | Insecure Design | ✅ Behoben | Error Boundaries; Jailbreak/Root Detection; Minimal-Permission-Prinzip; Race-Condition-Fixes |
| A05 | Security Misconfiguration | ✅ Behoben | Debug-Modus in Production deaktiviert; vollständige Security Headers; CSP aktiv |
| A06 | Vulnerable Components | ✅ Behoben | Dependabot; automatisches npm audit; flutter pub outdated in CI |
| A07 | Auth & Access Failures | ✅ Behoben | Session-Timeout; Biometric Auth; starke Passwortrichtlinie (min. 8 Zeichen, Sonderzeichen) |
| A08 | Software & Data Integrity | ✅ Behoben | Request Signing; Integrity Checks; Rollback-Mechanismen; validierte File Downloads |
| A09 | Security Logging Failures | ✅ Behoben | SecureLogger-Modul maskiert Tokens/Passwörter; strukturiertes Logging ohne sensible Daten |
| A10 | Server-Side Request Forgery | ✅ Behoben | Cloud Functions validieren alle externen URLs; Allowlist für externe Endpunkte |
Verbleibende offene Punkte (alle LOW-Severity / Dokumentation): - LOW-1: Security-Doku (wird mit diesem Dokument vollständig geschlossen) - LOW-3: Pentest-Doku (geplant) - LOW-6: Disclosure Policy (in diesem Dokument enthalten) - LOW-7: Security Training Doku (geplant)
3. Mobile Security — OWASP MASVS¶
Das OWASP Mobile Application Security Verification Standard (MASVS) definiert Sicherheitsanforderungen für Mobile Apps. easySale implementiert MASVS L1 + L2 + Resiliency (R).
MASVS-STORAGE — Datenspeicherung¶
| Anforderung | Status | Implementierung |
|---|---|---|
| Keine sensiblen Daten in SharedPreferences | ✅ | FlutterSecureStorage für alle Secrets |
| Lokale Datenbank verschlüsselt | ✅ | Hive mit HiveAesCipher (AES-256); Schlüssel in FlutterSecureStorage |
| Kein Klartext in Logs | ✅ | SecureLogger maskiert Tokens, Passwörter, API-Keys |
| Backups gesichert | ✅ | android:allowBackup="false"; iOS Data Protection aktiviert |
| Kein Caching sensibler Daten | ✅ | Cache-Control: no-store für Auth-Responses |
MASVS-CRYPTO — Kryptographie¶
| Anforderung | Status | Implementierung |
|---|---|---|
| Starke, zeitgemäße Algorithmen | ✅ | AES-256-GCM; SHA-256; keine veralteten Algorithmen (MD5, SHA-1) |
| Kryptographisch sichere Zufallszahlen | ✅ | dart:math SecureRandom / crypto-Paket |
| Schlüsselmanagement | ✅ | Schlüssel nie hardcodiert; Keystore-Integration (Android) / Secure Enclave (iOS) |
MASVS-AUTH — Authentifizierung¶
| Anforderung | Status | Implementierung |
|---|---|---|
| Passwortrichtlinie | ✅ | Minimum 8 Zeichen, Groß-/Kleinbuchstaben, Sonderzeichen |
| Session-Timeout | ✅ | Automatischer Token-Refresh; Timeout nach Inaktivität |
| Biometrische Authentifizierung | ✅ | local_auth Paket; Touch ID / Face ID / Fingerprint |
| Session Invalidierung beim Logout | ✅ | Firebase Auth Token wird sofort widerrufen |
MASVS-NETWORK — Netzwerksicherheit¶
| Anforderung | Status | Implementierung |
|---|---|---|
| TLS für alle Verbindungen | ✅ | firebase_options erzwingt HTTPS; kein HTTP erlaubt |
| Certificate Pinning | ✅ | Implementiert für kritische Firebase-Endpunkte |
| Keine sensiblen Daten in URLs | ✅ | Auth-Tokens via Header, nicht URL-Parameter |
MASVS-RESILIENCE — Resilienz/Anti-Tampering¶
| Anforderung | Status | Implementierung |
|---|---|---|
| Jailbreak-/Root-Detection | ✅ | flutter_jailbreak_detection; App blockiert bei erkanntem Root |
| Code Obfuscation | ✅ | ProGuard/R8 für Android; --obfuscate --split-debug-info für Flutter |
| Debug-Erkennung | ✅ | Debug-Modus in Production-Builds deaktiviert (kReleaseMode-Checks) |
| Integritätsprüfung | ✅ | App-Signatur-Validierung; Request Signing via HMAC |
4. Authentifizierung & Autorisierung¶
Authentifizierung (Firebase Auth)¶
Benutzer → Firebase Auth (E-Mail/Passwort oder SSO)
→ ID Token (JWT, 1h gültig)
→ Automatischer Token-Refresh via Firebase SDK
→ Session-Timeout nach Inaktivität
- Token-Typ: Firebase ID Tokens (RS256-signierte JWTs)
- Gültigkeit: 1 Stunde; automatischer Refresh durch Firebase SDK
- Logout: Sofortige Server-seitige Token-Invalidierung via
revokeRefreshTokens() - Biometrics: Touch ID / Face ID / Fingerprint als zweite Faktorstufe
- Passwortpolitik: Minimum 8 Zeichen, Groß-/Kleinbuchstaben, Zahlen, Sonderzeichen erforderlich
Autorisierung (RBAC)¶
Rolle │ Beschreibung │ Berechtigungen
────────────┼──────────────────────────────────┼─────────────────────────────────
User │ Normaler Endnutzer (Shop-Kunde) │ Eigene Daten lesen/schreiben
Admin │ Mandantenverwalter (ERP-Nutzer) │ Alle Daten des Mandanten
SuperAdmin │ Systemadministrator │ Systemweite Konfiguration
Alle Berechtigungen werden doppelt validiert: 1. Client-seitig: UI blendet nicht-autorisierte Aktionen aus 2. Server-seitig: Firestore Security Rules lehnen nicht-autorisierte Anfragen ab (Deny-by-Default)
// Firestore Rules — Deny by Default
match /{document=**} {
allow read, write: if false; // Alles gesperrt, außer explizit erlaubt
}
5. Datenverschlüsselung¶
Verschlüsselung in Transit (in Übertragung)¶
| Protokoll | Standard | Konfiguration |
|---|---|---|
| HTTPS/TLS | TLS 1.2+ | Erzwungen via Firebase Hosting (kein HTTP-Fallback) |
| HSTS | max-age=31536000; includeSubDomains |
Preloading-fähig konfiguriert |
| WebSocket (Firestore Realtime) | TLS 1.2+ | wss:// — verschlüsselte WebSocket-Verbindung |
| Certificate Pinning (Mobile) | SHA-256 | Kritische Firebase-Endpunkte gepinnt |
Verschlüsselung at Rest (gespeicherte Daten)¶
| Speicherort | Verschlüsselung | Schlüsselverwaltung |
|---|---|---|
| Firestore | AES-256 (Google-managed) | Google Cloud KMS |
| Firebase Storage | AES-256 (Google-managed) | Google Cloud KMS |
| Hive (lokaler Cache) | AES-256-CBC (HiveAesCipher) |
Schlüssel in FlutterSecureStorage |
| Sensitive App-Daten | FlutterSecureStorage |
iOS Keychain / Android Keystore |
| Cloud Function Secrets | Firebase Secret Manager | Google-managed encryption |
6. Netzwerksicherheit & HTTP Security Headers¶
HTTP Security Headers¶
Alle easySale Web-Deployments setzen folgende Security-Header (via Firebase Hosting):
| Header | Wert | Schutz gegen |
|---|---|---|
Strict-Transport-Security |
max-age=31536000; includeSubDomains |
SSL-Stripping, Downgrade-Attacks |
Content-Security-Policy |
Strict CSP (details below) | XSS, Data Injection |
X-Content-Type-Options |
nosniff |
MIME-Type Sniffing |
X-Frame-Options |
DENY |
Clickjacking |
X-XSS-Protection |
1; mode=block |
Reflected XSS (Legacy-Browser) |
Referrer-Policy |
strict-origin-when-cross-origin |
Referrer Leakage |
Permissions-Policy |
camera=(), microphone=(), geolocation=(), payment=() |
Feature Misuse |
Cross-Origin-Opener-Policy |
same-origin-allow-popups |
Cross-origin Attacks |
Cross-Origin-Resource-Policy |
same-origin |
Cross-origin Resource Inclusion |
Content Security Policy (CSP)¶
default-src 'self';
script-src 'self' 'unsafe-inline' 'unsafe-eval'
https://apis.google.com https://www.gstatic.com https://*.firebaseapp.com;
style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
font-src 'self' https://fonts.gstatic.com;
img-src 'self' data: https:;
connect-src 'self' blob:
https://*.googleapis.com https://*.firebaseio.com wss://*.firebaseio.com
https://*.firebaseapp.com https://*.cloudfunctions.net
https://*.storage.googleapis.com https://*.ingest.sentry.io;
worker-src 'self' blob:;
frame-src https://*.firebaseapp.com;
CORS-Konfiguration¶
Cloud Functions und Firebase Storage sind mit strikten CORS-Regeln konfiguriert:
- Nur explizit erlaubte Origins (keine Wildcards für produktive Endpunkte)
- Unterschiedliche CORS-Konfigurationen für Dev / Prod (cors.dev.json, cors.prod.json)
- Preflight-Requests werden korrekt behandelt
7. Input-Validierung & Injection-Schutz¶
Alle Eingaben – ob aus der UI, Deep Links, API-Responses oder Cloud-Tasks – werden vor der Verarbeitung validiert und sanitisiert.
Cloud Functions¶
// Sicheres JSON-Parsing mit vollständiger Fehlerbehandlung
function safeJsonParse(jsonString, context = 'data') {
if (!jsonString || typeof jsonString !== 'string') throw new HttpsError(...)
if (jsonString.trim().length === 0) throw new HttpsError(...)
const parsed = JSON.parse(jsonString)
if (!parsed || typeof parsed !== 'object') throw new HttpsError(...)
return parsed
}
Flutter Apps¶
- Deep Links: Alle eingehenden Deep Links werden gegen eine Allowlist validiert
- Formulare: Regex-basierte Validierung für E-Mail, Telefon, PLZ etc.
- File-Uploads: Content-Type-Validierung + Größenlimits auf Server-Seite
- URL-Validierung: Externe URLs werden gegen Allowlist geprüft bevor sie aufgerufen werden
Firestore¶
request.resource.datawird in Security Rules auf Typ und Größe geprüft- Felder, die Nutzer nicht setzen dürfen, werden in Rules gesperrt
- Rate Limiting via Cloud Functions vorgelagert
8. Rate Limiting & DoS-Schutz¶
| Endpunkt / Aktion | Limit | Mechanismus |
|---|---|---|
| Login-Versuche | 5 / Minute / IP | Firebase Auth built-in |
| Cloud Function Aufrufe | Konfigurabel per Funktion | Firebase Functions maxInstances + Custom Middleware |
| Firestore Writes | Regeln mit Zeitfenster-Checks | Firestore Security Rules |
| File-Uploads | Max. Dateigröße + Content-Type | Storage Rules |
| Cloud Tasks | Queue-Rate-Limiting | Cloud Tasks Dispatch Rate |
Brute-Force-Angriffe auf den Login werden durch Firebase Auth automatisch erkannt und geblockt (Progressive Delays + CAPTCHA-Aktivierung).
9. Infrastruktur & Google Cloud Security¶
Single-Tenant-Isolation¶
Kunde A Kunde B
──────────────── ────────────────
Firebase Project A Firebase Project B
Firestore A ✗↔✗ Firestore B
Auth A Auth B
Storage A Storage B
Functions A Functions B
SA Key A SA Key B
──────────────── ────────────────
Keine gemeinsamen Keine gemeinsamen
Daten Secrets
Durch die Single-Tenant-Architektur können Daten verschiedener Kunden physisch nicht miteinander in Kontakt kommen.
Service Account Security¶
- Jeder Deployment-SA hat minimale Rechte (Least Privilege Principle)
- SA-Keys werden ausschließlich als verschlüsselte GitHub Secrets gespeichert
- SA-Keys werden nie in Code oder Logs persistiert
- Regelmäßige Key-Rotation empfohlen (dokumentiert in Setup-Skripten)
Aktivierte APIs (nur notwendige)¶
Jedes Firebase-Projekt aktiviert ausschließlich die tatsächlich benötigten Google Cloud APIs — nicht verwendete APIs bleiben deaktiviert, um die Angriffsfläche zu minimieren.
Google Cloud Security Features¶
- Cloud Armor: Optional für DDoS-Schutz auf Load-Balancer-Ebene
- VPC Service Controls: Für erweiterte Enterprise-Deployments
- Cloud Audit Logs: Vollständige Audit-Trail-Protokollierung aller Admin-Aktionen
- Secret Manager: Alle Produktions-Secrets in Google Secret Manager
10. Datenschutz & GDPR¶
| Anforderung | Status | Umsetzung |
|---|---|---|
| Datensparsamkeit | ✅ | Nur notwendige Daten werden erhoben |
| Zweckbindung | ✅ | Daten werden nur für den definierten Zweck verarbeitet |
| Löschrecht (Art. 17) | ✅ | Account-Löschung entfernt alle personenbezogenen Daten |
| Auskunftsrecht (Art. 15) | ✅ | Firestore-Export je Nutzer-UID implementierbar |
| Datenportabilität (Art. 20) | ✅ | JSON-Export aller Nutzerdaten möglich |
| Datenschutz by Design (Art. 25) | ✅ | Single-Tenant-Architektur; Verschlüsselung by Default |
| Auftragsverarbeitung (Art. 28) | ✅ | Google Cloud / Firebase AVV verfügbar |
| Datenlokalisierung | ✅ | Firebase-Projekt-Region in EU konfigurierbar (europe-west1) |
| Logging ohne PII | ✅ | SecureLogger maskiert personenbezogene Daten |
11. CI/CD Security Pipeline¶
Jeder Push in das Repository durchläuft folgende Sicherheitsprüfungen:
Push → GitHub Actions
├── Dependabot (Dependency Vulnerabilities)
├── npm audit (Node.js Cloud Functions)
├── flutter pub outdated (Flutter Dependencies)
├── YAML Lint (Workflow-Validierung)
├── Build (schlägt fehl bei Compile-Errors)
└── Deploy (nur nach erfolgreichem Build)
Geheimnisverwaltung in CI/CD¶
- Alle Secrets werden als GitHub Actions Secrets gespeichert (nie in Workflow-Dateien)
- Organisation-Secrets:
CORE_REPO_PATfür Cross-Repo-Zugriff - Repository-Secrets: Firebase SA Keys, App Store Credentials
- Kein Secret-Logging: GitHub Actions maskiert automatisch registrierte Secrets in Logs
Dependency Management¶
| Tool | Scope | Automatismus |
|---|---|---|
| Dependabot | GitHub-Abhängigkeiten | PRs bei neuen Versionen |
npm audit |
Cloud Functions (Node.js) | CI/CD blockiert bei HIGH/CRITICAL |
flutter pub outdated |
Flutter-Apps | Regelmäßiger Check |
12. Schwachstellenmeldung (Responsible Disclosure)¶
⚠️ Bitte KEINEN öffentlichen Issue erstellen¶
Sicherheitslücken bitte ausschließlich über sichere Kanäle melden.
Meldewege¶
- E-Mail: security@easysale.de
- GitHub Security Advisories: Tab "Security" → "Report a vulnerability"
Was der Bericht enthalten sollte¶
- Beschreibung der Schwachstelle
- Reproduktionsschritte (minimal reproduzierbares Beispiel)
- Potenzieller Schaden / Angreifszenario
- Betroffenes System (ERP, Shop, Functions, Firestore Rules)
- Vorgeschlagener Fix (sofern vorhanden)
- Kontaktdaten des Melders
Reaktionszeiten¶
| Schweregrad | Erstreaktion | Status-Update | Fix |
|---|---|---|---|
| 🔴 Kritisch | < 24h | < 48h | < 48–72h |
| 🟠 Hoch | < 48h | < 7 Tage | < 7 Tage |
| 🟡 Mittel | < 48h | < 7 Tage | < 30 Tage |
| 🟢 Niedrig | < 48h | < 14 Tage | Nächster Release-Zyklus |
Scope¶
Im Scope:
- easySale Shop System (Web-App & Mobile)
- easySale ERP System (Web-App & Mobile)
- Firebase Cloud Functions (functions/)
- Firestore & Storage Security Rules
- CI/CD-Workflows (GitHub Actions)
Nicht im Scope: - Social Engineering (Phishing, Vishing) - Physische Angriffe - Denial-of-Service (DoS/DDoS) - Schwachstellen in Drittanbieter-Diensten (Firebase, Google Cloud) selbst - Automatische Scanner-Findings ohne Nachweis der Ausnutzbarkeit
Koordinierte Offenlegung¶
- Melder kontaktiert uns privat
- Wir bestätigen den Empfang innerhalb von 48 Stunden
- Wir untersuchen und bewerten die Schwachstelle (max. 7 Tage)
- Wir entwickeln und testen einen Fix
- Fix wird deployed
- Koordinierte öffentliche Offenlegung gemeinsam mit dem Melder
Als Dankeschön für verantwortungsvolles Disclosure: öffentliche Nennung in Release Notes (auf Wunsch) sowie schriftliche Bestätigung.
13. Unterstützte Versionen¶
| Version | Sicherheitsupdates | Status |
|---|---|---|
| 1.x (aktuell) | ✅ Aktiv | Vollständiger Support |
| < 1.0 | ❌ | End of Life |
Hinweise für Contributor¶
- ✅ Niemals Credentials, API-Keys oder Secrets committen
- ✅
npm auditausführen vor Cloud Functions Änderungen - ✅
flutter pub outdatedprüfen bei Flutter-Änderungen - ✅ OWASP-Richtlinien beachten
- ✅ Input-Validierung an allen System-Grenzen
- ✅
SecureLoggerstattprint()/debugPrint()für sensible Kontexte - ✅ Firestore Security Rules bei jedem neuen Collection-Zugriff anpassen
- ✅ Keine Wildcards in CORS-Konfiguration für Produktions-Endpunkte
14. Kontakt¶
| Anliegen | Kontakt |
|---|---|
| Sicherheitslücken | security@easysale.de |
| Allgemeine Security-Fragen | security@easysale.de |
| Project Lead | Stefan Hafner |
Letzte Aktualisierung: 2. April 2026
Nächste Review: Juli 2026
Security Audit Version: OWASP Top 10 2021 · OWASP MASVS 2.0