Sécurité

Isolation stricte des données par organisation

Aucune organisation ne peut accéder aux données d'une autre. L'isolation est vérifiée à chaque niveau : au chargement (une requête ne remonte jamais que le périmètre du compte connecté), à l'autorisation (chaque action passe par une règle qui vérifie la propriété de la classe, de l'arbre ou de l'apprenant concerné), et à l'affichage. Au sein d'une même organisation, un formateur ne voit que ses propres classes ; seul l'administrateur de l'organisation dispose d'une vue consolidée. Cette étanchéité est couverte par une suite de tests automatisés dédiée, rejouée à chaque modification du code.

Hébergement en France

Le service et sa base de données sont hébergés par IONOS SARL (7 place de la Gare, 57200 Sarreguemines, France). Les rares prestataires qui interviennent sur une partie du service — Mollie pour le paiement — sont établis dans l'Union européenne. Des sauvegardes de la base sont réalisées et conservées sur ce même hébergement.

Chiffrement des échanges

Tout le trafic passe en HTTPS : une connexion en clair est automatiquement redirigée, et l'en-tête HSTS demande au navigateur de ne plus jamais tenter le HTTP sur le domaine. Le cookie de session est marqué Secure, HttpOnly et SameSite — il n'est ni lisible par un script, ni transmis depuis un site tiers.

Mots de passe et connexion

• Les mots de passe ne sont jamais stockés en clair : ils sont hachés avec bcrypt, à un coût supérieur au réglage par défaut du framework. Personne, pas même l'éditeur, ne peut les lire.
• 12 caractères minimum, sur tous les chemins qui définissent un mot de passe. Pas de règle de complexité imposée : une phrase longue protège mieux qu’un mot court parsemé de symboles.
• La connexion est verrouillée après cinq tentatives échouées, pour un couple email + adresse IP donné.
• Les messages d'erreur restent génériques : ils ne permettent pas de deviner si une adresse email correspond à un compte existant.
• Les liens de réinitialisation sont à durée de vie limitée, et le jeton correspondant est stocké haché en base.

Protection contre les attaques applicatives courantes

• Injection SQL : toutes les requêtes passent par une couche d'accès aux données qui sépare la requête de ses paramètres. Aucune saisie utilisateur n'est concaténée dans du SQL.
• XSS (script injecté) : tout contenu saisi est échappé à l'affichage, et les liens externes sont filtrés sur une liste blanche de protocoles (un lien « javascript: » ne peut pas être enregistré, ni rendu cliquable).
• CSRF : chaque formulaire et chaque action modifiant des données portent un jeton anti-rejeu vérifié côté serveur.
• En-têtes de sécurité HTTP : protection contre l'affichage du site dans une iframe tierce (clickjacking), interdiction de la réinterprétation des types de fichiers, limitation des informations transmises aux sites externes, désactivation des API navigateur inutilisées (caméra, micro, géolocalisation) et isolation du contexte de navigation.
• Une politique de sécurité du contenu (CSP) est déployée en mode observation : elle remonte les anomalies sans encore bloquer, le temps d'être éprouvée sur tous les écrans.
• Limites de débit sur les actions coûteuses ou sensibles (connexion, réinitialisation de mot de passe, imports, exports, recherche) pour contenir les tentatives automatisées.

Conformité RGPD

• Export de vos données à tout moment : depuis votre profil, tout formateur télécharge une archive contenant l'intégralité de ses données (un fichier par classe, un fichier par arbre de compétences), sans avoir à en faire la demande. C'est le droit d'accès et de portabilité (articles 15 et 20) en libre-service.
• Suppression du compte depuis le profil, sans passer par le support.
• Pour les établissements, une annexe RGPD de sous-traitance (article 28) précise les engagements de Wazadō en tant que sous-traitant.
• Aucun cookie publicitaire ni traceur tiers : un unique cookie de session, strictement nécessaire pour vous garder connecté. Les polices de caractères sont hébergées sur le site, donc aucune requête vers un service tiers n'est déclenchée par votre navigation.
• Vos données ne sont ni vendues, ni louées, ni utilisées pour entraîner un modèle d'intelligence artificielle.

Voir aussi : Politique de confidentialité · Annexe RGPD sous-traitance

Paiement

Les paiements sont traités par Mollie, prestataire agréé. Aucune donnée bancaire (numéro de carte, IBAN) ne transite par Wazadō ni n'y est stockée : vous êtes redirigé vers l'environnement sécurisé de Mollie, et seule la confirmation du paiement nous revient.

Maintenance et vérifications

• Les dépendances du projet sont auditées avant chaque mise en production ; toute faille connue est corrigée avant publication.
• Plus de 260 tests automatisés sont rejoués à chaque modification, dont une partie porte spécifiquement sur la sécurité : étanchéité entre organisations, autorisations, en-têtes HTTP, limites de débit, filtrage des liens.
• Les pratiques décrites sur cette page ont été revues au regard du référentiel OWASP ASVS, niveau 1, sur les exigences applicables à ce type d'application.

Signaler une faille

Si vous pensez avoir découvert une vulnérabilité, écrivez à chris@wazado.app avec le détail permettant de la reproduire. Tout signalement de bonne foi reçoit une réponse, et aucune poursuite ne sera engagée contre une personne ayant signalé une faille sans l'exploiter ni divulguer de données.