Woodle Career

PAR WOODLE LAB

Security & Compliance Whitepaper

Sécurité & conformité

Une plateforme construite pour mériter la confiance de ses utilisateurs.

Version1.0 — 2026

Édité parWoodle Lab

DPOdpo@woodlelab.com

À qui s'adresse ce document

Ce document présente la stratégie de sécurité et la conformité réglementaire de Woodle Career. Il s'adresse aux utilisateurs, partenaires, entreprises clientes, investisseurs et responsables conformité qui doivent évaluer le sérieux d'une plateforme manipulant des données de candidats à l'emploi.

La sécurité est l'un des trois critères structurels qui guident chaque choix d'ingénierie (sobriété, sécurité, autonomie), pas une couche posée après coup. Les sections qui suivent décrivent les garanties techniques, les contrôles d'accès, la conformité RGPD et la gouvernance des incidents.

Audit interne — juillet 2026. Le codebase a fait l'objet d'une revue défensive en six volets (120 routes API, RLS, agents IA, paiement, OAuth, secrets) : aucune faille critique, aucun contournement d'authentification, aucune fuite de données inter-utilisateurs. Sur les 21 points relevés, 17 ont été corrigés et 4 différés de façon documentée (durcissement de fond et dépendances transitives, tracés pour un prochain cycle). Le détail vit dans le dépôt, sous contrôle de version.

0 critique

Faille applicative — audit 6 volets

33/33

Tests E2E RLS réussis

17/21

Findings corrigés · 4 différés tracés

UE

Hébergement données principales

Stratégie de sécurité — quatre principes

1. Défense en profondeur

Plusieurs couches indépendantes : authentification, Row-Level Security au niveau de la base de données, validation d'entrée serveur, headers stricts, rate-limiting. Si une couche cède, les autres tiennent.

2. Sécurité par défaut

Aucune table sensible n'est lisible sans une politique d'accès explicite. Aucun consentement optionnel n'est activé par défaut. Toute écriture publique est rate-limitée et modérée si elle peut devenir publique.

3. Confidentialité par construction

Le candidat décide ce qu'il partage. Les notes Sirius, le journal de candidature et les contenus sensibles restent privés par défaut, même côté B2B éducation (offre Campus).

4. Auditable et révisable

Migrations versionnées en append-only, tests automatisés (373), E2E sur PostgreSQL réel pour la RLS, registre des incidents tenu à jour. Chaque correctif est traçable dans le code.

Périmètre couvert par ce document

Authentification, gestion des accès et sécurisation des API
Chiffrement en transit et au repos, gestion des mots de passe
Journalisation, monitoring, sauvegardes, continuité de service
Protection contre les attaques courantes (OWASP Top 10)
Conformité RGPD : registre, droits, conservation, suppression
Plan de gestion d'incident et notifications réglementaires

Page 02 · Données · Accès · Chiffrement

Woodle Career

Protection des données et contrôle d'accès

Pile de sécurité, vue d'ensemble

Périmètre réseau HTTPS forcé · HSTS preload (2 ans) · TLS 1.2+ géré par Vercel et Supabase

Headers HTTP CSP · X-Frame-Options DENY · Referrer-Policy strict-origin · Permissions-Policy verrouillée · X-Content-Type-Options nosniff

Authentification Supabase Auth · Email + mot de passe ou OAuth Google · JWT signé · cookies HttpOnly + Secure + SameSite=Lax

Autorisation Row-Level Security PostgreSQL sur 14 tables · validation Zod côté serveur · whitelists pour empêcher le mass-assignment

Limitation de débit Upstash Redis · sliding window sur Sirius, contact, reviews, export RGPD, booking public · token Bearer en comparaison à temps constant pour les crons

Stockage Bucket privé pour les CV · URLs signées TTL 15 min · policy storage ancrée sur l'identité utilisateur

Audit & supervision Sentry sans PII · journal d'activités utilisateur (export RGPD) · table de dédup Stripe · 373 tests automatisés

Authentification

Email + mot de passe ou Google OAuth (Supabase Auth)
Mots de passe hashés avec bcrypt, jamais stockés en clair
Mot de passe minimum 8 caractères, validation côté client et serveur
Lien de récupération de mot de passe à usage unique
Garde anti open-redirect sur le callback OAuth (paramètre next validé)
Âge minimum 16 ans déclaré à l'inscription (art. 8 RGPD)

