Politique de sécurité

Progenda intègre toutes les techniques modernes de sécurisation des applications web. Afin de ne pas affaiblir l’intégrité de nos mesures de sécurité, la liste ci-dessous n’est pas exhaustive. Toutes nos pages sont protégées par une liste blanche stricte de règles « Content Security Policy ». Ces règles décrivent les origines possibles du code s’exécutant sur vos pages et les connexions autorisées. Elles servent de protection supplémentaire en cas de faille dans notre code ou celui de nos fournisseurs. Toutes les actions qui entraînent un changement d’état sont protégées par un token CSRF. Ces actions nécessitent toujours une méthode HTTP appropriée (POST, PUT, PATCH ou DELETE). Les requêtes depuis une origine externe autorisée (CORS) sont filtrées par une liste blanche stricte et sont limitées à certaines pages contenant uniquement de l’information publique. Nous interdisons l’intégration de Progenda dans une Iframe, afin d’éviter tout click-jacking. Tous les liens ouvrant de nouveaux onglets sont protégés par un attribut « noopener », empêchant une prise de contrôle de la page initiale par la page ouverte. Notre système de sessions est basé sur des cookies qui ne peuvent être lus par du code s’exécutant sur le navigateur (« HttpOnly »), qui ne peuvent être envoyés au travers d’une connexion non-sécurisée (« Secure ») et qui ne peuvent être envoyés lors d’une requête depuis une page étrangère à Progenda (« SameSite »). Les mots de passe de nos utilisateurs sont hashés avec l’algorithme BCrypt avant d’être enregistrés en base de données. L’accès à notre API se fait à l’aide de jetons (« tokens ») générés depuis l’interface d’administration. Après génération, le token est également hashé avec l’aide de BCrypt avant d’être enregistré. Ces tokens sont révocables depuis l’interface. Toutes les requêtes s’adressant aux serveurs de Progenda doivent être établies au travers d’une connexion chiffrée (HTTPS). Les requêtes en clair sont redirigées. Notre domaine est protégé par une politique HSTS, interdisant au navigateur d’utiliser une connexion non-sécurisée. Cette information a été inscrite dans le code source des navigateurs utilisant des listes de domaines protégés (« preload »). Nous n’autorisons plus les protocoles de chiffrement antérieurs à TLS 1.1. Cela signifie également que les versions de Internet Explorer antérieures à Internet Explorer 11 ne sont plus supportées. Les autorités habilitées à générer un certificat pour nos domaines sont inscrites dans le champ DNS CAA. Nous monitorons la publication de nouveaux certificats pour nos domaines via le programme Certificate Transparency. Nos champs DNS sont également protégés par l’extension DNSSEC. Les connexions entre notre fournisseur Cloudflare et nos serveurs « origine » sont également chiffrées. Seuls les serveurs de Cloudflare peuvent accéder au service web sur nos serveurs, protégeant l’identité de nos serveurs aux yeux des robots parcourant le net. Nos emails sont signés et authentifiés via le protocole DKIM. Les adresses habilitées à envoyer des emails en notre nom sont spécifiées via le champ SPF. Ces deux mesures sont imposées de manière stricte par notre champ DMARC. Tout email ne respectant pas les conditions ne peut atteindre la boîte de réception du destinataire. Plusieurs politiques anti-DoS ont été mises en place : pour chaque requête HTTP, toutes les procédures trop longues ou qui peuvent être exécutées plus tard sont placées en tâche de fond, afin de garantir une réponse rapide et de ne pas remplir le pool de requêtes. Toutes nos boucles n’opérant pas sur des collections sont limitées par des compteurs supplémentaires, afin d’éviter toute boucle infinie. Nos expressions régulières (regex) n’utilisent pas de backtracking. La prise de rendez-vous est protégée par plusieurs mesures de sécurité, telles que des captchas, l’enregistrement de l’adresse IP sur chaque rendez-vous pris, la limitation du nombre de rendez-vous sur base de l’adresse IP ou de l’adresse email ou l’utilisation de whitelist et de blacklist de personnes pouvant prendre rendez-vous (au choix de l’utilisateur). Nous avons également mis en place des politiques de suppression de données afin d’éviter toute perte de données involontaire. Ainsi, selon le type de ressource à supprimer, celle-ci sera uniquement marquée comme supprimée, marquée comme supprimée et à supprimer réellement à une date ultérieure ou bien supprimée immédiatement. Toutes les données au coeur de Progenda sont également exportables depuis l’interface. Nous considérons que tout client désirant arrêter le service doit pouvoir récupérer ses données aussi facilement que possible et que l’accès aux données ne doit pas constituer un frein au départ du client. Nous avons évalué les deux mesures de sécurité HPKP et SRI comme étant inutiles au vu des mesures déjà en place et/ou dangereuses pour la stabilité du système.