Notes techniques
Modèle de sécurité
Ce que reader.me protège, ce qu'il ne protège pas, et comment des décisions comme "utiliser AES-128 au lieu de AES-256" ou "garder 'unsafe-inline' dans le CSP" ont été prises. Écrit pour les reviewers sécurité — pas de marketing.
Modèle de menaces
Nous défendons contre
- Fuite via upload. Architecture structurellement non-uploadante.
- Fuite via JS tiers. CSP avec
script-srcverrouillé. - PDF malveillants contre PDF.js. Pinné ≥4.2.67 (CVE-2024-4367) avec hardening.
- Brute-force du Protect. AES-128 conservateur (faiblesses connues AES-256).
- XSS via nom de fichier. Toujours rendu comme texte.
- Pression mémoire. Workers pour fichiers >20 MB.
Nous ne défendons pas contre
- Extensions malveillantes — hors périmètre.
- Compromission OS.
- MitM avec CA coopérative.
- Side channels CPU.
Content Security Policy
public/_headers. Points clés :default-src 'self'script-src+'unsafe-inline'(requis par Astro hydration ; coût Phase 1).connect-srcsans endpoint document.frame-ancestors 'none'.upgrade-insecure-requests.
Politique de dépendances & réponse CVE
- Versions pinnées dans package.json.
- SLA CVE critique : 72 h.
- Tesseract self-hosted pour éviter dépendance CDN tierce.
- Vérifiez la promesse — DevTools → Network. Voir la recette 30 sec.
Quality gates en CI
- Pureté du moteur — pas de DOM/fetch dans
core/. - Tests unitaires — 97% lignes Vitest.
- E2E — Playwright par PR.
- Accessibilité — axe-core sur 8 routes.
- Lighthouse CI — perf ≥95, a11y =100.
Signaler une vulnérabilité
Divulguez de manière responsable par email pour ne pas mettre les utilisateurs en danger :
[email protected] — description et étapes de reproduction minimales.
Accusé sous 48 h, patch critique sous 72 h. Crédit donné sauf préférence inverse.
Liens connexes
- Comment ça marche → — parcours architectural.
- Confidentialité → — la promesse en langage clair.
- vs iLovePDF / Smallpdf → — comparaison architecturale côte à côte.
reader.me est une idée de David Carrero, développé chez Color Vivo Internet S.L.