Securité

Hébergement

Nos applications sont hébergées sur des serveurs fournis par la société OVH SAS , au sein des gammes So you Start et OVH Private Cloud. Nos serveurs tournent sous Ubuntu 22.04. Les accès d'administration à ces serveurs sont réservés à un très petit nombre de personnes et exigent des techniques d'authentification fortes (clefs RSA obligatoires et désactivation des accès par mots de passe). Vous pouvez consulter le détail de notre configuration des accès SSH grâce au site Rebex SSH Check .

Chiffrement des disques

Sur nos serveurs, vos données sont sauvegardées chiffrées. Sur nos serveurs de la gamme OVH Private Cloud (fournis par OVH SAS), vos données sont enregistrées sur des partitions chiffrées par la technologie LUKS (nous utilisons la version cryptsetup 2.4.3).

Chiffrement des échanges

Les données qui transitent entre votre terminal et nos serveurs applicatifs sont chiffrées, aussi bien à l'envoi qu'à la réception. Cela vous est confirmé par le cadenas dans la barre d'adresse de votre navigateur et l'URL qui indique l'utilisation d'HTTPS (dans notre cas, HTTP avec un chiffrement TLS 1.3).

Vous pouvez consulter le détail de notre configuration du chiffrement HTTPS grâce au site SSL Labs . Les certificats authentifiant nos serveurs sont fournis par Let's Encrypt , une autorité de certification automatisée et ouverte.

Nous redirigeons tout le traffic HTTP (port 80) en HTTPS (port 443) et avons mis en place le paramétrage HSTS pour indiquer à votre navigateur de faire de même.

Suivi des recommandations OWASP Top 10

OWASP est une communauté libre et ouverte travaillant sur la sécurité des applications web. Elle publie notamment une liste des dix risques de sécurité les plus critiques. Nous portons une attention particulière aux dix risques mentionnés dans la dernière version 2021 de cette liste.

• Injection: Nous n'écrivons aucune requête SQL manuellement. Toutes nos requêtes vers la base de données sont générées par l'ORM Laravel Eloquent qui utilise la liaison de paramètres PDO pour éviter les injections SQL.
• Authentification incorrecte : Nos serveurs sont protégés contre les attaques par énumération de comptes et les tentatives massives par dictionnaires de mots de passe. Notre plateforme impose à tous nos salariés d'utiliser des mots de passe de force 4 sur l'échelle Dropbox zxcvbn .
• Divulgation de données sensibles : Nous ne stockons pas vos données bancaires car celles-ci sont directement manipulées par notre partenaire Stripe . Vos mots de passe sont chiffrés par l'algorithme bcrypt après salage aléatoire et ne sont donc jamais conservés en clair. Plus généralement, l'ensemble de vos données en transit ou sur nos disques sont chiffrées (voir détails plus haut).
• XML External Entities : Nos API internes et externes reposent toutes sur le format JSON et ne sont donc pas concernées par les attaques par XML. Les fichiers Excel (au format XLSX, basé sur XML) que vous envoyez pour analyse sur nos serveurs sont manipulés par des librairies XML Java qui ont été configurées selon les recommandations recommandations OWASP recommendations pour Java.
• Autorisation incorrecte : Chaque requête HTTP effectuée vers notre application est préalablement analysée pour vérifier que l'utilisateur a les permissions suffisantes pour effectuer l'action demandée. Il est en particulier impossible à un utilisateur d'accéder aux données d'autres utilisateurs.
• Mauvaise configuration de sécurité : Nos applications sont déployées sur des serveurs Ubuntu nus de manière isolée. Nous utilisons des scripts d'installation standard pour s'assurer que nos configurations de sécurité sont identiques.
• Cross-Site Scripting : Toutes les valeurs saisies par un utilisateur et injectées dans le rendu de nos pages sont préalablement échapées par le moteur de rendu Laravel Blade pour éviter les attaques de type XSS.
• Désérialisation non sécurisée : Nous ne désérialisons jamais un bloc de données directement fourni par un utilisateur. Notre usage de la sérialisation est limité à la mise en cache de certaines vues.
• Utilisation de composants vulnérables : Nous utilisons des outils de gestion des dépendances qui nous permettent de mettre facilement à jour en une fois tous les composants dont nous dépendons : npm pour les dépendances JavaScript de la couche frontale, compose pour les dépendances PHP de la couche serveur et maven pour les dépendances Java de nos moteurs de calcul.
• Journalisation et suivi insuffisants : Nous historisons toutes les tentatives, réussies ou échouées, de connexion à notre plateforme. Les requêtes au niveau système sont elles aussi journalisées et limitées en volume.

L'utilisation et la bonne configuration de Laravel nous prémunissent aussi des attaques de type CSRF (un des dix risques de la version 2021 de la liste OWASP). En effet, tous nos points d'entrée générant une action (requêtes HTTP de type DELETE, POST, PUT ou UPDATE) exigent la présence d'un jeton lié à la session.

Tests d'intrusion

Nous faisons réaliser des tests d’intrusion chaque année afin d’évaluer la sécurité de nos infrastructures et applications. Nos derniers test d'intrusion (en boîte noire et en boîte grise) ont été conduits par la société Synetis en Janvier 2024.

Signalement des vulnérabilités

Since the first release, we have been inviting our users and security researchers to report vulnerabilities they suspect or have identified. To do this, we follow the requirements of securitytxt.org (a proposed standard to allow websites to define their security policy). In particular, we have set up a dedicated contact address and we respond to all incoming messages.