Wie FolioDoc deine Dokumente schuetzt: Ein technischer Einblick
Wir sagen nicht einfach "Sicherheit ist uns wichtig." Hier steht genau, was wir tun — und was wir noch nicht tun.
Sicherheit ist kein Feature — sie ist das Fundament
Wenn du schon mal SaaS-Produkte evaluiert hast, kennst du den Satz bestimmt: "Wir nehmen Sicherheit ernst." Steht auf jeder Marketingseite, meistens neben einem Schloss-Symbol und sonst nichts. Bei FolioDoc wollten wir das anders machen.
Dieser Artikel geht durch die konkreten Sicherheitsmassnahmen, die wir implementiert haben — mit echten Algorithmen, konkreten Limits und realen Architekturentscheidungen. Wenn du als CTO, IT-Leiter oder Datenschutzbeauftragter herausfinden willst, ob FolioDoc sicher genug fuer die Dokumente deiner Organisation ist, dann ist dieser Artikel fuer dich. Wir sagen dir auch, was wir noch nicht gebaut haben, weil diese Ehrlichkeit wichtiger ist als jede Marketingaussage.
Alles laeuft ueber TLS
Jede Verbindung zu FolioDoc ist mit TLS 1.2 oder hoeher verschluesselt. Wir verwenden moderne Cipher Suites — ECDHE fuer den Schluesselaustausch, AES-GCM und CHACHA20-POLY1305 fuer die symmetrische Verschluesselung. Legacy-Protokolle wie TLS 1.0 und 1.1 sind komplett deaktiviert. Es gibt keine Ausnahmen und keinen Fallback auf unverschluesseltes HTTP.
Wir erzwingen HSTS (HTTP Strict Transport Security) mit einem max-age von 31.536.000 Sekunden — das ist ein volles Jahr — und wir sind in der HSTS-Preload-Liste eingetragen. Sobald dein Browser einmal FolioDoc besucht hat, wird er nicht einmal versuchen, eine unverschluesselte Verbindung aufzubauen. Ausserdem aktivieren wir OCSP Stapling, damit dein Browser die Gueltigkeit unseres Zertifikats pruefen kann, ohne einen separaten Request an die Zertifizierungsstelle zu senden.
Warum ist das fuer ein Dokumentensammel-Tool wichtig? Weil Magic Links, Datei-Uploads und Authentifizierungs-Tokens alle ueber die Leitung gehen. Wenn irgendetwas davon ueber HTTP passiert, koennte ein Angreifer im selben Netzwerk Tokens abfangen, Sessions kapern oder hochgeladene Dateien manipulieren. TLS ueberall ist die Grundlage, kein Bonus.
Magic Links: Keine Passwoerter, keine Accounts
Wenn du eine Dokumentenanfrage ueber FolioDoc verschickst, brauchen deine Empfaenger keinen Account und kein Passwort. Stattdessen bekommen sie einen Magic Link — eine einzigartige URL, die ihnen direkten Zugang zu ihrem Upload-Portal gibt. Das beseitigt eine riesige Quelle von Reibung und eliminiert die Sicherheitsrisiken, die mit passwortbasierter Authentifizierung fuer externe Nutzer einhergehen.
So funktioniert es unter der Haube: Wir generieren jeden Token mit Pythons secrets.token_urlsafe(32), was einen kryptographisch zufaelligen 32-Byte-String in URL-sicherem Base64 erzeugt. Das ergibt 256 Bit Entropie — Brute-Force ist nicht praktikabel. Bevor wir irgendetwas in der Datenbank speichern, hashen wir den Token mit SHA-256. Der Roh-Token existiert nur in der URL, die wir an den Empfaenger senden. Unsere Datenbank enthaelt niemals einen Wert, mit dem man den Link rekonstruieren koennte.
Jeder Magic Link laeuft 24 Stunden nach der Deadline der Anfrage ab. Wir tracken ausserdem, wie oft ein Link aufgerufen wurde. Wenn jemand den Link weiterleitet oder er irgendwo auftaucht, siehst du den Zugriffszaehler steigen — ein einfaches, aber wirksames Signal, dass etwas nicht stimmen koennte.
Dieser Ansatz ist bewusst gewaehlt. Einen Kunden oder externen Partner zu bitten, "einen Account zu erstellen und ein Passwort festzulegen," um ein paar Dokumente hochzuladen, ist schlechte UX und schlechte Sicherheit. Menschen verwenden Passwoerter wieder, vergessen sie und werden frustriert. Ein Einmal-Link, der auf eine bestimmte Anfrage beschraenkt ist, ist einfacher und sicherer.
Fuenf Schichten der Dateivalidierung
Datei-Uploads aus dem Internet anzunehmen ist von Natur aus riskant. Eine Datei namens "rechnung.pdf" koennte tatsaechlich eine ausfuehrbare Datei sein. Eine 2-GB-Datei koennte ein Denial-of-Service-Angriff sein. Wir validieren jeden Upload durch fuenf aufeinanderfolgende Pruefungen, bevor er akzeptiert wird.
Die vollstaendige Pipeline:
- Groessenpruefung: Jede Datei muss unter 25 MB liegen. Das wird serverseitig erzwungen, nicht nur im Browser.
- Content-Type-Allowlist: Wir akzeptieren nur bestimmte MIME-Typen — PDF, JPEG, PNG, GIF, DOC, DOCX, XLS, XLSX und CSV. Alles andere wird abgelehnt.
- Erweiterungsvalidierung: Die Dateierweiterung muss einem unserer erlaubten Typen entsprechen. Eine Datei ohne Erweiterung oder mit einer unerlaubten Erweiterung wird blockiert.
- Magic-Byte-Inspektion: Das ist die entscheidende Pruefung. Wir nutzen die filetype-Bibliothek, um die ersten Bytes der Datei zu lesen und ihr tatsaechliches Format aus dem Binaer-Header zu bestimmen. Wenn jemand malware.exe in rechnung.pdf umbenennt, sagt die Erweiterung PDF, aber die Magic Bytes sagen PE-Executable — und wir lehnen ab.
- Pro-Empfaenger-Kontingente: Jeder Empfaenger kann maximal 10 Dateien mit insgesamt hoechstens 100 MB hochladen. Das verhindert, dass ein einzelner Empfaenger eine Anfrage mit Daten flutet.
Diese Pruefungen laufen der Reihe nach. Wenn eine Datei bei einer Schicht durchfaellt, wird sie sofort abgelehnt — wir verschwenden keine Ressourcen fuer spaetere Pruefungen einer Datei, die schon eine fruehere nicht bestanden hat.
Wir berechnen ausserdem eine SHA-256-Pruefsumme fuer jede hochgeladene Datei und fuehren taegliche Integritaetspruefungen durch. Wenn eine Datei beschaedigt oder manipuliert wurde, erkennen wir das.
Authentifizierung und Rate Limiting
Fuer Kontoinhaber (die Personen, die Dokumentenanfragen erstellen und verwalten) verwenden wir JWT-basierte Authentifizierung. Access Tokens laufen nach 15 Minuten ab. Refresh Tokens sind 7 Tage gueltig und werden bei jeder Verwendung rotiert — sobald ein Refresh Token benutzt wird, wird der alte auf eine Blacklist gesetzt und kann nie wieder verwendet werden. Das begrenzt das Schadensfenster, wenn ein Token kompromittiert wird.
Wir begrenzen sensitive Endpunkte aggressiv. Login-Versuche sind auf 5 pro 15 Minuten limitiert, bezogen auf die Kombination aus E-Mail-Adresse und IP. Ein Angreifer kann also nicht einfach tausende Passwoerter gegen dein Konto ausprobieren. Das allgemeine API-Rate-Limit liegt bei 200 Anfragen pro Minute pro authentifiziertem Benutzer — hoch genug fuer normalen Gebrauch, niedrig genug um automatisierten Missbrauch zu stoppen.
Passwort-Reset-E-Mails haben einen 5-Minuten-Cooldown pro E-Mail-Adresse. Wenn du einen Reset ausloest, kannst du fuer dieselbe E-Mail-Adresse 5 Minuten lang keinen weiteren ausloesen, unabhaengig davon, von welcher IP die Anfrage kommt. Das verhindert Postfach-Flooding. Empfaenger-Benachrichtigungs-E-Mails haben einen aehnlichen 10-Minuten-Cooldown, um Spamming externer Empfaenger zu verhindern.
Was passiert, wenn du etwas loeschst
Wenn du eine Anfrage in FolioDoc loeschst, setzen wir nicht einfach ein Flag in der Datenbank. Wir fuehren eine vollstaendige Kaskaden-Loeschung durch: Alle Checklistenpunkte, Empfaengerdatensaetze, hochgeladene Antworten, Magic Links, Benachrichtigungshistorie und Eskalations-Events, die mit dieser Anfrage verknuepft sind, werden entfernt. Physische Dateien auf der Festplatte werden explizit geloescht, bevor die Datenbank-Kaskade laeuft.
Wenn eine Dateiloeschung fehlschlaegt — vielleicht ist das Speicher-Backend voruebergehend nicht erreichbar — ueberspringen wir sie nicht stillschweigend. Stattdessen erstellen wir einen PendingFileDeletion-Eintrag, der automatisch erneut versucht wird. Ein geplanter Task greift diese Eintraege auf und versucht sie erneut. Dateien werden niemals leise auf der Festplatte verwaist.
Jede Loeschung wird in einem DeletionLog mit Zeitstempel, Ausloeser, geloeschten Objekten und Anzahl der betroffenen Datensaetze protokolliert. Wir loggen keine sensitiven Inhalte — nur genug, um einen Audit Trail aufrechtzuerhalten.
Fuer DSGVO-Konformitaet werden abgeschlossene und abgelaufene Anfragen nach 90 Tagen automatisch bereinigt (konfigurierbar ueber Umgebungsvariable). Kontoloeschung entfernt alles — alle Anfragen, alle Dateien, das Marken-Logo, alles. Wir bieten ausserdem Self-Service-Datenexport im JSON- und CSV-Format an, damit du dein Recht auf Datenportabilitaet ausueben kannst, bevor du irgendetwas loeschst.
Security Headers und Output-Sanitisierung
Wir setzen Content-Security-Policy-Header, die Objekt-Einbettungen und Frame-Einbettung blockieren (object-src 'none', frame-ancestors 'none'). X-Content-Type-Options ist auf nosniff gesetzt, um zu verhindern, dass Browser MIME-Typen raten. Referrer-Policy ist auf no-referrer gesetzt, damit wir niemals URLs — einschliesslich Magic-Link-Tokens — in Referrer-Headern preisgeben.
Beim Datei-Download erzwingen wir den Content-Type auf application/octet-stream. Das weist den Browser an, die Datei herunterzuladen, anstatt sie inline zu rendern, was eine Klasse von Angriffen verhindert, bei denen eine boesartige HTML-Datei als Dokument getarnt JavaScript im Kontext unserer Domain ausfuehren koennte.
CSV-Exporte werden gegen Formel-Injection sanitisiert. Jeder Zellwert, der mit =, +, - oder @ beginnt, wird mit einem Tab-Zeichen praefixiert, um zu verhindern, dass Tabellenkalkulationsprogramme den Wert als Formel interpretieren. Das stoppt einen Angreifer daran, etwas wie =HYPERLINK("http://evil.com","Klick hier") in ein Feld einzuschleusen, das spaeter exportiert wird.
Antivirus-Scanning mit ClamAV
Zusaetzlich zu unserer fuenfschichtigen Dateivalidierung scannen wir jetzt jede hochgeladene Datei mit ClamAV, der weit verbreiteten Open-Source-Antivirus-Engine. Die Scans laufen asynchron direkt nach dem Upload — deine Empfaenger bemerken keine Verzoegerung, aber im Hintergrund pruefen wir die Datei gegen ClamAVs Signaturdatenbank. Wird eine Datei als infiziert erkannt, loeschen wir sie sofort und markieren den Upload als abgelehnt. Keine infizierte Datei schafft es jemals in deine Anfrage.
Trotzdem wollen wir ehrlich sein: Keine Antivirus-Loesung erkennt 100 % aller Bedrohungen. Neue Malware-Varianten tauchen staendig auf, und es gibt immer ein Zeitfenster zwischen dem Auftauchen einer Bedrohung und der Aktualisierung der Signaturen. ClamAV ist eine starke Verteidigungsschicht, aber keine Garantie. Wir empfehlen dir und deinem Team, Dateien auch auf euren eigenen Rechnern mit aktuellem Endpoint-Schutz zu pruefen, bevor ihr sie oeffnet. Unser Scanning ist eine weitere Schicht im Sicherheits-Stack, kein Ersatz fuer eure eigenen Sicherheitspraktiken.
Was wir (noch) nicht tun
Wir glauben, dass Transparenz ueber Luecken nuetzlicher ist als so zu tun, als gaebe es keine.
Wir bieten keine Ende-zu-Ende-Verschluesselung an. Dateien sind beim Transport ueber TLS verschluesselt und koennen je nach Hosting-Konfiguration im Ruhezustand verschluesselt werden (z.B. EBS-Verschluesselung auf AWS), aber wir implementieren keine clientseitige Verschluesselung, bei der nur der Empfaenger den Entschluesselungsschluessel besitzt. Fuer die meisten Dokumentensammel-Workflows reicht TLS plus At-Rest-Verschluesselung aus, aber wir wollen hier klar sein.
Interessiert an den vollstaendigen Details? Schau dir unsere /security-Seite fuer die komplette Liste an, oder lies unseren Auftragsverarbeitungsvertrag unter /dpa.
Sicherheit ist nie fertig. Wir ueberpruefen kontinuierlich unsere Implementierung, verfolgen neue Schwachstellen und aktualisieren unsere Abhaengigkeiten. Wenn du Fragen zu irgendetwas davon hast, oder wenn du etwas gefunden hast, das wir fixen sollten, melde dich unter security@foliodoc.com. Wir hoeren lieber von dir als aus einem Incident Report.