PostOmnia

Sicherheit

Sicherheitsmaßnahmen und verantwortungsvolle Offenlegung.

Security Policy

Sicherheitsprobleme melden

Bitte melde Schwachstellen nicht öffentlich über Issues, sondern per E-Mail an

security@deinedomain.de (Platzhalter – bitte an deine Adresse anpassen). Wir

bestätigen den Eingang innerhalb von 72 Stunden.

Unterstützte Versionen

Es wird jeweils die aktuelle main-Version unterstützt.

Eingebaute Schutzmaßnahmen

• Passwörter: gehasht mit scrypt + zufälligem Salt (kein Klartext, kein MD5/SHA1).
• Sessions: zufällige 256-bit-Tokens mit Ablaufzeit; **alle Sessions werden bei

Passwort-Reset invalidiert**.

• Brute-Force-Schutz: Login sperrt eine E-Mail nach 5 Fehlversuchen für 15 Minuten

(src/ratelimit.js).

• Rate-Limiting: enges Limit auf allen /api/auth-Endpunkten (pro IP).
• Team-Isolation: jede Ressource (Konten, Posts, Medien) ist strikt an eine

teamId gebunden; Cross-Team-Zugriffe liefern 404.

• Secret-Maskierung: OAuth-Tokens, Passwörter & API-Keys werden in API-Antworten

und Logs maskiert (token|secret|password|…).

• Stripe-Webhook: Signaturprüfung (HMAC-SHA256) gegen STRIPE_WEBHOOK_SECRET;

ohne Secret ist der Endpunkt deaktiviert.

• Plan-Limits: serverseitig durchgesetzt (nicht im Client umgehbar).
• Production-Frontend: Browser können HTML, CSS, JavaScript und sichtbare Assets

immer herunterladen; das ist normal und kein Sicherheitsproblem. PostOmnia liefert

keine Source Maps aus (*.map -> 404), blockiert Dotfiles wie .env, deaktiviert

Directory Listing über Express Static und setzt Sicherheitsheader wie CSP,

X-Content-Type-Options, X-Frame-Options, Referrer-Policy und

Permissions-Policy.

Empfehlungen für den Produktivbetrieb

• Immer hinter TLS betreiben (deploy/ mit Caddy liefert automatische Zertifikate).
• Starke, individuelle Werte für OMNIPOST_ADMIN_PASSWORD und OMNIPOST_API_KEY setzen.
• Alle Secrets ausschließlich über Umgebungsvariablen/Secret-Manager, nie im Code.
• /metrics mit METRICS_TOKEN schützen, wenn öffentlich erreichbar.
• Für Multi-Instance-Betrieb Rate-Limits/Brute-Force-Zähler in einen geteilten Store

(z. B. Redis) auslagern – die aktuelle Implementierung ist single-instance.