Skip to content
reader.me

Technische Notizen

Sicherheitsmodell

Wogegen reader.me schützt und wogegen nicht. Geschrieben für Security-Reviewer — kein Marketing.

Threat Model

reader.me ist eine SPA, die im Browser des Nutzers läuft. Die Angriffsfläche wird davon geprägt.

Wir schützen gegen

  • Dokument-Leak via Upload. Strukturell unmöglich.
  • Leak via Drittanbieter-JS. CSP verriegelt.
  • Schädliche PDFs gegen PDF.js. Pinned ≥4.2.67 mit Hardening.
  • Brute-Force auf Protect. AES-128 konservativ.
  • XSS via Dateiname.
  • Speicher-Druck. Workers >20 MB.

Wir schützen nicht gegen

  • Bösartige Browser-Erweiterungen.
  • OS-Kompromittierung.
  • MitM mit kooperativer CA.
  • CPU-Seitenkanäle.

Content Security Policy

CSP unter public/_headers. Höhepunkte:
  • default-src 'self'
  • 'unsafe-inline' Trade-off in Phase 1 (Astro Hydration).
  • connect-src ohne Dokument-Endpunkt.
  • frame-ancestors 'none'.
  • upgrade-insecure-requests.

Abhängigkeitsrichtlinie & CVE-Reaktion

Drei kritische Engines: PDF.js, pdf-lib, Tesseract.js.
  • Pinned in package.json.
  • Kritische CVE-SLA: 72 h.
  • Tesseract selbst gehostet.
  • Verifizieren — DevTools → Network. 30-Sek-Rezept.

Quality Gates in CI

  • Engine-Purity — kein DOM/fetch in core.
  • Unit-Tests — 97% Vitest.
  • E2E — Playwright pro PR.
  • Accessibility — axe-core.
  • Lighthouse CI — perf ≥95.

Vulnerability melden

Verantwortungsvolle Offenlegung per Email, um Nutzer nicht durch öffentlichen Bericht zu gefährden:

[email protected] — Beschreibung und minimale Reproduktionsschritte.

Bestätigung in 48 h, kritische Patches in 72 h. Credit im Changelog, außer Sie ziehen Anonymität vor.

Verwandtes

reader.me ist eine Idee von David Carrero, entwickelt bei Color Vivo Internet S.L.