Gestion des sessions

JWT Supabase, durée de vie courte (1h), refresh automatique
Cookies HttpOnly + Secure + SameSite=Lax
Déconnexion explicite révoque le refresh token côté serveur
État OAuth signé HMAC pour empêcher la réutilisation
Aucune session côté client tierce (ni LocalStorage de secrets)

Chiffrement

Surface	Mécanisme	Détail
En transit	TLS 1.2+	HTTPS forcé sur l'ensemble du périmètre (Vercel CDN + edge), HSTS preload 2 ans avec includeSubDomains.
Au repos (DB)	Chiffrement disque AWS	PostgreSQL Supabase sur AWS eu-west-1, volumes chiffrés AES-256 par défaut côté infrastructure.
Au repos (Storage)	Chiffrement objet	Bucket privé, URLs signées (15 minutes), policy basée sur auth.uid(). Aucun lien direct vers un fichier brut.
Mots de passe	bcrypt	Hash + sel géré par Supabase Auth. Aucun accès au plaintext, même côté équipe Woodle Lab.
Secrets API	Variables d'env Vercel	Service role Supabase, clés Stripe, Anthropic, Resend, Upstash. Jamais exposés au client (préfixe NEXT_PUBLIC_ interdit pour les secrets).
Webhooks	Signature vérifiée	Stripe : signature stripe-signature validée. Dédup d'event-id pour empêcher le rejeu.

Page 03 · API · OWASP · Monitoring · Continuité

Woodle Career

Sécurisation des API et résistance aux attaques

Protection contre les attaques courantes (OWASP Top 10)

