Architektur im Überblick

Vereinfachter Datenfluss durch das aktuelle bewerbendenseitige Mail-System von ContactVault.

Moderne Ende-zu-Ende-Verschlüsselung

Alle sensiblen Inhalte werden mit einem authentifizierten Verfahren (XChaCha20‑Poly1305) verschlüsselt; die Schlüssel werden per HKDF‑SHA256 abgeleitet. Jeder Datensatz erhält eigenen Zufalls-Salt und Nonce, für starke Vertraulichkeit und Integrität.

• Schlüssel und Nonces pro Nachricht, um Wiederverwendung zu verhindern.
• Konstante Zeitvergleiche zur Reduktion von Timing-Leaks.

Anonymität durch Design

Arbeitgeber sehen standardmäßig keine persönliche E-Mail-Adresse der bewerbenden Person. ContactVault vergibt Postfachadressen auf Bewerbendenseite, damit Erstkontakt und Antworten stattfinden können, ohne das persönliche Postfach offenzulegen.

• Dedizierte ContactVault-Postfachadressen trennen Bewerbendenidentität von privaten Kontaktdaten.
• Strukturierte Antwortbuttons und normale Antworten bleiben beide im Mailprogramm des Arbeitgebers.

Signierte Links mit kurzer Lebensdauer

Verifikationslinks, Bewerbenden-Login-Links und sensible Aktionen sind durch HMAC-Signaturen, eingebettete Nonces und eindeutige Ablaufzeiten geschützt. Tokens werden bei jeder Nutzung geprüft und danach als verbraucht markiert.

Standardmäßig missbrauchsresistent

Öffentliche Einstiegspunkte erzwingen Burst-Limits, tägliche Kontingente, E-Mail/IP-Drosselung und optionalen Proof-of-Work, um automatisierten Missbrauch zu bremsen, ohne normale Bewerbende unnötig zu benachteiligen.

• Per-IP-Drosselung für öffentliche Versand- und Bewerbenden-Login-Pfade.
• Konfigurierbares Proof-of-Work-Gate für öffentliche Formulare.

Minimale Speicherung, klarer Lebenszyklus

Betriebsdaten werden nur so lange gespeichert, wie es für Zustellung, Antworten, Bewerbendenzugriff und Missbrauchsprävention erforderlich ist. Bereinigungsjobs löschen alte Daten automatisch.

Gehärtete Weboberfläche

Für typische Webrisiken gelten strikte Sicherheitsstandards.

• Öffentlicher Traffic endet am Apache-Reverse-Proxy; der App-Prozess bindet nur an localhost.
• Content-Security-Policy und Frame-Schutzmechanismen.
• HSTS und sichere Cookies, wo anwendbar, einschließlich strenger Bewerbenden-Sessions.
• Serverseitige Eingabevalidierung und Templates mit Auto-Escaping.

Betriebliche Schutzmaßnahmen

Detaillierte Audit-Logs, Health-Checks und Alarm-Schwellen helfen, Auffälligkeiten früh zu erkennen. Ausgehende E-Mails werden validiert, sensible Felder in Logs geschwärzt.

• Veränderliche Laufzeitdaten sind außerhalb des App-Code-Verzeichnisses isoliert.
• Die Applicant-Mail-Runtime ist hinter dem Reverse Proxy von der öffentlichen App-Oberfläche isoliert.
• Tägliche automatische Checks überwachen Konfigurationsdrift und kritische Pfade.

Meldung von Sicherheitslücken

Wenn Sie ein Sicherheitsproblem vermuten, nutzen Sie bitte unseren Kanal zur verantwortungsvollen Offenlegung. Wir prüfen Meldungen zeitnah und schätzen koordinierte Behebungen.

Nächste Schritte

• Entfernung verbleibender Debug-only-Auth-Oberflächen vor dem Produktions-Cutover.
• CSRF-Schutz, bevor neue authentifizierte Browser-Schreibflüsse auf `/v2` eingeführt werden.
• Mehr kontinuierliche Tests und Monitoring für Login-Ausstellung, Inbound-Mail und Abuse-Reporting.

Das sind schrittweise Upgrades auf einem Sicherheitsmodell, das bereits auf bewerbendengesteuerter Kommunikation aufbaut.

Sicherheits-Deep-Dives

• Runtime-Isolation erklärt: Warum App-Code und Daten getrennt sein müssen