Famille d'attaque	Mesure en place	Statut
Broken Access Control	Row-Level Security PostgreSQL sur 14 tables, helpers SECURITY DEFINER anti-récursion, garde is_coach_of_student.	Testé E2E 33/33
Injection (SQL, NoSQL)	Requêtes paramétrées via Supabase JS, validation Zod, sanitization des filtres de recherche PostgREST.	OK
Cross-Site Scripting (XSS)	React auto-escape · Content-Security-Policy stricte · helper safeExternalUrl sur les URLs rendues en href · escapeHtml sur les mails internes.	OK
Cross-Site Request Forgery (CSRF)	Cookies SameSite=Lax, en-tête Origin vérifié sur les webhooks, JWT.	OK
Server-Side Request Forgery (SSRF)	Aucun fetch côté serveur d'URL utilisateur arbitraire : tous les appels sortants visent des hôtes fixes (Stripe, Anthropic, Resend, agrégateurs d'offres).	OK
Mass assignment	Whitelists Zod strictes sur les routes mutantes critiques (candidatures, préférences, consentement).	OK
Open redirect	Garde getSafeNext sur l'/auth/callback et le login : seuls les chemins relatifs sont acceptés.	OK
Brute force / déni	Rate-limiting Upstash sur les endpoints sensibles (sliding window IP + utilisateur).	OK
Upload malveillant	Allowlist MIME, garde anti double-extension, Content-Disposition: attachment forcé pour les non-images.	OK
Dépendances vulnérables	npm audit suivi en CI, correctifs non-breaking appliqués. Advisories résiduelles transitives via next (build CSS + traitement d'image) — sans exposition runtime de l'app, planifiées au prochain bump majeur.	Suivi

Journalisation

Sentry : erreurs serveur, edge, client. PII désactivé.
Table activities : journal d'actions utilisateur (créations, exports, suppressions).
Logs Vercel : requêtes API, temps d'exécution, erreurs runtime.
Logs Stripe : tentatives de paiement, webhooks reçus.
Logs Supabase : connexions actives, requêtes ralenties.
Aucun mot de passe, JWT ou clé API n'apparaît dans les logs.

Sauvegardes et continuité

Sauvegardes PostgreSQL : quotidiennes (Supabase).
Point-in-Time Recovery disponible (upgrade plan payant).
Code et infrastructure as code versionnés (GitHub, Vercel).
Restauration testée sur cluster jetable lors des E2E.
Pas de point de défaillance unique : Vercel scale automatiquement, Supabase est multi-AZ AWS.
RPO < 24h, RTO < 4h en configuration Pro Supabase.

Monitoring & alertes

Source	Quoi observer	Réaction
Sentry	Erreurs serveur/client en temps réel, taux d'erreur par route	Notification email immédiate, investigation sous 4h
cron-job.org + GitHub Actions	État des 8 crons quotidiens (6 emails sur cron-job.org + 2 infra sur GH Actions), échec d'envoi d'emails	Notification en cas d'échec, replay manuel possible
Stripe Dashboard	Échecs de paiement, webhooks 5xx, fraude potentielle	Revue quotidienne, replay des webhooks en cas d'échec transitoire
Resend	Taux de délivrabilité, bounces, plaintes	Suppressions automatiques, alerte si taux de bounce > 5%
Supabase	Taille DB, requêtes lentes, connexions actives	Upgrade anticipé avant d'atteindre les limites

Page 04 · Incidents · RGPD · Conformité

Woodle Career

Gestion d'incident et conformité RGPD

Plan de gestion des violations de données (art. 33 et 34 RGPD)

Une procédure formalisée encadre toute violation de données personnelles susceptible d'engendrer un risque pour les droits et libertés des utilisateurs.

T+0

Détection & containment. Identification de la source (Sentry, alerte Supabase, signalement externe), arrêt de la fuite, rotation des clés impactées, ouverture d'un ticket interne.

T+2h

Évaluation du risque. Catégories de données touchées, volume d'utilisateurs affectés, conséquences potentielles. Décision : risque faible, modéré ou élevé.

T+24h

Notification CNIL si risque non négligeable. Déclaration via le formulaire CNIL (delai légal 72h, art. 33 RGPD).

T+72h

Notification individuelle si risque élevé. Envoi d'un email clair aux utilisateurs concernés via Resend (art. 34 RGPD). Contenu : nature de la violation, conséquences probables, mesures prises, contact DPO.

T+7j

Post-mortem & registre. Rédaction du post-mortem (cause racine, mesures correctives), inscription dans le registre interne des incidents. Revue des mesures de sécurité.

Point de contact : toute violation présumée doit être signalée à dpo@woodlelab.com. Le registre interne des incidents est tenu à jour et conservé indéfiniment.

Conformité RGPD

Droits des personnes — implémentés

Accès & portabilité (art. 15, 20) : bouton « Télécharger mes données » dans Paramètres, ZIP/JSON, gratuit pour tous.
Rectification (art. 16) : modification directe depuis le profil.
Effacement (art. 17) : suppression du compte depuis Paramètres → Zone danger, ou par email DPO.
Opposition (art. 21) : opt-out des traitements légitimes via les Paramètres.
Retrait du consentement : digest, Sirius Advice, partage école — révocables en un clic.
Plainte : dpo@woodlelab.com puis CNIL en dernier recours.

Délai de réponse : 1 mois (art. 12.3 RGPD), prolongeable de 2 mois si la demande est complexe.

Conservation et suppression

Données de compte et candidatures : durée d'activité + 30 jours.
Données de facturation : 10 ans (art. L123-22 Code de commerce).
Logs techniques : 90 jours maximum.
Logs Resend : 30 jours.
Sirius : aucune conservation côté Anthropic (mode no-retention).
Suppression effective sous 30 jours après demande.

Registre des traitements (art. 30)

9 traitements documentés avec finalité, base légale, destinataires, durée.
Sous-traitants : Supabase (UE), Stripe (UE), Resend (US CCT), Vercel (US CCT), Sentry (US CCT), Anthropic (US CCT), Upstash (UE).
Transferts hors UE encadrés par Clauses Contractuelles Types (CCT) Commission européenne.
Document complet disponible sur demande (dpo@woodlelab.com).

Public mineur & données sensibles

Âge minimum 16 ans déclaré à l'inscription (art. 8 RGPD France).
Aucune donnée de catégorie particulière (art. 9) collectée volontairement.
Modération des avis publics avant affichage (anti-spoofing).
Consentements explicites et révocables pour le partage école (offre Campus).

Engagement de transparence

La politique de confidentialité, les conditions générales et le registre RGPD sont publics, datés et maintenus. Tout audit externe ou question de partenaire est traité par le DPO sous 48h ouvrées : dpo@woodlelab.com.

Pour aller plus loin : Technical Architecture Overview (choix d'ingénierie), End-to-End Test Report (preuves de fonctionnement), Media Deck (vision produit).