Autoévaluation de Cybernetics au regard de l'OWASP Application Security Verification Standard (ASVS) 5.0, niveau 2 : chaque exigence est vérifiée dans le code de la plateforme, avec son statut et une réponse factuelle.

Couverture par chapitre

Couverture = (exigences « Oui » + ½ × exigences « Partiellement ») ÷ exigences applicables (hors « Sans objet »). Calculée au 27/09/2026 ; elle est mise à jour à chaque évolution.

Cette page complète l'autoévaluation OWASP Secure Coding Practices chez Cybernetics, fondée sur la checklist OWASP Secure Coding Practices. L'ASVS est plus exigeant : ses exigences sont testables et classées par niveau.

1.1.1 · niveau 2 · Vérifier que les entrées sont décodées ou déséchappées vers une forme canonique une seule fois, qu'elles ne sont décodées que lorsque des données encodées sous cette forme sont attendues, et que cela est fait avant tout traitement ultérieur de l'entrée, par exemple que cela n'est pas effectué après la validation ou l'assainissement des entrées.

Verify that input is decoded or unescaped into a canonical form only once, it is only decoded when encoded data in that form is expected, and that this is done before processing the input further, for example it is not performed after input validation or sanitization.

Réponse de Cybernetics : Partiellement. Le framework décode les entrées une seule fois avant la validation ; une donnée de configuration de champ personnalisé est encore décodée une seconde fois après la validation, et sa correction est planifiée.

​

1.1.2 · niveau 2 · Vérifier que l'application effectue l'encodage et l'échappement des sorties soit comme étape finale avant leur utilisation par l'interpréteur auquel elles sont destinées, soit par l'interpréteur lui-même.

Verify that the application performs output encoding and escaping either as a final step before being used by the interpreter for which it is intended or by the interpreter itself.

Réponse de Cybernetics : Partiellement. L'échappement est fait au moment du rendu par les moteurs de gabarits (interface et e-mails) ; une insertion non échappée subsiste dans un modèle d'e-mail, et sa correction est planifiée.

​

1.2.1 · niveau 1 · Vérifier que l'encodage de sortie d'une réponse HTTP, d'un document HTML ou d'un document XML est adapté au contexte requis, par exemple en encodant les caractères pertinents pour les éléments HTML, les attributs HTML, les commentaires HTML, le CSS ou les champs d'en-tête HTTP, afin d'éviter de modifier la structure du message ou du document.

Verify that output encoding for an HTTP response, HTML document, or XML document is relevant for the context required, such as encoding the relevant characters for HTML elements, HTML attributes, HTML comments, CSS, or HTTP header fields, to avoid changing the message or document structure.

Réponse de Cybernetics : Partiellement. Le contenu HTML de l'interface et des e-mails est encodé automatiquement selon son contexte ; un champ est encore inséré sans échappement dans un modèle d'e-mail.

​

1.2.2 · niveau 1 · Vérifier que, lors de la construction dynamique d'URL, les données non fiables sont encodées selon leur contexte (par ex. encodage URL ou encodage base64url pour les paramètres de requête ou de chemin). S'assurer que seuls des protocoles d'URL sûrs sont autorisés (par ex. interdire javascript: ou data:).

Verify that when dynamically building URLs, untrusted data is encoded according to its context (e.g., URL encoding or base64url encoding for query or path parameters). Ensure that only safe URL protocols are permitted (e.g., disallow javascript: or data:).

Réponse de Cybernetics : Partiellement. Les URL de services saisies par les clients sont limitées à HTTPS ; certaines URL construites dynamiquement (dans l'interface et vers les services tiers) n'encodent pas encore tous leurs paramètres, et les schémas acceptés pour les liens de preuve sont trop larges.

​

1.2.3 · niveau 1 · Vérifier que l'encodage ou l'échappement de sortie est utilisé lors de la construction dynamique de contenu JavaScript (y compris JSON), afin d'éviter de modifier la structure du message ou du document (pour éviter l'injection JavaScript et JSON).

Verify that output encoding or escaping is used when dynamically building JavaScript content (including JSON), to avoid changing the message or document structure (to avoid JavaScript and JSON injection).

Réponse de Cybernetics : Oui. Le JSON est toujours produit par les sérialiseurs du framework, et aucun code JavaScript n'est construit à partir de données d'utilisateur.

​

1.2.4 · niveau 1 · Vérifier que la sélection de données ou les requêtes vers les bases de données (par ex. SQL, HQL, NoSQL, Cypher) utilisent des requêtes paramétrées, des ORM, des frameworks d'entités, ou sont autrement protégées contre l'injection SQL et les autres attaques par injection en base de données. Cela s'applique également à l'écriture de procédures stockées.

Verify that data selection or database queries (e.g., SQL, HQL, NoSQL, Cypher) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from SQL Injection and other database injection attacks. This is also relevant when writing stored procedures.

Réponse de Cybernetics : Oui. Les requêtes passent par l'ORM ou par des requêtes paramétrées ; les rares fragments SQL dynamiques n'utilisent que des constantes internes ou des valeurs issues d'une liste fermée.

​

1.2.5 · niveau 1 · Vérifier que l'application se protège contre l'injection de commandes du système d'exploitation et que les appels au système d'exploitation utilisent des requêtes système paramétrées ou un encodage de sortie contextuel pour la ligne de commande.

Verify that the application protects against OS command injection and that operating system calls use parameterized OS queries or use contextual command line output encoding.

Réponse de Cybernetics : Partiellement. Les outils internes appellent le système avec des arguments séparés ; certaines commandes de l'agent passent par PowerShell avec un échappement encore incomplet, et un connecteur utilise un outil en ligne de commande avec une donnée non validée strictement. Leur durcissement est planifié.

​

1.2.6 · niveau 2 · Vérifier que l'application se protège contre les vulnérabilités d'injection LDAP, ou que des contrôles de sécurité spécifiques visant à empêcher l'injection LDAP ont été mis en place.

Verify that the application protects against LDAP injection vulnerabilities, or that specific security controls to prevent LDAP injection have been implemented.

Réponse de Cybernetics : Oui. Les requêtes d'annuaire de l'agent utilisent uniquement des filtres fixes, jamais construits à partir d'une donnée d'utilisateur.

​

1.2.7 · niveau 2 · Vérifier que l'application est protégée contre les attaques par injection XPath en utilisant le paramétrage des requêtes ou des requêtes précompilées.

Verify that the application is protected against XPath injection attacks by using query parameterization or precompiled queries.

Réponse de Cybernetics : Sans objet. Aucune requête XPath n'est utilisée.

​

1.2.8 · niveau 2 · Vérifier que les processeurs LaTeX sont configurés de manière sécurisée (par exemple en n'utilisant pas l'option "--shell-escape") et qu'une liste d'autorisation de commandes est utilisée pour empêcher les attaques par injection LaTeX.

Verify that LaTeX processors are configured securely (such as not using the "--shell-escape" flag) and an allowlist of commands is used to prevent LaTeX injection attacks.

Réponse de Cybernetics : Sans objet. Aucun moteur LaTeX n'est utilisé.

​

1.2.9 · niveau 2 · Vérifier que l'application échappe les caractères spéciaux dans les expressions régulières (généralement à l'aide d'une barre oblique inverse) afin d'éviter qu'ils ne soient interprétés à tort comme des métacaractères.

Verify that the application escapes special characters in regular expressions (typically using a backslash) to prevent them from being misinterpreted as metacharacters.

Réponse de Cybernetics : Oui. Aucune expression régulière n'est construite à partir d'une entrée d'utilisateur, et les motifs de recherche textuelle sont échappés.

​

1.3.1 · niveau 1 · Vérifier que toute entrée HTML non fiable provenant d'éditeurs WYSIWYG ou similaires est assainie à l'aide d'une bibliothèque d'assainissement HTML reconnue et sécurisée, ou d'une fonctionnalité équivalente du framework.

Verify that all untrusted HTML input from WYSIWYG editors or similar is sanitized using a well-known and secure HTML sanitization library or framework feature.

Réponse de Cybernetics : Partiellement. L'application n'accepte pas de HTML en saisie et n'a pas d'éditeur de texte riche ; un texte saisi est toutefois inséré comme HTML dans un modèle d'e-mail sans assainissement, et sa correction est planifiée.

​

1.3.2 · niveau 1 · Vérifier que l'application évite l'utilisation de eval() ou d'autres fonctionnalités d'exécution dynamique de code telles que Spring Expression Language (SpEL). Lorsqu'il n'existe aucune alternative, toute entrée utilisateur incluse doit être assainie avant d'être exécutée.

Verify that the application avoids the use of eval() or other dynamic code execution features such as Spring Expression Language (SpEL). Where there is no alternative, any user input being included must be sanitized before being executed.

Réponse de Cybernetics : Oui. Le code n'utilise aucune exécution dynamique (eval ou équivalent), et la CSP de l'interface l'interdit.

​

1.3.3 · niveau 2 · Vérifier que les données transmises à un contexte potentiellement dangereux sont préalablement assainies afin d'appliquer des mesures de sûreté, par exemple en n'autorisant que les caractères sûrs pour ce contexte et en tronquant les entrées trop longues.

Verify that data being passed to a potentially dangerous context is sanitized beforehand to enforce safety measures, such as only allowing characters which are safe for this context and trimming input which is too long.

Réponse de Cybernetics : Partiellement. Les identifiants transmis aux services tiers sont en grande partie contraints par des formats stricts ; certaines données réutilisées dans des requêtes tierces ou dans un outil en ligne de commande ne sont pas encore filtrées.

​

1.3.4 · niveau 2 · Vérifier que le contenu scriptable des fichiers Scalable Vector Graphics (SVG) fournis par l'utilisateur est validé ou assaini afin de ne contenir que des balises et attributs (tels que le dessin de graphiques) sûrs pour l'application, par ex. ne contenant ni scripts ni foreignObject.

Verify that user-supplied Scalable Vector Graphics (SVG) scriptable content is validated or sanitized to contain only tags and attributes (such as draw graphics) that are safe for the application, e.g., do not contain scripts and foreignObject.

Réponse de Cybernetics : Sans objet. Aucun envoi de fichier, SVG compris, n'est accepté ; les images configurables sont chargées comme de simples images, et la CSP limite leurs sources.

​

1.3.5 · niveau 2 · Vérifier que l'application assainit ou désactive le contenu scriptable ou en langage de gabarit à expressions fourni par l'utilisateur, tel que Markdown, les feuilles de style CSS ou XSL, BBCode ou similaires.

Verify that the application sanitizes or disables user-supplied scriptable or expression template language content, such as Markdown, CSS or XSL stylesheets, BBCode, or similar.

Réponse de Cybernetics : Sans objet. Aucun contenu Markdown, feuille de style ou langage de gabarit fourni par l'utilisateur n'est interprété.

​

1.3.6 · niveau 2 · Vérifier que l'application se protège contre les attaques de type Server-side Request Forgery (SSRF), en validant les données non fiables par rapport à une liste d'autorisation de protocoles, de domaines, de chemins et de ports, et en assainissant les caractères potentiellement dangereux avant d'utiliser ces données pour appeler un autre service.

Verify that the application protects against Server-side Request Forgery (SSRF) attacks, by validating untrusted data against an allowlist of protocols, domains, paths and ports and sanitizing potentially dangerous characters before using the data to call another service.

Réponse de Cybernetics : Oui. Les adresses de services saisies par les clients sont limitées à HTTPS, sans identifiants intégrés ; à chaque connexion, les adresses privées, internes et de métadonnées cloud sont refusées, et les redirections sont désactivées.

​

1.3.7 · niveau 2 · Vérifier que l'application se protège contre les attaques par injection de gabarit (template injection) en n'autorisant pas la construction de gabarits à partir d'entrées non fiables. Lorsqu'il n'existe aucune alternative, toute entrée non fiable incluse dynamiquement lors de la création du gabarit doit être assainie ou strictement validée.

Verify that the application protects against template injection attacks by not allowing templates to be built based on untrusted input. Where there is no alternative, any untrusted input being included dynamically during template creation must be sanitized or strictly validated.

Réponse de Cybernetics : Oui. Tous les gabarits sont des fichiers statiques : aucun gabarit n'est compilé à partir d'une donnée d'utilisateur.

​

1.3.8 · niveau 2 · Vérifier que l'application assainit correctement les entrées non fiables avant leur utilisation dans des requêtes Java Naming and Directory Interface (JNDI) et que JNDI est configuré de manière sécurisée pour empêcher les attaques par injection JNDI.

Verify that the application appropriately sanitizes untrusted input before use in Java Naming and Directory Interface (JNDI) queries and that JNDI is configured securely to prevent JNDI injection attacks.

Réponse de Cybernetics : Sans objet. La pile n'utilise ni Java ni JNDI.

​

1.3.9 · niveau 2 · Vérifier que l'application assainit le contenu avant de l'envoyer à memcache afin d'empêcher les attaques par injection.

Verify that the application sanitizes content before it is sent to memcache to prevent injection attacks.

Réponse de Cybernetics : Sans objet. Aucun cache memcache ni Redis n'est utilisé ; les compteurs de limitation sont stockés en base via des requêtes paramétrées.

​

1.3.10 · niveau 2 · Vérifier que les chaînes de format susceptibles d'être résolues de manière inattendue ou malveillante lors de leur utilisation sont assainies avant d'être traitées.

Verify that format strings which might resolve in an unexpected or malicious way when used are sanitized before being processed.

Réponse de Cybernetics : Oui. Aucune chaîne de format n'est construite à partir de données d'utilisateur, et les journaux sont structurés.

​

1.3.11 · niveau 2 · Vérifier que l'application assainit les entrées utilisateur avant de les transmettre aux systèmes de messagerie afin de se protéger contre l'injection SMTP ou IMAP.

Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection.

Réponse de Cybernetics : Oui. Les e-mails partent par l'API d'un prestataire, en JSON structuré, jamais par une commande SMTP construite à la main.

​

1.4.1 · niveau 2 · Vérifier que l'application utilise des chaînes de caractères sûres en mémoire, des copies mémoire plus sûres et une arithmétique de pointeurs sûre afin de détecter ou d'empêcher les débordements de pile, de tampon ou de tas.

Verify that the application uses memory-safe string, safer memory copy and pointer arithmetic to detect or prevent stack, buffer, or heap overflows.

Réponse de Cybernetics : Sans objet. Le code est écrit dans des langages à mémoire gérée (TypeScript sur Node.js et Deno).

​

1.4.2 · niveau 2 · Vérifier que des techniques de validation du signe, de la plage et des entrées sont utilisées pour empêcher les débordements d'entiers.

Verify that sign, range, and input validation techniques are used to prevent integer overflows.

Réponse de Cybernetics : Partiellement. La plupart des valeurs numériques sont bornées (taille de page, montants, quantités), mais certains champs numériques, dont le numéro de page, n'ont pas encore de maximum.

​

1.4.3 · niveau 2 · Vérifier que la mémoire et les ressources allouées dynamiquement sont libérées, et que les références ou pointeurs vers la mémoire libérée sont supprimés ou mis à null afin d'empêcher les pointeurs pendants et les vulnérabilités de type use-after-free.

Verify that dynamically allocated memory and resources are released, and that references or pointers to freed memory are removed or set to null to prevent dangling pointers and use-after-free vulnerabilities.

Réponse de Cybernetics : Sans objet. La mémoire est gérée automatiquement par le moteur d'exécution.

​

1.5.1 · niveau 1 · Vérifier que l'application configure les analyseurs XML avec une configuration restrictive et que les fonctionnalités dangereuses telles que la résolution des entités externes sont désactivées afin d'empêcher les attaques XML eXternal Entity (XXE).

Verify that the application configures XML parsers to use a restrictive configuration and that unsafe features such as resolving external entities are disabled to prevent XML eXternal Entity (XXE) attacks.

Réponse de Cybernetics : Oui. Le XML reçu des services tiers est lu par un analyseur qui ne résout pas les entités externes.

​

1.5.2 · niveau 2 · Vérifier que la désérialisation de données non fiables impose un traitement sûr des entrées, par exemple en utilisant une liste d'autorisation de types d'objets ou en restreignant les types d'objets définis par le client, afin d'empêcher les attaques par désérialisation. Les mécanismes de désérialisation explicitement définis comme non sécurisés ne doivent pas être utilisés avec des entrées non fiables.

Verify that deserialization of untrusted data enforces safe input handling, such as using an allowlist of object types or restricting client-defined object types, to prevent deserialization attacks. Deserialization mechanisms that are explicitly defined as insecure must not be used with untrusted input.

Réponse de Cybernetics : Oui. Seul le JSON est désérialisé, et aucun mécanisme ne recrée des types d'objets choisis par le client.

2.1.1 · niveau 1 · Vérifier que la documentation de l'application définit des règles de validation des entrées décrivant comment contrôler la validité des éléments de données par rapport à une structure attendue. Il peut s'agir de formats de données courants tels que les numéros de carte bancaire, les adresses e-mail, les numéros de téléphone, ou d'un format de données interne.

Verify that the application's documentation defines input validation rules for how to check the validity of data items against an expected structure. This could be common data formats such as credit card numbers, email addresses, telephone numbers, or it could be an internal data format.

Réponse de Cybernetics : Partiellement. Les règles de validation de chaque entrée sont définies dans des schémas centralisés ; il n'existe pas encore de document dédié qui les décrit.

​

2.1.2 · niveau 2 · Vérifier que la documentation de l'application définit comment valider la cohérence logique et contextuelle d'éléments de données combinés, par exemple en vérifiant que la commune et le code postal correspondent.

Verify that the application's documentation defines how to validate the logical and contextual consistency of combined data items, such as checking that suburb and ZIP code match.

Réponse de Cybernetics : Partiellement. Les contrôles de cohérence entre champs sont définis dans les schémas de validation, mais pas encore décrits dans une documentation formelle.

​

2.1.3 · niveau 2 · Vérifier que les attentes en matière de limites et de validations de la logique métier sont documentées, à la fois par utilisateur et globalement à l'échelle de l'application.

Verify that expectations for business logic limits and validations are documented, including both per-user and globally across the application.

Réponse de Cybernetics : Partiellement. Les limites métier (quotas par offre, fréquences) sont définies à un seul endroit du code, mais ne sont pas encore décrites dans une documentation formelle.

​

2.2.1 · niveau 1 · Vérifier que les entrées sont validées afin d'appliquer les attentes métier ou fonctionnelles relatives à ces entrées. Cela doit reposer soit sur une validation positive par rapport à une liste d'autorisation de valeurs, de motifs et de plages, soit sur la comparaison de l'entrée à une structure attendue et à des limites logiques selon des règles prédéfinies. Pour le niveau L1, cela peut se concentrer sur les entrées utilisées pour prendre des décisions métier ou de sécurité spécifiques. Pour le niveau L2 et supérieur, cela doit s'appliquer à toutes les entrées.

Verify that input is validated to enforce business or functional expectations for that input. This should either use positive validation against an allow list of values, patterns, and ranges, or be based on comparing the input to an expected structure and logical limits according to predefined rules. For L1, this can focus on input which is used to make specific business or security decisions. For L2 and up, this should apply to all input.

Réponse de Cybernetics : Partiellement. Les entrées sont validées côté serveur (types, listes de valeurs, formats), mais certains champs n'ont pas encore de format ni de longueur maximale.

​

2.2.2 · niveau 1 · Vérifier que l'application est conçue pour appliquer la validation des entrées au niveau d'une couche de service de confiance. Bien que la validation côté client améliore l'ergonomie et doive être encouragée, elle ne doit pas être considérée comme un contrôle de sécurité.

Verify that the application is designed to enforce input validation at a trusted service layer. While client-side validation improves usability and should be encouraged, it must not be relied upon as a security control.

Réponse de Cybernetics : Oui. Toute validation qui porte une décision est faite côté serveur ; celle de l'interface n'est qu'une aide à la saisie.

​

2.2.3 · niveau 2 · Vérifier que l'application s'assure que les combinaisons d'éléments de données liés sont cohérentes selon les règles prédéfinies.

Verify that the application ensures that combinations of related data items are reasonable according to the pre-defined rules.

Réponse de Cybernetics : Partiellement. Plusieurs combinaisons de champs sont contrôlées (dates ordonnées, quantité affectée inférieure à la quantité achetée) ; l'appartenance à la bonne entreprise des objets référencés n'est pas toujours vérifiée.

​

2.3.1 · niveau 1 · Vérifier que l'application ne traite les flux de logique métier pour un même utilisateur que dans l'ordre séquentiel attendu des étapes et sans en sauter.

Verify that the application will only process business logic flows for the same user in the expected sequential step order and without skipping steps.

Réponse de Cybernetics : Oui. Les parcours sensibles (double authentification, réinitialisation du mot de passe) imposent l'ordre des étapes grâce à un défi côté serveur et à des jetons à usage unique.

​

2.3.2 · niveau 2 · Vérifier que les limites de la logique métier sont mises en œuvre conformément à la documentation de l'application afin d'éviter l'exploitation de failles de logique métier.

Verify that business logic limits are implemented per the application's documentation to avoid business logic flaws being exploited.

Réponse de Cybernetics : Partiellement. Les quotas de chaque offre sont appliqués dans les règles d'autorisation ; une limite de tentatives prévue sur l'enregistrement des secrets n'est pas encore activée, et certaines protections de l'offre restent à renforcer.

​

2.3.3 · niveau 2 · Vérifier que des transactions sont utilisées au niveau de la logique métier, de sorte qu'une opération de logique métier soit réussisse dans son intégralité, soit soit annulée pour revenir à l'état correct précédent.

Verify that transactions are being used at the business logic level such that either a business logic operation succeeds in its entirety or it is rolled back to the previous correct state.

Réponse de Cybernetics : Partiellement. La plupart des opérations métier à écritures multiples sont exécutées dans des transactions annulées entièrement en cas d'erreur ; quelques opérations d'administration ne le sont pas encore, et leur correction est planifiée.

​

2.3.4 · niveau 2 · Vérifier que des mécanismes de verrouillage au niveau de la logique métier sont utilisés pour garantir que des ressources en quantité limitée (telles que des sièges de théâtre ou des créneaux de livraison) ne peuvent pas être réservées deux fois en manipulant la logique de l'application.

Verify that business logic level locking mechanisms are used to ensure that limited quantity resources (such as theater seats or delivery slots) cannot be double-booked by manipulating the application's logic.

Réponse de Cybernetics : Partiellement. Des verrous protègent les sessions, les jetons et le chiffrement ; les contrôles de quotas ne sont pas encore protégés contre les requêtes simultanées.

​

2.4.1 · niveau 2 · Vérifier que des contrôles anti-automatisation sont en place pour se protéger contre les appels excessifs aux fonctions de l'application pouvant conduire à l'exfiltration de données, à la création de données parasites, à l'épuisement des quotas, au dépassement des limites de débit, à un déni de service ou à la surutilisation de ressources coûteuses.

Verify that anti-automation controls are in place to protect against excessive calls to application functions that could lead to data exfiltration, garbage-data creation, quota exhaustion, rate-limit breaches, denial-of-service, or overuse of costly resources.

Réponse de Cybernetics : Oui. Les routes ont une limitation de fréquence avec des profils adaptés à chaque type d'opération, complétée par des règles de limitation chez Cloudflare.

3.2.1 · niveau 1 · Vérifier que des contrôles de sécurité sont en place pour empêcher les navigateurs de rendre du contenu ou des fonctionnalités des réponses HTTP dans un contexte incorrect (par ex. lorsqu'une API, un fichier téléversé par un utilisateur ou une autre ressource est demandé directement). Les contrôles possibles incluent : ne pas servir le contenu à moins que les champs d'en-tête de requête HTTP (tels que Sec-Fetch-*) n'indiquent qu'il s'agit du bon contexte, utiliser la directive sandbox du champ d'en-tête Content-Security-Policy, ou utiliser le type de disposition attachment dans le champ d'en-tête Content-Disposition.

Verify that security controls are in place to prevent browsers from rendering content or functionality in HTTP responses in an incorrect context (e.g., when an API, a user-uploaded file or other resource is requested directly). Possible controls could include: not serving the content unless HTTP request header fields (such as Sec-Fetch-*) indicate it is the correct context, using the sandbox directive of the Content-Security-Policy header field or using the attachment disposition type in the Content-Disposition header field.

Réponse de Cybernetics : Oui. L'API ne renvoie que du JSON ou du texte avec un type de contenu explicite, une CSP qui interdit toute ressource, l'interdiction du « sniffing » et l'interdiction de l'intégration dans un cadre ; l'application ne sert aucun fichier déposé par un utilisateur.

​

3.2.2 · niveau 1 · Vérifier que le contenu destiné à être affiché en tant que texte, et non rendu en HTML, est traité à l'aide de fonctions de rendu sûres (telles que createTextNode ou textContent) afin d'empêcher l'exécution involontaire de contenu tel que du HTML ou du JavaScript.

Verify that content intended to be displayed as text, rather than rendered as HTML, is handled using safe rendering functions (such as createTextNode or textContent) to prevent unintended execution of content such as HTML or JavaScript.

Réponse de Cybernetics : Oui. L'interface affiche les données par interpolation échappée du framework ; aucun rendu HTML brut n'est utilisé sur des données d'utilisateur.

​

3.3.1 · niveau 1 · Vérifier que les cookies ont l'attribut 'Secure' défini, et que si le préfixe '__Host-' n'est pas utilisé pour le nom du cookie, le préfixe '__Secure-' doit être utilisé pour le nom du cookie.

Verify that cookies have the 'Secure' attribute set, and if the '__Host-' prefix is not used for the cookie name, the '__Secure-' prefix must be used for the cookie name.

Réponse de Cybernetics : Partiellement. Les cookies d'authentification portent l'attribut Secure en production ; le préfixe __Host- n'est utilisé que sur la copie côté interface, pas encore sur le cookie lu par l'API, et quelques cookies de préférence n'ont pas d'attributs explicites.

​

3.3.2 · niveau 2 · Vérifier que la valeur de l'attribut 'SameSite' de chaque cookie est définie en fonction de la finalité du cookie, afin de limiter l'exposition aux attaques de détournement d'interface utilisateur et aux attaques de forgerie de requête basées sur le navigateur, communément appelées cross-site request forgery (CSRF).

Verify that each cookie's 'SameSite' attribute value is set according to the purpose of the cookie, to limit exposure to user interface redress attacks and browser-based request forgery attacks, commonly known as cross-site request forgery (CSRF).

Réponse de Cybernetics : Oui. Les cookies de session et de double authentification sont en SameSite=Strict ; les cookies temporaires de connexion Google ou Microsoft et les cookies de préférence d'affichage, sans donnée sensible, sont en Lax.

​

3.3.3 · niveau 2 · Vérifier que les cookies portent le préfixe '__Host-' dans leur nom, sauf s'ils sont explicitement conçus pour être partagés avec d'autres hôtes.

Verify that cookies have the '__Host-' prefix for the cookie name unless they are explicitly designed to be shared with other hosts.

Réponse de Cybernetics : Partiellement. Les cookies sont limités à leur hôte (sans attribut Domain, chemin /), mais le préfixe __Host- n'est utilisé que sur une copie côté interface, que l'API ne lit pas encore.

​

3.3.4 · niveau 2 · Vérifier que si la valeur d'un cookie n'est pas destinée à être accessible aux scripts côté client (par exemple un jeton de session), le cookie doit avoir l'attribut 'HttpOnly' défini et la même valeur (par ex. le jeton de session) ne doit être transmise au client que via le champ d'en-tête 'Set-Cookie'.

Verify that if the value of a cookie is not meant to be accessible to client-side scripts (such as a session token), the cookie must have the 'HttpOnly' attribute set and the same value (e. g. session token) must only be transferred to the client via the 'Set-Cookie' header field.

Réponse de Cybernetics : Partiellement. Le cookie de session est HttpOnly, mais le jeton transite aussi une fois dans le corps de la réponse de connexion.

​

3.4.1 · niveau 1 · Vérifier qu'un champ d'en-tête Strict-Transport-Security est inclus dans toutes les réponses afin d'appliquer une politique HTTP Strict Transport Security (HSTS). Une durée maximale d'au moins 1 an doit être définie, et pour le niveau L2 et supérieur, la politique doit également s'appliquer à tous les sous-domaines.

Verify that a Strict-Transport-Security header field is included on all responses to enforce an HTTP Strict Transport Security (HSTS) policy. A maximum age of at least 1 year must be defined, and for L2 and up, the policy must apply to all subdomains as well.

Réponse de Cybernetics : Oui. HSTS est envoyé sur toutes les réponses (un an, sous-domaines inclus, preload), et le domaine est inscrit dans la liste de préchargement des navigateurs.

​

3.4.2 · niveau 1 · Vérifier que le champ d'en-tête Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin est une valeur fixe définie par l'application, ou que si la valeur du champ d'en-tête de requête HTTP Origin est utilisée, elle est validée par rapport à une liste d'autorisation d'origines de confiance. Lorsque 'Access-Control-Allow-Origin: *' doit être utilisé, vérifier que la réponse ne contient aucune information sensible.

Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin header field is a fixed value by the application, or if the Origin HTTP request header field value is used, it is validated against an allowlist of trusted origins. When 'Access-Control-Allow-Origin: *' needs to be used, verify that the response does not include any sensitive information.

Réponse de Cybernetics : Oui. L'origine est comparée à une liste d'autorisation stricte avant d'être renvoyée dans l'en-tête CORS, avec les identifiants autorisés uniquement pour ces origines.

​

3.4.3 · niveau 2 · Vérifier que les réponses HTTP incluent un champ d'en-tête de réponse Content-Security-Policy définissant des directives garantissant que le navigateur ne charge et n'exécute que du contenu ou des ressources de confiance, afin de limiter l'exécution de JavaScript malveillant. Au minimum, une politique globale doit être utilisée, incluant les directives object-src 'none' et base-uri 'none', et définissant soit une liste d'autorisation, soit l'utilisation de nonces ou de hachages. Pour une application de niveau L3, une politique par réponse avec nonces ou hachages doit être définie.

Verify that HTTP responses include a Content-Security-Policy response header field which defines directives to ensure the browser only loads and executes trusted content or resources, in order to limit execution of malicious JavaScript. As a minimum, a global policy must be used which includes the directives object-src 'none' and base-uri 'none' and defines either an allowlist or uses nonces or hashes. For an L3 application, a per-response policy with nonces or hashes must be defined.

Réponse de Cybernetics : Partiellement. Une politique de sécurité du contenu stricte est appliquée (nonce et strict-dynamic sur l'application, empreintes des scripts sur le site public, object-src 'none', default-src 'none' sur l'API) ; la directive base-uri reste à durcir.

​

3.4.4 · niveau 2 · Vérifier que toutes les réponses HTTP contiennent un champ d'en-tête 'X-Content-Type-Options: nosniff'. Cela indique aux navigateurs de ne pas utiliser la détection de contenu ni la déduction du type MIME pour la réponse concernée, et d'exiger que la valeur du champ d'en-tête Content-Type de la réponse corresponde à la ressource de destination. Par exemple, la réponse à une requête de feuille de style n'est acceptée que si le Content-Type de la réponse est 'text/css'. Cela active également l'utilisation par le navigateur de la fonctionnalité Cross-Origin Read Blocking (CORB).

Verify that all HTTP responses contain an 'X-Content-Type-Options: nosniff' header field. This instructs browsers not to use content sniffing and MIME type guessing for the given response, and to require the response's Content-Type header field value to match the destination resource. For example, the response to a request for a style is only accepted if the response's Content-Type is 'text/css'. This also enables the use of the Cross-Origin Read Blocking (CORB) functionality by the browser.

Réponse de Cybernetics : Oui. L'en-tête X-Content-Type-Options: nosniff est envoyé sur toutes les réponses.

​

3.4.5 · niveau 2 · Vérifier que l'application définit une politique de référent afin d'empêcher la fuite de données techniquement sensibles vers des services tiers via le champ d'en-tête de requête HTTP 'Referer'. Cela peut se faire à l'aide du champ d'en-tête de réponse HTTP Referrer-Policy ou via des attributs d'éléments HTML. Les données sensibles peuvent inclure le chemin et les paramètres de requête de l'URL, ainsi que, pour les applications internes non publiques, le nom d'hôte.

Verify that the application sets a referrer policy to prevent leakage of technically sensitive data to third-party services via the 'Referer' HTTP request header field. This can be done using the Referrer-Policy HTTP response header field or via HTML element attributes. Sensitive data could include path and query data in the URL, and for internal non-public applications also the hostname.

Réponse de Cybernetics : Oui. Une politique de référent restrictive (strict-origin-when-cross-origin, ou plus stricte) est appliquée sur toutes les applications.

​

3.4.6 · niveau 2 · Vérifier que l'application web utilise la directive frame-ancestors du champ d'en-tête Content-Security-Policy pour chaque réponse HTTP afin de garantir qu'elle ne peut pas être intégrée par défaut et que l'intégration de ressources spécifiques n'est autorisée que lorsque c'est nécessaire. Noter que le champ d'en-tête X-Frame-Options, bien que pris en charge par les navigateurs, est obsolète et ne doit pas être considéré comme fiable.

Verify that the web application uses the frame-ancestors directive of the Content-Security-Policy header field for every HTTP response to ensure that it cannot be embedded by default and that embedding of specific resources is allowed only when necessary. Note that the X-Frame-Options header field, although supported by browsers, is obsolete and may not be relied upon.

Réponse de Cybernetics : Oui. frame-ancestors 'none' est défini pour l'application, le site public et l'API, doublé de X-Frame-Options: DENY.

​

3.5.1 · niveau 1 · Vérifier que, si l'application ne s'appuie pas sur le mécanisme de pré-vérification (preflight) CORS pour empêcher les requêtes cross-origin non autorisées d'utiliser des fonctionnalités sensibles, ces requêtes sont validées afin de s'assurer qu'elles proviennent de l'application elle-même. Cela peut se faire en utilisant et en validant des jetons anti-forgerie ou en exigeant des champs d'en-tête HTTP supplémentaires qui ne font pas partie des champs d'en-tête de requête CORS-safelisted. L'objectif est de se défendre contre les attaques de forgerie de requête basées sur le navigateur, communément appelées cross-site request forgery (CSRF).

Verify that, if the application does not rely on the CORS preflight mechanism to prevent disallowed cross-origin requests to use sensitive functionality, these requests are validated to ensure they originate from the application itself. This may be done by using and validating anti-forgery tokens or requiring extra HTTP header fields that are not CORS-safelisted request-header fields. This is to defend against browser-based request forgery attacks, commonly known as cross-site request forgery (CSRF).

Réponse de Cybernetics : Partiellement. La protection contre les requêtes intersites repose sur des cookies SameSite=Strict et une liste d'autorisation CORS ; l'API ne vérifie pas encore l'origine des requêtes qui modifient des données et n'utilise pas de jeton anti-CSRF.

​

3.5.2 · niveau 1 · Vérifier que, si l'application s'appuie sur le mécanisme de pré-vérification (preflight) CORS pour empêcher l'utilisation cross-origin non autorisée de fonctionnalités sensibles, il n'est pas possible d'appeler la fonctionnalité avec une requête qui ne déclenche pas de requête de pré-vérification CORS. Cela peut nécessiter de contrôler les valeurs des champs d'en-tête de requête 'Origin' et 'Content-Type', ou d'utiliser un champ d'en-tête supplémentaire qui n'est pas CORS-safelisted.

Verify that, if the application relies on the CORS preflight mechanism to prevent disallowed cross-origin use of sensitive functionality, it is not possible to call the functionality with a request which does not trigger a CORS-preflight request. This may require checking the values of the 'Origin' and 'Content-Type' request header fields or using an extra header field that is not a CORS-safelisted header-field.

Réponse de Cybernetics : Partiellement. L'API accepte encore le format formulaire, qui ne déclenche pas de vérification préalable CORS ; la protection repose alors sur SameSite=Strict.

​

3.5.3 · niveau 1 · Vérifier que les requêtes HTTP vers des fonctionnalités sensibles utilisent des méthodes HTTP appropriées telles que POST, PUT, PATCH ou DELETE, et non des méthodes définies comme « sûres » par la spécification HTTP telles que HEAD, OPTIONS ou GET. Alternativement, une validation stricte des champs d'en-tête de requête Sec-Fetch-* peut être utilisée pour s'assurer que la requête ne provient pas d'un appel cross-origin inapproprié, d'une requête de navigation ou d'un chargement de ressource (tel qu'une source d'image) lorsque cela n'est pas attendu.

Verify that HTTP requests to sensitive functionality use appropriate HTTP methods such as POST, PUT, PATCH, or DELETE, and not methods defined by the HTTP specification as "safe" such as HEAD, OPTIONS, or GET. Alternatively, strict validation of the Sec-Fetch-* request header fields can be used to ensure that the request did not originate from an inappropriate cross-origin call, a navigation request, or a resource load (such as an image source) where this is not expected.

Réponse de Cybernetics : Partiellement. Les opérations qui modifient des données utilisent POST, PUT, PATCH ou DELETE, à une exception près (déconnexion), dont le passage en POST est planifié.

​

3.5.4 · niveau 2 · Vérifier que les applications distinctes sont hébergées sur des noms d'hôte différents afin de tirer parti des restrictions offertes par la politique de même origine (same-origin policy), notamment la manière dont les documents ou scripts chargés par une origine peuvent interagir avec les ressources d'une autre origine, ainsi que les restrictions sur les cookies basées sur le nom d'hôte.

Verify that separate applications are hosted on different hostnames to leverage the restrictions provided by same-origin policy, including how documents or scripts loaded by one origin can interact with resources from another origin and hostname-based restrictions on cookies.

Réponse de Cybernetics : Oui. Le site public, l'application et l'API sont servis sur des noms d'hôte distincts, avec des cookies limités à leur hôte.

​

3.5.5 · niveau 2 · Vérifier que les messages reçus par l'interface postMessage sont rejetés si l'origine du message n'est pas de confiance, ou si la syntaxe du message est invalide.

Verify that messages received by the postMessage interface are discarded if the origin of the message is not trusted, or if the syntax of the message is invalid.

Réponse de Cybernetics : Oui. Aucun récepteur de messages inter-fenêtres n'existe ; le seul canal de messagerie est limité à la même origine et ignore tout message inattendu.

​

3.7.1 · niveau 2 · Vérifier que l'application n'utilise que des technologies côté client encore prises en charge et considérées comme sécurisées. Parmi les technologies ne répondant pas à cette exigence figurent les plugins NSAPI, Flash, Shockwave, ActiveX, Silverlight, NACL ou les applets Java côté client.

Verify that the application only uses client-side technologies which are still supported and considered secure. Examples of technologies which do not meet this requirement include NSAPI plugins, Flash, Shockwave, ActiveX, Silverlight, NACL, or client-side Java applets.

Réponse de Cybernetics : Oui. Aucune technologie cliente obsolète n'est utilisée, et la CSP interdit les objets intégrés.

​

3.7.2 · niveau 2 · Vérifier que l'application ne redirige automatiquement l'utilisateur vers un autre nom d'hôte ou domaine (non contrôlé par l'application) que si la destination figure dans une liste d'autorisation.

Verify that the application will only automatically redirect the user to a different hostname or domain (which is not controlled by the application) where the destination appears on an allowlist.

Réponse de Cybernetics : Oui. Les redirections vers des domaines externes ne concernent que des URL générées côté serveur par les fournisseurs d'identité et de paiement ; aucune destination n'est reprise d'un paramètre fourni par l'utilisateur.

4.1.1 · niveau 1 · Vérifier que chaque réponse HTTP dotée d'un corps de message contient un champ d'en-tête Content-Type correspondant au contenu réel de la réponse, y compris le paramètre charset spécifiant un encodage de caractères sûr (par ex. UTF-8, ISO-8859-1) conformément aux types de médias IANA, tels que "text/", "/+xml" et "/xml".

Verify that every HTTP response with a message body contains a Content-Type header field that matches the actual content of the response, including the charset parameter to specify safe character encoding (e.g., UTF-8, ISO-8859-1) according to IANA Media Types, such as "text/", "/+xml" and "/xml".

Réponse de Cybernetics : Oui. Chaque réponse porte un type de contenu adapté, avec le jeu de caractères UTF-8.

​

4.1.2 · niveau 2 · Vérifier que seuls les points de terminaison destinés aux utilisateurs (prévus pour un accès manuel via un navigateur web) redirigent automatiquement de HTTP vers HTTPS, tandis que les autres services ou points de terminaison ne mettent pas en œuvre de redirections transparentes. L'objectif est d'éviter une situation où un client enverrait par erreur des requêtes HTTP non chiffrées sans que la fuite de données sensibles ne soit détectée, du fait de la redirection automatique des requêtes vers HTTPS.

Verify that only user-facing endpoints (intended for manual web-browser access) automatically redirect from HTTP to HTTPS, while other services or endpoints do not implement transparent redirects. This is to avoid a situation where a client is erroneously sending unencrypted HTTP requests, but since the requests are being automatically redirected to HTTPS, the leakage of sensitive data goes undiscovered.

Réponse de Cybernetics : Partiellement. La redirection de HTTP vers HTTPS est activée pour tous les domaines, y compris l'API, au lieu d'y refuser le HTTP ; le préchargement HSTS protège les navigateurs, mais pas les autres clients.

​

4.1.3 · niveau 2 · Vérifier que tout champ d'en-tête HTTP utilisé par l'application et défini par une couche intermédiaire, telle qu'un répartiteur de charge, un proxy web ou un service backend-for-frontend, ne peut pas être remplacé par l'utilisateur final. Des exemples d'en-têtes incluent X-Real-IP, X-Forwarded-* ou X-User-ID.

Verify that any HTTP header field used by the application and set by an intermediary layer, such as a load balancer, a web proxy, or a backend-for-frontend service, cannot be overridden by the end-user. Example headers might include X-Real-IP, X-Forwarded-*, or X-User-ID.

Réponse de Cybernetics : Oui. Les en-têtes de transfert ne sont acceptés que depuis les plages du fournisseur de périphérie et du réseau interne.

​

4.2.1 · niveau 2 · Vérifier que tous les composants de l'application (y compris les répartiteurs de charge, les pare-feu et les serveurs d'application) déterminent les limites des messages HTTP entrants à l'aide du mécanisme approprié à la version HTTP, afin d'empêcher le HTTP request smuggling. En HTTP/1.x, si un champ d'en-tête Transfer-Encoding est présent, l'en-tête Content-Length doit être ignoré conformément à la RFC 2616. En HTTP/2 ou HTTP/3, si un champ d'en-tête Content-Length est présent, le récepteur doit s'assurer qu'il est cohérent avec la longueur des trames DATA.

Verify that all application components (including load balancers, firewalls, and application servers) determine boundaries of incoming HTTP messages using the appropriate mechanism for the HTTP version to prevent HTTP request smuggling. In HTTP/1.x, if a Transfer-Encoding header field is present, the Content-Length header must be ignored per RFC 2616. When using HTTP/2 or HTTP/3, if a Content-Length header field is present, the receiver must ensure that it is consistent with the length of the DATA frames.

Réponse de Cybernetics : Partiellement. La chaîne s'appuie sur des analyseurs HTTP standard à jour, sans mode d'analyse permissif ; aucun test de désynchronisation n'a encore été réalisé.

​

4.3.1 · niveau 2 · Vérifier qu'une liste d'autorisation de requêtes, une limitation de profondeur, une limitation de quantité ou une analyse du coût des requêtes est utilisée pour empêcher un déni de service (DoS) sur GraphQL ou sur les expressions de la couche de données résultant de requêtes coûteuses et imbriquées.

Verify that a query allowlist, depth limiting, amount limiting, or query cost analysis is used to prevent GraphQL or data layer expression Denial of Service (DoS) as a result of expensive, nested queries.

Réponse de Cybernetics : Sans objet. L'application n'expose pas de GraphQL : l'API est en REST avec des routes explicites.

​

4.3.2 · niveau 2 · Vérifier que les requêtes d'introspection GraphQL sont désactivées dans l'environnement de production, sauf si l'API GraphQL est destinée à être utilisée par des tiers.

Verify that GraphQL introspection queries are disabled in the production environment unless the GraphQL API is meant to be used by other parties.

Réponse de Cybernetics : Sans objet. Pas de GraphQL, donc pas d'introspection.

​

4.4.1 · niveau 1 · Vérifier que WebSocket sur TLS (WSS) est utilisé pour toutes les connexions WebSocket.

Verify that WebSocket over TLS (WSS) is used for all WebSocket connections.

Réponse de Cybernetics : Sans objet. L'application n'utilise pas de WebSocket propre ; seul le module de support tiers en utilise, uniquement chiffré (wss).

​

4.4.2 · niveau 2 · Vérifier que, lors de la poignée de main HTTP initiale du WebSocket, le champ d'en-tête Origin est contrôlé par rapport à une liste d'origines autorisées pour l'application.

Verify that, during the initial HTTP WebSocket handshake, the Origin header field is checked against a list of origins allowed for the application.

Réponse de Cybernetics : Sans objet. Pas de WebSocket applicatif.

​

4.4.3 · niveau 2 · Vérifier que, si la gestion de session standard de l'application ne peut pas être utilisée, des jetons dédiés sont utilisés à cette fin, conformes aux exigences de sécurité pertinentes en matière de gestion de session.

Verify that, if the application's standard session management cannot be used, dedicated tokens are being used for this, which comply with the relevant Session Management security requirements.

Réponse de Cybernetics : Sans objet. Pas de WebSocket applicatif.

​

4.4.4 · niveau 2 · Vérifier que les jetons dédiés de gestion de session WebSocket sont initialement obtenus ou validés via la session HTTPS préalablement authentifiée lors de la transition d'une session HTTPS existante vers un canal WebSocket.

Verify that dedicated WebSocket session management tokens are initially obtained or validated through the previously authenticated HTTPS session when transitioning an existing HTTPS session to a WebSocket channel.

Réponse de Cybernetics : Sans objet. Pas de WebSocket applicatif.

5.1.1 · niveau 2 · Vérifier que la documentation définit les types de fichiers autorisés, les extensions de fichiers attendues et la taille maximale (y compris la taille décompressée) pour chaque fonctionnalité de téléversement. S'assurer en outre que la documentation précise comment les fichiers sont rendus sûrs pour le téléchargement et le traitement par les utilisateurs finaux, par exemple le comportement de l'application lorsqu'un fichier malveillant est détecté.

Verify that the documentation defines the permitted file types, expected file extensions, and maximum size (including unpacked size) for each upload feature. Additionally, ensure that the documentation specifies how files are made safe for end-users to download and process, such as how the application behaves when a malicious file is detected.

Réponse de Cybernetics : Sans objet. Il n'existe pas de fonction de dépôt de fichier : l'analyse multipart est désactivée et les preuves de conformité sont des liens.

​

5.2.1 · niveau 1 · Vérifier que l'application n'accepte que des fichiers d'une taille qu'elle peut traiter sans provoquer de perte de performance ni d'attaque par déni de service.

Verify that the application will only accept files of a size which it can process without causing a loss of performance or a denial of service attack.

Réponse de Cybernetics : Sans objet. L'application n'accepte aucun fichier, et la taille des requêtes est limitée.

​

5.2.2 · niveau 1 · Vérifier que, lorsque l'application accepte un fichier, seul ou au sein d'une archive telle qu'un fichier zip, elle contrôle que l'extension du fichier correspond à une extension attendue et valide que le contenu correspond au type représenté par l'extension. Cela inclut, sans s'y limiter, le contrôle des « octets magiques » initiaux, la réécriture des images et l'utilisation de bibliothèques spécialisées pour la validation du contenu des fichiers. Pour le niveau L1, cela peut se concentrer uniquement sur les fichiers utilisés pour prendre des décisions métier ou de sécurité spécifiques. Pour le niveau L2 et supérieur, cela doit s'appliquer à tous les fichiers acceptés.

Verify that when the application accepts a file, either on its own or within an archive such as a zip file, it checks if the file extension matches an expected file extension and validates that the contents correspond to the type represented by the extension. This includes, but is not limited to, checking the initial 'magic bytes', performing image re-writing, and using specialized libraries for file content validation. For L1, this can focus just on files which are used to make specific business or security decisions. For L2 and up, this must apply to all files being accepted.

Réponse de Cybernetics : Sans objet. L'application n'accepte aucun fichier ; les images de profil sont des URL.

​

5.2.3 · niveau 2 · Vérifier que l'application contrôle les fichiers compressés (par ex. zip, gz, docx, odt) par rapport à une taille décompressée maximale autorisée et à un nombre maximal de fichiers avant de les décompresser.

Verify that the application checks compressed files (e.g., zip, gz, docx, odt) against maximum allowed uncompressed size and against maximum number of files before uncompressing the file.

Réponse de Cybernetics : Sans objet. L'application n'accepte ni ne décompresse aucune archive.

​

5.3.1 · niveau 1 · Vérifier que les fichiers téléversés ou générés à partir d'entrées non fiables et stockés dans un dossier public ne sont pas exécutés comme du code de programme côté serveur lorsqu'ils sont accédés directement par une requête HTTP.

Verify that files uploaded or generated by untrusted input and stored in a public folder, are not executed as server-side program code when accessed directly with an HTTP request.

Réponse de Cybernetics : Sans objet. Aucun fichier issu d'une entrée non fiable n'est stocké dans un dossier public ; les exports sont générés dans le navigateur de l'utilisateur.

​

5.3.2 · niveau 1 · Vérifier que, lorsque l'application construit des chemins de fichiers pour des opérations sur les fichiers, elle utilise des données générées en interne ou de confiance plutôt que des noms de fichiers soumis par l'utilisateur, ou que, si des noms de fichiers ou des métadonnées de fichiers soumis par l'utilisateur doivent être utilisés, une validation et un assainissement stricts sont appliqués. L'objectif est de se protéger contre les attaques de traversée de répertoires, d'inclusion de fichiers locaux ou distants (LFI, RFI) et de server-side request forgery (SSRF).

Verify that when the application creates file paths for file operations, instead of user-submitted filenames, it uses internally generated or trusted data, or if user-submitted filenames or file metadata must be used, strict validation and sanitization must be applied. This is to protect against path traversal, local or remote file inclusion (LFI, RFI), and server-side request forgery (SSRF) attacks.

Réponse de Cybernetics : Partiellement. Les chemins de fichiers internes sont construits à partir d'identifiants internes ; la génération de liens de téléchargement signés pour l'agent n'est pas encore limitée à une liste fermée de fichiers.

​

5.4.1 · niveau 2 · Vérifier que l'application valide ou ignore les noms de fichiers soumis par l'utilisateur, y compris dans un paramètre JSON, JSONP ou d'URL, et spécifie un nom de fichier dans le champ d'en-tête Content-Disposition de la réponse.

Verify that the application validates or ignores user-submitted filenames, including in a JSON, JSONP, or URL parameter and specifies a filename in the Content-Disposition header field in the response.

Réponse de Cybernetics : Oui. Les noms des fichiers exportés sont générés par l'application, jamais à partir d'un nom fourni par l'utilisateur.

​

5.4.2 · niveau 2 · Vérifier que les noms de fichiers servis (par ex. dans les champs d'en-tête de réponse HTTP ou les pièces jointes d'e-mails) sont encodés ou assainis (par ex. conformément à la RFC 6266) afin de préserver la structure du document et d'empêcher les attaques par injection.

Verify that file names served (e.g., in HTTP response header fields or email attachments) are encoded or sanitized (e.g., following RFC 6266) to preserve document structure and prevent injection attacks.

Réponse de Cybernetics : Oui. Les noms de fichiers produits sont réduits à des caractères sûrs, et les exports tabulaires neutralisent les formules.

​

5.4.3 · niveau 2 · Vérifier que les fichiers obtenus de sources non fiables sont analysés par des scanners antivirus afin d'empêcher la diffusion de contenu malveillant connu.

Verify that files obtained from untrusted sources are scanned by antivirus scanners to prevent serving of known malicious content.

Réponse de Cybernetics : Sans objet. L'application ne reçoit ni ne redistribue de fichiers de sources non fiables ; les seuls binaires distribués sont produits par Cybernetics.

6.1.1 · niveau 1 · Vérifier que la documentation de l'application définit comment des contrôles tels que la limitation de débit, l'anti-automatisation et la réponse adaptative sont utilisés pour se défendre contre des attaques telles que le credential stuffing et la force brute sur les mots de passe. La documentation doit indiquer clairement comment ces contrôles sont configurés et comment ils empêchent le verrouillage malveillant de comptes.

Verify that application documentation defines how controls such as rate limiting, anti-automation, and adaptive response, are used to defend against attacks such as credential stuffing and password brute force. The documentation must make clear how these controls are configured and prevent malicious account lockout.

Réponse de Cybernetics : Partiellement. La limitation de débit par adresse IP, par e-mail et par défi de double authentification, ainsi que le verrouillage temporaire, sont en place ; leur configuration et la prévention des verrouillages malveillants ne sont pas encore décrites dans un document de sécurité.

​

6.1.2 · niveau 2 · Vérifier qu'une liste de mots spécifiques au contexte est documentée afin d'empêcher leur utilisation dans les mots de passe. Cette liste peut inclure des permutations de noms d'organisation, de noms de produits, d'identifiants de systèmes, de noms de code de projets, de noms de services ou de fonctions, et autres éléments similaires.

Verify that a list of context-specific words is documented in order to prevent their use in passwords. The list could include permutations of organization names, product names, system identifiers, project codenames, department or role names, and similar.

Réponse de Cybernetics : Non. Il n'existe pas encore de liste documentée de mots propres au contexte (nom de l'entreprise, du produit…) à interdire dans les mots de passe.

​

6.1.3 · niveau 2 · Vérifier que, si l'application comporte plusieurs parcours d'authentification, ceux-ci sont tous documentés avec les contrôles de sécurité et le niveau de robustesse d'authentification qui doivent être appliqués de manière cohérente sur l'ensemble de ces parcours.

Verify that, if the application includes multiple authentication pathways, these are all documented together with the security controls and authentication strength which must be consistently enforced across them.

Réponse de Cybernetics : Partiellement. Les voies d'authentification (mot de passe, Google, Microsoft, passkey, agents) sont définies dans le code, mais pas encore présentées dans un document unique avec leur niveau de garantie.

​

6.2.1 · niveau 1 · Vérifier que les mots de passe définis par les utilisateurs comportent au moins 8 caractères, un minimum de 15 caractères étant fortement recommandé.

Verify that user set passwords are at least 8 characters in length although a minimum of 15 characters is strongly recommended.

Réponse de Cybernetics : Oui. Les mots de passe font au moins 16 caractères.

​

6.2.2 · niveau 1 · Vérifier que les utilisateurs peuvent modifier leur mot de passe.

Verify that users can change their password.

Réponse de Cybernetics : Oui. L'utilisateur peut changer son mot de passe depuis son profil.

​

6.2.3 · niveau 1 · Vérifier que la fonctionnalité de changement de mot de passe exige le mot de passe actuel et le nouveau mot de passe de l'utilisateur.

Verify that password change functionality requires the user's current and new password.

Réponse de Cybernetics : Partiellement. Le changement de mot de passe exige une réauthentification récente, mais pas encore la saisie du mot de passe actuel, et un autre chemin de définition du mot de passe ne l'exige pas ; leur correction est planifiée.

​

6.2.4 · niveau 1 · Vérifier que les mots de passe soumis lors de l'inscription ou du changement de mot de passe sont contrôlés par rapport à un ensemble disponible d'au moins les 3000 mots de passe les plus courants correspondant à la politique de mots de passe de l'application, par ex. la longueur minimale.

Verify that passwords submitted during account registration or password change are checked against an available set of, at least, the top 3000 passwords which match the application's password policy, e.g. minimum length.

Réponse de Cybernetics : Partiellement. Les mots de passe sont comparés à la base Have I Been Pwned, qui contient les mots de passe les plus courants ; il n'existe pas encore de liste locale de secours si ce service est indisponible.

​

6.2.5 · niveau 1 · Vérifier que des mots de passe de toute composition peuvent être utilisés, sans règles limitant le type de caractères autorisés. Il ne doit y avoir aucune exigence de nombre minimal de majuscules, de minuscules, de chiffres ou de caractères spéciaux.

Verify that passwords of any composition can be used, without rules limiting the type of characters permitted. There must be no requirement for a minimum number of upper or lower case characters, numbers, or special characters.

Réponse de Cybernetics : Oui. Aucune règle de composition n'est imposée et tous les caractères sont acceptés.

​

6.2.6 · niveau 1 · Vérifier que les champs de saisie de mot de passe utilisent type=password pour masquer la saisie. Les applications peuvent permettre à l'utilisateur d'afficher temporairement l'intégralité du mot de passe masqué, ou le dernier caractère saisi du mot de passe.

Verify that password input fields use type=password to mask the entry. Applications may allow the user to temporarily view the entire masked password, or the last typed character of the password.

Réponse de Cybernetics : Oui. Les champs de mot de passe sont masqués, avec un bouton pour afficher temporairement la saisie.

​

6.2.7 · niveau 1 · Vérifier que la fonctionnalité « coller », les assistants de mots de passe des navigateurs et les gestionnaires de mots de passe externes sont autorisés.

Verify that "paste" functionality, browser password helpers, and external password managers are permitted.

Réponse de Cybernetics : Oui. Le collage et les gestionnaires de mots de passe sont autorisés.

​

6.2.8 · niveau 1 · Vérifier que l'application vérifie le mot de passe de l'utilisateur exactement tel qu'il a été reçu de l'utilisateur, sans aucune modification telle qu'une troncature ou une transformation de la casse.

Verify that the application verifies the user's password exactly as received from the user, without any modifications such as truncation or case transformation.

Réponse de Cybernetics : Oui. Le mot de passe est vérifié exactement tel qu'il est saisi, sans troncature ni changement de casse.

​

6.2.9 · niveau 2 · Vérifier que des mots de passe d'au moins 64 caractères sont autorisés.

Verify that passwords of at least 64 characters are permitted.

Réponse de Cybernetics : Oui. Les mots de passe peuvent aller jusqu'à 128 caractères.

​

6.2.10 · niveau 2 · Vérifier que le mot de passe d'un utilisateur reste valide jusqu'à ce qu'il soit découvert comme compromis ou que l'utilisateur le renouvelle. L'application ne doit pas exiger de rotation périodique des identifiants.

Verify that a user's password stays valid until it is discovered to be compromised or the user rotates it. The application must not require periodic credential rotation.

Réponse de Cybernetics : Oui. Aucun renouvellement périodique n'est imposé : le mot de passe reste valide jusqu'à ce que l'utilisateur le change ou qu'une compromission soit suspectée.

​

6.2.11 · niveau 2 · Vérifier que la liste documentée de mots spécifiques au contexte est utilisée pour empêcher la création de mots de passe faciles à deviner.

Verify that the documented list of context specific words is used to prevent easy to guess passwords being created.

Réponse de Cybernetics : Non. Aucune liste de mots propres au contexte n'est encore appliquée lors de la création d'un mot de passe.

​

6.2.12 · niveau 2 · Vérifier que les mots de passe soumis lors de l'inscription ou du changement de mot de passe sont contrôlés par rapport à un ensemble de mots de passe compromis.

Verify that passwords submitted during account registration or password changes are checked against a set of breached passwords.

Réponse de Cybernetics : Partiellement. Les mots de passe sont vérifiés contre les fuites connues sans transmettre le mot de passe (k-anonymat) ; si le service est indisponible, la vérification n'est pas bloquante.

​

6.3.1 · niveau 1 · Vérifier que les contrôles visant à empêcher des attaques telles que le credential stuffing et la force brute sur les mots de passe sont mis en œuvre conformément à la documentation de sécurité de l'application.

Verify that controls to prevent attacks such as credential stuffing and password brute force are implemented according to the application's security documentation.

Réponse de Cybernetics : Oui. Limitation de débit par adresse IP, par e-mail et par défi, verrouillage temporaire après des échecs répétés et message d'erreur générique.

​

6.3.2 · niveau 1 · Vérifier que les comptes utilisateur par défaut (par ex. « root », « admin » ou « sa ») ne sont pas présents dans l'application ou sont désactivés.

Verify that default user accounts (e.g., "root", "admin", or "sa") are not present in the application or are disabled.

Réponse de Cybernetics : Oui. Aucun compte par défaut n'existe ; les comptes initiaux sont créés à partir de secrets propres à chaque environnement.

​

6.3.3 · niveau 2 · Vérifier qu'un mécanisme d'authentification multifacteur ou une combinaison de mécanismes d'authentification à facteur unique doit être utilisé pour accéder à l'application. Pour le niveau L3, l'un des facteurs doit être un mécanisme d'authentification matériel offrant une résistance à la compromission et à l'usurpation face aux attaques par hameçonnage, tout en vérifiant l'intention de s'authentifier par une action initiée par l'utilisateur (telle qu'un appui sur le bouton d'une clé matérielle FIDO ou d'un téléphone mobile). Tout assouplissement des considérations de cette exigence requiert une justification entièrement documentée et un ensemble complet de contrôles compensatoires.

Verify that either a multi-factor authentication mechanism or a combination of single-factor authentication mechanisms, must be used in order to access the application. For L3, one of the factors must be a hardware-based authentication mechanism which provides compromise and impersonation resistance against phishing attacks while verifying the intent to authenticate by requiring a user-initiated action (such as a button press on a FIDO hardware key or a mobile phone). Relaxing any of the considerations in this requirement requires a fully documented rationale and a comprehensive set of mitigating controls.

Réponse de Cybernetics : Partiellement. La double authentification est obligatoire (application TOTP, code par e-mail, ou passkey avec vérification de l'utilisateur) ; elle peut encore être désactivée par un administrateur pour les comptes Admin Support, et la suppression de cette exception est planifiée.

​

6.3.4 · niveau 2 · Vérifier que, si l'application comporte plusieurs parcours d'authentification, il n'existe aucun parcours non documenté et que les contrôles de sécurité et le niveau de robustesse d'authentification sont appliqués de manière cohérente.

Verify that, if the application includes multiple authentication pathways, there are no undocumented pathways and that security controls and authentication strength are enforced consistently.

Réponse de Cybernetics : Partiellement. Toutes les voies d'authentification connues imposent la double authentification, à l'exception décrite en 6.3.3 ; une documentation d'ensemble des voies est à produire.

​

6.4.1 · niveau 1 · Vérifier que les mots de passe initiaux ou codes d'activation générés par le système sont générés de manière aléatoire et sécurisée, respectent la politique de mots de passe en vigueur, et expirent après une courte période ou après leur première utilisation. Ces secrets initiaux ne doivent pas pouvoir devenir le mot de passe à long terme.

Verify that system generated initial passwords or activation codes are securely randomly generated, follow the existing password policy, and expire after a short period of time or after they are initially used. These initial secrets must not be permitted to become the long term password.

Réponse de Cybernetics : Partiellement. Les mots de passe initiaux sont aléatoires, respectent la longueur minimale et doivent être changés à la première connexion, mais ils sont envoyés par e-mail et n'expirent pas ; leur remplacement par un lien d'activation est planifié.

​

6.4.2 · niveau 1 · Vérifier que les indices de mot de passe ou l'authentification basée sur les connaissances (dites « questions secrètes ») ne sont pas présents.

Verify that password hints or knowledge-based authentication (so-called "secret questions") are not present.

Réponse de Cybernetics : Oui. Aucun indice de mot de passe ni question secrète n'est utilisé.

​

6.4.3 · niveau 2 · Vérifier qu'un processus sécurisé de réinitialisation d'un mot de passe oublié est mis en œuvre, qui ne contourne aucun des mécanismes d'authentification multifacteur activés.

Verify that a secure process for resetting a forgotten password is implemented, that does not bypass any enabled multi-factor authentication mechanisms.

Réponse de Cybernetics : Oui. La réinitialisation passe par un lien à usage unique de courte durée et ne connecte pas l'utilisateur : le second facteur reste exigé à la connexion suivante.

​

6.4.4 · niveau 2 · Vérifier que, en cas de perte d'un facteur d'authentification multifacteur, une preuve de vérification d'identité est exigée au même niveau que lors de l'enrôlement.

Verify that if a multi-factor authentication factor is lost, evidence of identity proofing is performed at the same level as during enrollment.

Réponse de Cybernetics : Partiellement. En cas de perte du second facteur, l'utilisateur dispose de codes de récupération ou d'une réinitialisation par le support ; le renforcement de la vérification d'identité lors du réenrôlement du second facteur est planifié.

​

6.5.1 · niveau 2 · Vérifier que les secrets de consultation (lookup secrets), les demandes ou codes d'authentification hors bande et les mots de passe à usage unique basés sur le temps (TOTP) ne peuvent être utilisés avec succès qu'une seule fois.

Verify that lookup secrets, out-of-band authentication requests or codes, and time-based one-time passwords (TOTPs) are only successfully usable once.

Réponse de Cybernetics : Partiellement. Les codes TOTP, de récupération et par e-mail sont conçus pour un usage unique ; la garantie d'usage unique en cas de requêtes simultanées est en cours de renforcement.

​

6.5.2 · niveau 2 · Vérifier que, lorsqu'ils sont stockés dans le backend de l'application, les secrets de consultation (lookup secrets) ayant moins de 112 bits d'entropie (19 caractères alphanumériques aléatoires ou 34 chiffres aléatoires) sont hachés avec un algorithme de hachage approuvé pour le stockage des mots de passe intégrant un sel aléatoire de 32 bits. Une fonction de hachage standard peut être utilisée si le secret possède 112 bits d'entropie ou plus.

Verify that, when being stored in the application's backend, lookup secrets with less than 112 bits of entropy (19 random alphanumeric characters or 34 random digits) are hashed with an approved password storage hashing algorithm that incorporates a 32-bit random salt. A standard hash function can be used if the secret has 112 bits of entropy or more.

Réponse de Cybernetics : Oui. Les codes de récupération et les codes par e-mail sont stockés hachés avec Argon2id et un sel aléatoire.

​

6.5.3 · niveau 2 · Vérifier que les secrets de consultation (lookup secrets), les codes d'authentification hors bande et les graines des mots de passe à usage unique basés sur le temps sont générés à l'aide d'un générateur de nombres pseudo-aléatoires cryptographiquement sûr (CSPRNG) afin d'éviter les valeurs prévisibles.

Verify that lookup secrets, out-of-band authentication code, and time-based one-time password seeds, are generated using a Cryptographically Secure Pseudorandom Number Generator (CSPRNG) to avoid predictable values.

Réponse de Cybernetics : Oui. Tous ces secrets sont générés par un générateur aléatoire cryptographique.

​

6.5.4 · niveau 2 · Vérifier que les secrets de consultation (lookup secrets) et les codes d'authentification hors bande possèdent un minimum de 20 bits d'entropie (généralement 4 caractères alphanumériques aléatoires ou 6 chiffres aléatoires suffisent).

Verify that lookup secrets and out-of-band authentication codes have a minimum of 20 bits of entropy (typically 4 random alphanumeric characters or 6 random digits is sufficient).

Réponse de Cybernetics : Oui. Les codes de récupération ont environ 50 bits d'entropie et les codes par e-mail comportent 6 chiffres, avec limitation des tentatives.

​

6.5.5 · niveau 2 · Vérifier que les demandes, codes ou jetons d'authentification hors bande, ainsi que les mots de passe à usage unique basés sur le temps (TOTP), ont une durée de vie définie. Les demandes hors bande doivent avoir une durée de vie maximale de 10 minutes et les TOTP une durée de vie maximale de 30 secondes.

Verify that out-of-band authentication requests, codes, or tokens, as well as time-based one-time passwords (TOTPs) have a defined lifetime. Out of band requests must have a maximum lifetime of 10 minutes and for TOTP a maximum lifetime of 30 seconds.

Réponse de Cybernetics : Oui. Le code par e-mail expire en 5 minutes et le code TOTP a une période de 30 secondes.

​

6.6.1 · niveau 2 · Vérifier que les mécanismes d'authentification utilisant le réseau téléphonique commuté public (PSTN) pour délivrer des mots de passe à usage unique (OTP) par téléphone ou SMS ne sont proposés que lorsque le numéro de téléphone a été préalablement validé, que des méthodes alternatives plus robustes (telles que les mots de passe à usage unique basés sur le temps) sont également proposées, et que le service informe les utilisateurs des risques de sécurité associés. Pour les applications de niveau L3, le téléphone et le SMS ne doivent pas être proposés comme options.

Verify that authentication mechanisms using the Public Switched Telephone Network (PSTN) to deliver One-time Passwords (OTPs) via phone or SMS are offered only when the phone number has previously been validated, alternate stronger methods (such as Time based One-time Passwords) are also offered, and the service provides information on their security risks to users. For L3 applications, phone and SMS must not be available as options.

Réponse de Cybernetics : Sans objet. Aucun code n'est envoyé par SMS ou par téléphone.

​

6.6.2 · niveau 2 · Vérifier que les demandes, codes ou jetons d'authentification hors bande sont liés à la demande d'authentification d'origine pour laquelle ils ont été générés et ne sont pas utilisables pour une demande précédente ou ultérieure.

Verify that out-of-band authentication requests, codes, or tokens are bound to the original authentication request for which they were generated and are not usable for a previous or subsequent one.

Réponse de Cybernetics : Partiellement. Un seul code par e-mail est actif par utilisateur et il est remplacé à chaque nouvelle demande ; il n'est pas encore lié à la tentative de connexion précise.

​

6.6.3 · niveau 2 · Vérifier qu'un mécanisme d'authentification hors bande basé sur un code est protégé contre les attaques par force brute au moyen d'une limitation de débit. Envisager également l'utilisation d'un code d'au moins 64 bits d'entropie.

Verify that a code based out-of-band authentication mechanism is protected against brute force attacks by using rate limiting. Consider also using a code with at least 64 bits of entropy.

Réponse de Cybernetics : Oui. La saisie du code est limitée par défi et par adresse IP, et le compte est verrouillé temporairement après des échecs répétés.

​

6.8.1 · niveau 2 · Vérifier que, si l'application prend en charge plusieurs fournisseurs d'identité (IdP), l'identité de l'utilisateur ne peut pas être usurpée via un autre fournisseur d'identité pris en charge (par ex. en utilisant le même identifiant utilisateur). La mesure d'atténuation standard consiste pour l'application à enregistrer et identifier l'utilisateur à l'aide d'une combinaison de l'identifiant de l'IdP (servant d'espace de noms) et de l'identifiant de l'utilisateur au sein de l'IdP.

Verify that, if the application supports multiple identity providers (IdPs), the user's identity cannot be spoofed via another supported identity provider (eg. by using the same user identifier). The standard mitigation would be for the application to register and identify the user using a combination of the IdP ID (serving as a namespace) and the user's ID in the IdP.

Réponse de Cybernetics : Oui. Après un premier rattachement fait par l'adresse e-mail vérifiée d'un compte préalablement invité, chaque compte fédéré est identifié par l'identifiant immuable du fournisseur, et son organisation est contrôlée à chaque connexion.

​

6.8.2 · niveau 2 · Vérifier que la présence et l'intégrité des signatures numériques sur les assertions d'authentification (par exemple sur les JWT ou les assertions SAML) sont toujours validées, en rejetant toute assertion non signée ou dont la signature est invalide.

Verify that the presence and integrity of digital signatures on authentication assertions (for example on JWTs or SAML assertions) are always validated, rejecting any assertions that are unsigned or have invalid signatures.

Réponse de Cybernetics : Oui. La signature des jetons d'identité Microsoft est vérifiée (clés publiques, audience, nonce) ; Google est interrogé directement côté serveur, sans assertion transmise par le navigateur.

​

6.8.3 · niveau 2 · Vérifier que les assertions SAML sont traitées de manière unique et utilisées une seule fois pendant leur période de validité afin d'empêcher les attaques par rejeu.

Verify that SAML assertions are uniquely processed and used only once within the validity period to prevent replay attacks.

Réponse de Cybernetics : Sans objet. Aucune fédération SAML n'est utilisée.

​

6.8.4 · niveau 2 · Vérifier que, si une application utilise un fournisseur d'identité (IdP) distinct et attend un niveau de robustesse, des méthodes ou une récence d'authentification spécifiques pour certaines fonctions, l'application le vérifie à l'aide des informations renvoyées par l'IdP. Par exemple, si OIDC est utilisé, cela peut être réalisé en validant les claims de l'ID Token tels que 'acr', 'amr' et 'auth_time' (s'ils sont présents). Si l'IdP ne fournit pas ces informations, l'application doit disposer d'une approche de repli documentée supposant que le mécanisme d'authentification de robustesse minimale a été utilisé (par exemple, une authentification à facteur unique par nom d'utilisateur et mot de passe).

Verify that, if an application uses a separate Identity Provider (IdP) and expects specific authentication strength, methods, or recentness for specific functions, the application verifies this using the information returned by the IdP. For example, if OIDC is used, this might be achieved by validating ID Token claims such as 'acr', 'amr', and 'auth_time' (if present). If the IdP does not provide this information, the application must have a documented fallback approach that assumes that the minimum strength authentication mechanism was used (for example, single-factor authentication using username and password).

Réponse de Cybernetics : Partiellement. Cybernetics ne se fie pas à la force d'authentification déclarée par le fournisseur et impose son propre second facteur après une connexion Google ou Microsoft (sauf l'exception décrite en 6.3.3) ; ce principe n'est pas encore documenté.

7.1.1 · niveau 2 · Vérifier que le délai d'inactivité de session de l'utilisateur et la durée de vie maximale absolue de la session sont documentés, sont appropriés en combinaison avec les autres contrôles, et que la documentation inclut une justification de tout écart par rapport aux exigences de réauthentification du NIST SP 800-63B.

Verify that the user's session inactivity timeout and absolute maximum session lifetime are documented, are appropriate in combination with other controls, and that the documentation includes justification for any deviations from NIST SP 800-63B re-authentication requirements.

Réponse de Cybernetics : Partiellement. Les durées de session sont définies dans le code (15 minutes d'inactivité, 8 heures au maximum, 24 heures fixes pour les comptes Admin Support), mais elles ne sont pas encore justifiées dans une politique de session documentée au regard du NIST SP 800-63B.

​

7.1.2 · niveau 2 · Vérifier que la documentation définit le nombre de sessions simultanées (parallèles) autorisées pour un même compte, ainsi que les comportements attendus et les actions à entreprendre lorsque le nombre maximal de sessions actives est atteint.

Verify that the documentation defines how many concurrent (parallel) sessions are allowed for one account as well as the intended behaviors and actions to be taken when the maximum number of active sessions is reached.

Réponse de Cybernetics : Partiellement. Une seule session active est autorisée par compte : une nouvelle connexion doit reprendre explicitement la session existante, ce qui ferme l'ancienne. Ce comportement est implémenté mais pas encore décrit dans une politique documentée.

​

7.1.3 · niveau 2 · Vérifier que tous les systèmes qui créent et gèrent des sessions utilisateur dans le cadre d'un écosystème de gestion d'identité fédérée (tels que les systèmes SSO) sont documentés, avec les contrôles permettant de coordonner les durées de vie des sessions, leur terminaison et toute autre condition nécessitant une réauthentification.

Verify that all systems that create and manage user sessions as part of a federated identity management ecosystem (such as SSO systems) are documented along with controls to coordinate session lifetimes, termination, and any other conditions that require re-authentication.

Réponse de Cybernetics : Partiellement. Microsoft Entra ID et Google sont les fournisseurs d'identité fédérés ; la session Cybernetics est indépendante de celle du fournisseur, et la coordination des durées et des déconnexions n'est pas encore documentée.

​

7.2.1 · niveau 1 · Vérifier que l'application effectue toutes les vérifications de jetons de session à l'aide d'un service backend de confiance.

Verify that the application performs all session token verification using a trusted, backend service.

Réponse de Cybernetics : Oui. Chaque jeton de session est vérifié côté serveur par rapport à la base (empreinte stockée, expiration, compte).

​

7.2.2 · niveau 1 · Vérifier que l'application utilise pour la gestion de session soit des jetons autonomes (self-contained), soit des jetons de référence, générés dynamiquement, c'est-à-dire sans recourir à des secrets ou clés d'API statiques.

Verify that the application uses either self-contained or reference tokens that are dynamically generated for session management, i.e. not using static API secrets and keys.

Réponse de Cybernetics : Oui. Les sessions reposent sur des jetons de référence générés à chaque authentification, jamais sur des secrets statiques.

​

7.2.3 · niveau 1 · Vérifier que, si des jetons de référence sont utilisés pour représenter les sessions utilisateur, ils sont uniques, générés à l'aide d'un générateur de nombres pseudo-aléatoires cryptographiquement sûr (CSPRNG) et possèdent au moins 128 bits d'entropie.

Verify that if reference tokens are used to represent user sessions, they are unique and generated using a cryptographically secure pseudo-random number generator (CSPRNG) and possess at least 128 bits of entropy.

Réponse de Cybernetics : Oui. Les jetons sont uniques et issus d'un générateur cryptographique, avec une entropie bien supérieure à 128 bits ; seule leur empreinte est conservée.

​

7.2.4 · niveau 1 · Vérifier que l'application génère un nouveau jeton de session lors de l'authentification de l'utilisateur, y compris lors de la réauthentification, et met fin au jeton de session en cours.

Verify that the application generates a new session token on user authentication, including re-authentication, and terminates the current session token.

Réponse de Cybernetics : Partiellement. Un nouveau jeton est émis à chaque connexion et l'ancien est supprimé ; la réauthentification avant une opération sensible ne renouvelle pas encore le jeton de session.

​

7.3.1 · niveau 2 · Vérifier qu'il existe un délai d'inactivité tel que la réauthentification est imposée conformément à l'analyse de risque et aux décisions de sécurité documentées.

Verify that there is an inactivity timeout such that re-authentication is enforced according to risk analysis and documented security decisions.

Réponse de Cybernetics : Partiellement. Après 15 minutes d'inactivité, une nouvelle authentification est exigée ; les comptes Admin Support ont une durée fixe de 24 heures sans délai d'inactivité, dont la justification reste à documenter.

​

7.3.2 · niveau 2 · Vérifier qu'il existe une durée de vie maximale absolue de session telle que la réauthentification est imposée conformément à l'analyse de risque et aux décisions de sécurité documentées.

Verify that there is an absolute maximum session lifetime such that re-authentication is enforced according to risk analysis and documented security decisions.

Réponse de Cybernetics : Oui. La durée absolue d'une session est plafonnée à 8 heures (24 heures non prolongeables pour les comptes Admin Support) ; au-delà, le jeton est révoqué.

​

7.4.1 · niveau 1 · Vérifier que, lorsque la terminaison d'une session est déclenchée (par exemple par déconnexion ou expiration), l'application interdit toute utilisation ultérieure de la session. Pour les jetons de référence ou les sessions avec état, cela implique d'invalider les données de session dans le backend de l'application. Les applications utilisant des jetons autonomes (self-contained) devront recourir à une solution telle que la tenue d'une liste de jetons révoqués, le rejet des jetons émis avant une date et heure propre à chaque utilisateur, ou la rotation d'une clé de signature propre à chaque utilisateur.

Verify that when session termination is triggered (such as logout or expiration), the application disallows any further use of the session. For reference tokens or stateful sessions, this means invalidating the session data at the application backend. Applications using self-contained tokens will need a solution such as maintaining a list of terminated tokens, disallowing tokens produced before a per-user date and time or rotating a per-user signing key.

Réponse de Cybernetics : Oui. La déconnexion supprime tous les jetons du compte côté serveur, et un jeton expiré est refusé.

​

7.4.2 · niveau 1 · Vérifier que l'application met fin à toutes les sessions actives lorsqu'un compte utilisateur est désactivé ou supprimé (par exemple lorsqu'un employé quitte l'entreprise).

Verify that the application terminates all active sessions when a user account is disabled or deleted (such as an employee leaving the company).

Réponse de Cybernetics : Oui. Un compte supprimé ne peut plus s'authentifier, et les jetons d'un compte non confirmé ou détaché de son entreprise sont révoqués.

​

7.4.3 · niveau 2 · Vérifier que l'application offre la possibilité de mettre fin à toutes les autres sessions actives après la modification ou la suppression réussie de tout facteur d'authentification (y compris le changement de mot de passe via réinitialisation ou récupération et, le cas échéant, la mise à jour des paramètres MFA).

Verify that the application gives the option to terminate all other active sessions after a successful change or removal of any authentication factor (including password change via reset or recovery and, if present, an MFA settings update).

Réponse de Cybernetics : Oui. Toutes les sessions sont révoquées après une réinitialisation du mot de passe ou de la double authentification ; le modèle à session unique ne laisse aucune autre session ouverte.

​

7.4.4 · niveau 2 · Vérifier que toutes les pages nécessitant une authentification offrent un accès facile et visible à la fonctionnalité de déconnexion.

Verify that all pages that require authentication have easy and visible access to logout functionality.

Réponse de Cybernetics : Oui. La déconnexion est accessible depuis le menu, présent sur toutes les pages authentifiées.

​

7.4.5 · niveau 2 · Vérifier que les administrateurs de l'application peuvent mettre fin aux sessions actives d'un utilisateur donné ou de tous les utilisateurs.

Verify that application administrators are able to terminate active sessions for an individual user or for all users.

Réponse de Cybernetics : Partiellement. La fin des sessions d'un utilisateur passe aujourd'hui par des actions indirectes (réinitialisation, détachement, retrait du rôle support) ; il n'existe pas encore de fonction d'administration dédiée pour mettre fin aux sessions d'un utilisateur, et la révocation au retrait d'un membre support est en cours de correction.

​

7.5.1 · niveau 2 · Vérifier que l'application exige une réauthentification complète avant d'autoriser la modification d'attributs sensibles du compte pouvant affecter l'authentification, tels que l'adresse e-mail, le numéro de téléphone, la configuration MFA ou d'autres informations utilisées pour la récupération du compte.

Verify that the application requires full re-authentication before allowing modifications to sensitive account attributes which may affect authentication such as email address, phone number, MFA configuration, or other information used in account recovery.

Réponse de Cybernetics : Partiellement. Une réauthentification récente est exigée pour changer l'e-mail, le mot de passe ou les passkeys, mais certaines opérations sensibles ne l'exigent pas encore.

​

7.5.2 · niveau 2 · Vérifier que les utilisateurs peuvent consulter et (après s'être réauthentifiés avec au moins un facteur) mettre fin à une ou à l'ensemble de leurs sessions actuellement actives.

Verify that users are able to view and (having authenticated again with at least one factor) terminate any or all currently active sessions.

Réponse de Cybernetics : Partiellement. Il n'existe pas de liste des sessions actives, mais la session est unique : l'utilisateur voit ses appareils connus, peut reprendre sa session, et le lien « Ce n'est pas moi » révoque toutes les sessions.

​

7.6.1 · niveau 2 · Vérifier que la durée de vie et la terminaison des sessions entre les parties utilisatrices (Relying Parties, RP) et les fournisseurs d'identité (IdP) se comportent comme documenté, en exigeant une réauthentification lorsque nécessaire, par exemple lorsque le délai maximal entre deux événements d'authentification auprès de l'IdP est atteint.

Verify that session lifetime and termination between Relying Parties (RPs) and Identity Providers (IdPs) behave as documented, requiring re-authentication as necessary such as when the maximum time between IdP authentication events is reached.

Réponse de Cybernetics : Partiellement. Le jeton d'identité Microsoft est validé à la connexion, mais l'ancienneté de l'authentification auprès du fournisseur n'est pas limitée, et la déconnexion n'est pas propagée au fournisseur d'identité.

​

7.6.2 · niveau 2 · Vérifier que la création d'une session nécessite soit le consentement de l'utilisateur, soit une action explicite, empêchant ainsi la création de nouvelles sessions applicatives sans interaction de l'utilisateur.

Verify that creation of a session requires either the user's consent or an explicit action, preventing the creation of new application sessions without user interaction.

Réponse de Cybernetics : Oui. Une session n'est créée qu'après une action explicite de l'utilisateur (formulaire, passkey ou connexion Google ou Microsoft qu'il déclenche).

8.1.1 · niveau 1 · Vérifier que la documentation d'autorisation définit des règles de restriction de l'accès au niveau des fonctions et au niveau des données spécifiques, fondées sur les permissions du consommateur et les attributs des ressources.

Verify that authorization documentation defines rules for restricting function-level and data-specific access based on consumer permissions and resource attributes.

Réponse de Cybernetics : Partiellement. Les rôles et les permissions liées aux offres sont définis dans le code ; il n'existe pas encore de documentation formelle des règles d'accès aux fonctions et aux données.

​

8.1.2 · niveau 2 · Vérifier que la documentation d'autorisation définit des règles de restriction de l'accès au niveau des champs (en lecture comme en écriture), fondées sur les permissions du consommateur et les attributs des ressources. Noter que ces règles peuvent dépendre d'autres valeurs d'attributs de l'objet de données concerné, telles que son état ou son statut.

Verify that authorization documentation defines rules for field-level access restrictions (both read and write) based on consumer permissions and resource attributes. Note that these rules might depend on other attribute values of the relevant data object, such as state or status.

Réponse de Cybernetics : Partiellement. Les règles d'accès champ par champ ne sont pas documentées : elles existent uniquement dans les validateurs et les sérialisations.

​

8.2.1 · niveau 1 · Vérifier que l'application s'assure que l'accès au niveau des fonctions est restreint aux consommateurs disposant de permissions explicites.

Verify that the application ensures that function-level access is restricted to consumers with explicit permissions.

Réponse de Cybernetics : Partiellement. Chaque route passe par une politique d'autorisation côté serveur (rôle croisé avec les permissions de l'offre), mais des défauts résiduels subsistent, dont la définition des droits du rôle Éditeur.

​

8.2.2 · niveau 1 · Vérifier que l'application s'assure que l'accès aux données spécifiques est restreint aux consommateurs disposant de permissions explicites sur ces éléments de données, afin d'atténuer les références directes non sécurisées à des objets (IDOR) et les défauts d'autorisation au niveau des objets (BOLA).

Verify that the application ensures that data-specific access is restricted to consumers with explicit permissions to specific data items to mitigate insecure direct object reference (IDOR) and broken object level authorization (BOLA).

Réponse de Cybernetics : Partiellement. Les objets sont en général contrôlés par politique et par entreprise, et des tests d'isolation existent, mais certaines références d'objets restent insuffisamment vérifiées.

​

8.2.3 · niveau 2 · Vérifier que l'application s'assure que l'accès au niveau des champs est restreint aux consommateurs disposant de permissions explicites sur ces champs, afin d'atténuer les défauts d'autorisation au niveau des propriétés d'objets (BOPLA).

Verify that the application ensures that field-level access is restricted to consumers with explicit permissions to specific fields to mitigate broken object property level authorization (BOPLA).

Réponse de Cybernetics : Partiellement. Les champs acceptés sont filtrés par des validateurs, mais certaines références transmises dans une requête ne sont pas encore contrôlées au regard des droits de l'appelant.

​

8.3.1 · niveau 1 · Vérifier que l'application applique les règles d'autorisation au niveau d'une couche de service de confiance et ne s'appuie pas sur des contrôles qu'un consommateur non fiable pourrait manipuler, tels que du JavaScript côté client.

Verify that the application enforces authorization rules at a trusted service layer and doesn't rely on controls that an untrusted consumer could manipulate, such as client-side JavaScript.

Réponse de Cybernetics : Oui. Toutes les règles d'autorisation s'appliquent côté serveur ; l'interface ne fait que refléter les droits.

​

8.4.1 · niveau 2 · Vérifier que les applications multi-locataires (multi-tenant) utilisent des contrôles inter-locataires garantissant que les opérations d'un consommateur n'affecteront jamais des locataires avec lesquels il n'est pas autorisé à interagir.

Verify that multi-tenant applications use cross-tenant controls to ensure consumer operations will never affect tenants with which they do not have permissions to interact.

Réponse de Cybernetics : Partiellement. Le cloisonnement entre entreprises est appliqué et testé en grande partie, mais des écarts résiduels ont été identifiés et sont en cours de correction.

9.1.1 · niveau 1 · Vérifier que les jetons autonomes (self-contained) sont validés à l'aide de leur signature numérique ou de leur MAC afin de se protéger contre toute altération avant d'accepter le contenu du jeton.

Verify that self-contained tokens are validated using their digital signature or MAC to protect against tampering before accepting the token's contents.

Réponse de Cybernetics : Oui. Le jeton d'identité Microsoft est vérifié par signature, et les liens signés émis par la plateforme sont contrôlés par HMAC avant tout usage.

​

9.1.2 · niveau 1 · Vérifier que seuls les algorithmes figurant dans une liste d'autorisation peuvent être utilisés pour créer et vérifier les jetons autonomes, pour un contexte donné. La liste d'autorisation doit inclure les algorithmes permis, idéalement uniquement des algorithmes symétriques ou uniquement des algorithmes asymétriques, et ne doit pas inclure l'algorithme 'None'. Si les algorithmes symétriques et asymétriques doivent tous deux être pris en charge, des contrôles supplémentaires seront nécessaires pour empêcher la confusion de clés.

Verify that only algorithms on an allowlist can be used to create and verify self-contained tokens, for a given context. The allowlist must include the permitted algorithms, ideally only either symmetric or asymmetric algorithms, and must not include the 'None' algorithm. If both symmetric and asymmetric must be supported, additional controls will be needed to prevent key confusion.

Réponse de Cybernetics : Partiellement. L'algorithme « none » est refusé et l'algorithme doit correspondre à la clé publiée par le fournisseur, mais aucune liste explicite d'algorithmes autorisés n'est encore configurée.

​

9.1.3 · niveau 1 · Vérifier que le matériel de clé utilisé pour valider les jetons autonomes provient de sources de confiance préconfigurées pour l'émetteur du jeton, empêchant ainsi les attaquants de spécifier des sources et des clés non fiables. Pour les JWT et autres structures JWS, les en-têtes tels que 'jku', 'x5u' et 'jwk' doivent être validés par rapport à une liste d'autorisation de sources de confiance.

Verify that key material that is used to validate self-contained tokens is from trusted pre-configured sources for the token issuer, preventing attackers from specifying untrusted sources and keys. For JWTs and other JWS structures, headers such as 'jku', 'x5u', and 'jwk' must be validated against an allowlist of trusted sources.

Réponse de Cybernetics : Oui. Les clés de vérification proviennent uniquement du point de publication officiel de Microsoft, configuré dans le code ; les clés désignées par l'en-tête du jeton ne sont pas acceptées.

​

9.2.1 · niveau 1 · Vérifier que, si une période de validité est présente dans les données du jeton, le jeton et son contenu ne sont acceptés que si l'instant de vérification se situe dans cette période de validité. Par exemple, pour les JWT, les claims 'nbf' et 'exp' doivent être vérifiés.

Verify that, if a validity time span is present in the token data, the token and its content are accepted only if the verification time is within this validity time span. For example, for JWTs, the claims 'nbf' and 'exp' must be verified.

Réponse de Cybernetics : Oui. La période de validité du jeton d'identité est vérifiée, et les liens signés portent une expiration contrôlée.

​

9.2.2 · niveau 2 · Vérifier que le service recevant un jeton valide que celui-ci est du type correct et destiné à l'usage prévu avant d'accepter son contenu. Par exemple, seuls les jetons d'accès peuvent être acceptés pour les décisions d'autorisation et seuls les ID Tokens peuvent être utilisés pour prouver l'authentification de l'utilisateur.

Verify that the service receiving a token validates the token to be the correct type and is meant for the intended purpose before accepting the token's contents. For example, only access tokens can be accepted for authorization decisions and only ID Tokens can be used for proving user authentication.

Réponse de Cybernetics : Oui. Le jeton d'identité, récupéré directement auprès du fournisseur, sert uniquement à prouver l'identité ; chaque lien signé est lié à une route précise.

​

9.2.3 · niveau 2 · Vérifier que le service n'accepte que les jetons destinés à être utilisés avec ce service (audience). Pour les JWT, cela peut être réalisé en validant le claim 'aud' par rapport à une liste d'autorisation définie dans le service.

Verify that the service only accepts tokens which are intended for use with that service (audience). For JWTs, this can be achieved by validating the 'aud' claim against an allowlist defined in the service.

Réponse de Cybernetics : Oui. Le destinataire du jeton d'identité doit correspondre à l'application Cybernetics, l'émetteur est contrôlé, et un nonce lié au navigateur est vérifié.

​

9.2.4 · niveau 2 · Vérifier que, si un émetteur de jetons utilise la même clé privée pour émettre des jetons à destination de différentes audiences, les jetons émis contiennent une restriction d'audience identifiant de manière unique les audiences visées. Cela empêchera la réutilisation d'un jeton auprès d'une audience non prévue. Si l'identifiant d'audience est provisionné dynamiquement, l'émetteur de jetons doit valider ces audiences afin de s'assurer qu'elles ne conduisent pas à une usurpation d'audience.

Verify that, if a token issuer uses the same private key for issuing tokens to different audiences, the issued tokens contain an audience restriction that uniquely identifies the intended audiences. This will prevent a token from being reused with an unintended audience. If the audience identifier is dynamically provisioned, the token issuer must validate these audiences in order to make sure that they do not result in audience impersonation.

Réponse de Cybernetics : Sans objet. Cybernetics n'émet aucun jeton autonome (de type JWT) destiné à plusieurs destinataires : ses sessions reposent sur des jetons de référence, et ses liens signés sont propres à une seule route.

10.1.1 · niveau 2 · Vérifier que les jetons ne sont envoyés qu'aux composants qui en ont strictement besoin. Par exemple, lors de l'utilisation d'un modèle backend-for-frontend pour les applications JavaScript exécutées dans le navigateur, les jetons d'accès et de rafraîchissement ne doivent être accessibles qu'au backend.

Verify that tokens are only sent to components that strictly need them. For example, when using a backend-for-frontend pattern for browser-based JavaScript applications, access and refresh tokens shall only be accessible for the backend.

Réponse de Cybernetics : Oui. Les jetons remis par Google et Microsoft sont utilisés uniquement côté serveur pendant la connexion, jamais transmis au navigateur ni conservés ; les jetons des connecteurs restent en mémoire dans le service qui les utilise.

​

10.1.2 · niveau 2 · Vérifier que le client n'accepte des valeurs du serveur d'autorisation (telles que le code d'autorisation ou l'ID Token) que si ces valeurs résultent d'un flux d'autorisation initié par la même session d'agent utilisateur et la même transaction. Cela exige que les secrets générés par le client, tels que le 'code_verifier' du proof key for code exchange (PKCE), le 'state' ou le 'nonce' OIDC, ne soient pas devinables, soient spécifiques à la transaction et soient liés de manière sécurisée à la fois au client et à la session d'agent utilisateur dans laquelle la transaction a été initiée.

Verify that the client only accepts values from the authorization server (such as the authorization code or ID Token) if these values result from an authorization flow that was initiated by the same user agent session and transaction. This requires that client-generated secrets, such as the proof key for code exchange (PKCE) 'code_verifier', 'state' or OIDC 'nonce', are not guessable, are specific to the transaction, and are securely bound to both the client and the user agent session in which the transaction was started.

Réponse de Cybernetics : Oui. Chaque connexion génère un paramètre state, un vérificateur PKCE et un nonce aléatoires et à usage unique, liés au navigateur par des cookies protégés (HttpOnly, Secure, 10 minutes) et effacés au retour.

​

10.2.1 · niveau 2 · Vérifier que, si le flux code est utilisé, le client OAuth dispose d'une protection contre les attaques de forgerie de requête basées sur le navigateur, communément appelées cross-site request forgery (CSRF), qui déclenchent des requêtes de jeton, soit en utilisant la fonctionnalité proof key for code exchange (PKCE), soit en contrôlant le paramètre 'state' envoyé dans la requête d'autorisation.

Verify that, if the code flow is used, the OAuth client has protection against browser-based request forgery attacks, commonly known as cross-site request forgery (CSRF), which trigger token requests, either by using proof key for code exchange (PKCE) functionality or checking the 'state' parameter that was sent in the authorization request.

Réponse de Cybernetics : Oui. Le flux « code d'autorisation » combine la vérification du paramètre state et PKCE (méthode S256) ; un retour sans correspondance est rejeté avant l'échange du code.

​

10.2.2 · niveau 2 · Vérifier que, si le client OAuth peut interagir avec plusieurs serveurs d'autorisation, il dispose d'une défense contre les attaques de type mix-up. Par exemple, il pourrait exiger que le serveur d'autorisation renvoie la valeur du paramètre 'iss' et la valider dans la réponse d'autorisation et dans la réponse de jeton.

Verify that, if the OAuth client can interact with more than one authorization server, it has a defense against mix-up attacks. For example, it could require that the authorization server return the 'iss' parameter value and validate it in the authorization response and the token response.

Réponse de Cybernetics : Oui. Les deux fournisseurs sont fixes et préconfigurés ; chacun a sa propre URL de retour et son propre cookie de state, ce qui empêche de confondre les réponses entre fournisseurs.

​

10.3.1 · niveau 2 · Vérifier que le serveur de ressources n'accepte que les jetons d'accès destinés à être utilisés avec ce service (audience). L'audience peut être incluse dans un jeton d'accès structuré (tel que le claim 'aud' d'un JWT), ou elle peut être contrôlée via le point de terminaison d'introspection de jetons.

Verify that the resource server only accepts access tokens that are intended for use with that service (audience). The audience may be included in a structured access token (such as the 'aud' claim in JWT), or it can be checked using the token introspection endpoint.

Réponse de Cybernetics : Sans objet. Les API de Cybernetics n'acceptent aucun jeton d'accès OAuth : elles utilisent des jetons de session internes.

​

10.3.2 · niveau 2 · Vérifier que le serveur de ressources applique les décisions d'autorisation sur la base des claims du jeton d'accès qui définissent l'autorisation déléguée. Si des claims tels que 'sub', 'scope' et 'authorization_details' sont présents, ils doivent faire partie de la décision.

Verify that the resource server enforces authorization decisions based on claims from the access token that define delegated authorization. If claims such as 'sub', 'scope', and 'authorization_details' are present, they must be part of the decision.

Réponse de Cybernetics : Sans objet. Cybernetics n'est pas un serveur de ressources OAuth.

​

10.3.3 · niveau 2 · Vérifier que, si une décision de contrôle d'accès nécessite d'identifier un utilisateur unique à partir d'un jeton d'accès (JWT ou réponse d'introspection de jeton associée), le serveur de ressources identifie l'utilisateur à partir de claims qui ne peuvent pas être réattribués à d'autres utilisateurs. Cela implique généralement d'utiliser une combinaison des claims 'iss' et 'sub'.

Verify that if an access control decision requires identifying a unique user from an access token (JWT or related token introspection response), the resource server identifies the user from claims that cannot be reassigned to other users. Typically, it means using a combination of 'iss' and 'sub' claims.

Réponse de Cybernetics : Sans objet. Cybernetics n'est pas un serveur de ressources OAuth.

​

10.3.4 · niveau 2 · Vérifier que, si le serveur de ressources exige un niveau de robustesse, des méthodes ou une récence d'authentification spécifiques, il vérifie que le jeton d'accès présenté satisfait à ces contraintes. Par exemple, s'ils sont présents, en utilisant respectivement les claims OIDC 'acr', 'amr' et 'auth_time'.

Verify that, if the resource server requires specific authentication strength, methods, or recentness, it verifies that the presented access token satisfies these constraints. For example, if present, using the OIDC 'acr', 'amr' and 'auth_time' claims respectively.

Réponse de Cybernetics : Sans objet. Cybernetics n'est pas un serveur de ressources OAuth.

​

10.4.1 · niveau 1 · Vérifier que le serveur d'autorisation valide les URI de redirection sur la base d'une liste d'autorisation d'URI préenregistrées propre à chaque client, par comparaison exacte de chaînes.

Verify that the authorization server validates redirect URIs based on a client-specific allowlist of pre-registered URIs using exact string comparison.

Réponse de Cybernetics : Sans objet. Cybernetics n'est pas un serveur d'autorisation ; ce contrôle est assuré par Google et Microsoft, auprès desquels les URL de retour de Cybernetics sont préenregistrées.

​

10.4.2 · niveau 1 · Vérifier que, si le serveur d'autorisation renvoie le code d'autorisation dans la réponse d'autorisation, celui-ci ne peut être utilisé qu'une seule fois pour une requête de jeton. Lors de la seconde requête valide avec un code d'autorisation déjà utilisé pour émettre un jeton d'accès, le serveur d'autorisation doit rejeter la requête de jeton et révoquer tous les jetons émis en lien avec ce code d'autorisation.

Verify that, if the authorization server returns the authorization code in the authorization response, it can be used only once for a token request. For the second valid request with an authorization code that has already been used to issue an access token, the authorization server must reject a token request and revoke any issued tokens related to the authorization code.

Réponse de Cybernetics : Sans objet. Cybernetics n'est pas un serveur d'autorisation.

​

10.4.3 · niveau 1 · Vérifier que le code d'autorisation a une courte durée de vie. La durée de vie maximale peut aller jusqu'à 10 minutes pour les applications de niveau L1 et L2 et jusqu'à 1 minute pour les applications de niveau L3.

Verify that the authorization code is short-lived. The maximum lifetime can be up to 10 minutes for L1 and L2 applications and up to 1 minute for L3 applications.

Réponse de Cybernetics : Sans objet. Cybernetics n'est pas un serveur d'autorisation.

​

10.4.4 · niveau 1 · Vérifier que, pour un client donné, le serveur d'autorisation n'autorise que l'utilisation des grants dont ce client a besoin. Noter que les grants 'token' (flux Implicit) et 'password' (flux Resource Owner Password Credentials) ne doivent plus être utilisés.

Verify that for a given client, the authorization server only allows the usage of grants that this client needs to use. Note that the grants 'token' (Implicit flow) and 'password' (Resource Owner Password Credentials flow) must no longer be used.

Réponse de Cybernetics : Sans objet. Cybernetics n'est pas un serveur d'autorisation ; côté client, seuls les flux « code d'autorisation » (connexion) et « client credentials » (connecteurs) sont utilisés, jamais les flux implicite ou « mot de passe ».

​

10.4.5 · niveau 1 · Vérifier que le serveur d'autorisation atténue les attaques par rejeu de jetons de rafraîchissement pour les clients publics, de préférence en utilisant des jetons de rafraîchissement liés à l'émetteur (sender-constrained), c'est-à-dire Demonstrating Proof of Possession (DPoP) ou des jetons d'accès liés à un certificat via TLS mutuel (mTLS). Pour les applications de niveau L1 et L2, la rotation des jetons de rafraîchissement peut être utilisée. Si la rotation des jetons de rafraîchissement est utilisée, le serveur d'autorisation doit invalider le jeton de rafraîchissement après utilisation et révoquer tous les jetons de rafraîchissement de cette autorisation si un jeton de rafraîchissement déjà utilisé et invalidé est présenté.

Verify that the authorization server mitigates refresh token replay attacks for public clients, preferably using sender-constrained refresh tokens, i.e., Demonstrating Proof of Possession (DPoP) or Certificate-Bound Access Tokens using mutual TLS (mTLS). For L1 and L2 applications, refresh token rotation may be used. If refresh token rotation is used, the authorization server must invalidate the refresh token after usage, and revoke all refresh tokens for that authorization if an already used and invalidated refresh token is provided.

Réponse de Cybernetics : Sans objet. Cybernetics n'est pas un serveur d'autorisation.

​

10.4.6 · niveau 2 · Vérifier que, si le grant code est utilisé, le serveur d'autorisation atténue les attaques par interception du code d'autorisation en exigeant le proof key for code exchange (PKCE). Pour les requêtes d'autorisation, le serveur d'autorisation doit exiger une valeur 'code_challenge' valide et ne doit pas accepter la valeur 'plain' pour 'code_challenge_method'. Pour une requête de jeton, il doit exiger la validation du paramètre 'code_verifier'.

Verify that, if the code grant is used, the authorization server mitigates authorization code interception attacks by requiring proof key for code exchange (PKCE). For authorization requests, the authorization server must require a valid 'code_challenge' value and must not accept a 'code_challenge_method' value of 'plain'. For a token request, it must require validation of the 'code_verifier' parameter.

Réponse de Cybernetics : Sans objet. Cybernetics n'est pas un serveur d'autorisation ; côté client, PKCE S256 est toujours utilisé.

​

10.4.7 · niveau 2 · Vérifier que, si le serveur d'autorisation prend en charge l'enregistrement dynamique de clients non authentifié, il atténue le risque lié aux applications clientes malveillantes. Il doit valider les métadonnées du client telles que toute URI enregistrée, s'assurer du consentement de l'utilisateur et avertir l'utilisateur avant de traiter une requête d'autorisation impliquant une application cliente non fiable.

Verify that if the authorization server supports unauthenticated dynamic client registration, it mitigates the risk of malicious client applications. It must validate client metadata such as any registered URIs, ensure the user's consent, and warn the user before processing an authorization request with an untrusted client application.

Réponse de Cybernetics : Sans objet. Pas de serveur d'autorisation, donc pas d'enregistrement dynamique de clients.

​

10.4.8 · niveau 2 · Vérifier que les jetons de rafraîchissement ont une expiration absolue, y compris lorsqu'une expiration glissante des jetons de rafraîchissement est appliquée.

Verify that refresh tokens have an absolute expiration, including if sliding refresh token expiration is applied.

Réponse de Cybernetics : Sans objet. Cybernetics n'est pas un serveur d'autorisation.

​

10.4.9 · niveau 2 · Vérifier que les jetons de rafraîchissement et les jetons d'accès de référence peuvent être révoqués par un utilisateur autorisé via l'interface utilisateur du serveur d'autorisation, afin d'atténuer le risque lié aux clients malveillants ou aux jetons volés.

Verify that refresh tokens and reference access tokens can be revoked by an authorized user using the authorization server user interface, to mitigate the risk of malicious clients or stolen tokens.

Réponse de Cybernetics : Sans objet. Cybernetics n'est pas un serveur d'autorisation.

​

10.4.10 · niveau 2 · Vérifier que le client confidentiel est authentifié pour les requêtes de canal arrière (backchannel) du client vers le serveur d'autorisation, telles que les requêtes de jeton, les pushed authorization requests (PAR) et les requêtes de révocation de jeton.

Verify that confidential client is authenticated for client-to-authorized server backchannel requests such as token requests, pushed authorization requests (PAR), and token revocation requests.

Réponse de Cybernetics : Sans objet. L'exigence porte sur le serveur d'autorisation ; côté client, Cybernetics s'authentifie par secret client lors de l'échange du code et des demandes des connecteurs.

​

10.4.11 · niveau 2 · Vérifier que la configuration du serveur d'autorisation n'attribue au client OAuth que les scopes requis.

Verify that the authorization server configuration only assigns the required scopes to the OAuth client.

Réponse de Cybernetics : Sans objet. L'attribution des droits (scopes) relève des serveurs d'autorisation de Google et Microsoft ; la réduction des droits demandés par Cybernetics est planifiée.

​

10.5.1 · niveau 2 · Vérifier que le client (en tant que partie utilisatrice) atténue les attaques par rejeu d'ID Token. Par exemple, en s'assurant que le claim 'nonce' de l'ID Token correspond à la valeur 'nonce' envoyée dans la requête d'authentification à l'OpenID Provider (appelée en OAuth2 requête d'autorisation envoyée au serveur d'autorisation).

Verify that the client (as the relying party) mitigates ID Token replay attacks. For example, by ensuring that the 'nonce' claim in the ID Token matches the 'nonce' value sent in the authentication request to the OpenID Provider (in OAuth2 refereed to as the authorization request sent to the authorization server).

Réponse de Cybernetics : Oui. Avec Microsoft Entra ID, un nonce aléatoire est envoyé puis comparé à celui du jeton d'identité ; avec Google, aucun jeton d'identité n'est utilisé.

​

10.5.2 · niveau 2 · Vérifier que le client identifie l'utilisateur de manière unique à partir des claims de l'ID Token, généralement le claim 'sub', qui ne peuvent pas être réattribués à d'autres utilisateurs (dans le périmètre d'un fournisseur d'identité).

Verify that the client uniquely identifies the user from ID Token claims, usually the 'sub' claim, which cannot be reassigned to other users (for the scope of an identity provider).

Réponse de Cybernetics : Oui. Après le premier rattachement, fait par l'adresse e-mail vérifiée d'un compte préalablement invité, l'utilisateur est identifié par l'identifiant immuable du fournisseur (compte et organisation), et l'organisation ou le domaine est contrôlé à chaque connexion.

​

10.5.3 · niveau 2 · Vérifier que le client rejette les tentatives d'un serveur d'autorisation malveillant d'usurper l'identité d'un autre serveur d'autorisation via les métadonnées du serveur d'autorisation. Le client doit rejeter les métadonnées du serveur d'autorisation si l'URL d'émetteur qu'elles contiennent ne correspond pas exactement à l'URL d'émetteur préconfigurée attendue par le client.

Verify that the client rejects attempts by a malicious authorization server to impersonate another authorization server through authorization server metadata. The client must reject authorization server metadata if the issuer URL in the authorization server metadata does not exactly match the pre-configured issuer URL expected by the client.

Réponse de Cybernetics : Sans objet. Aucune métadonnée de découverte OIDC n'est consommée dynamiquement : les points de terminaison et l'émetteur attendu sont fixés dans le code.

​

10.5.4 · niveau 2 · Vérifier que le client valide que l'ID Token est destiné à être utilisé par ce client (audience) en contrôlant que le claim 'aud' du jeton est égal à la valeur 'client_id' du client.

Verify that the client validates that the ID Token is intended to be used for that client (audience) by checking that the 'aud' claim from the token is equal to the 'client_id' value for the client.

Réponse de Cybernetics : Oui. La signature du jeton d'identité Microsoft est vérifiée avec les clés publiques de Microsoft, ainsi que son audience et son émetteur.

​

10.5.5 · niveau 2 · Vérifier que, lors de l'utilisation de la déconnexion par canal arrière (back-channel logout) OIDC, la partie utilisatrice atténue le déni de service par déconnexion forcée et la confusion cross-JWT dans le flux de déconnexion. Le client doit vérifier que le jeton de déconnexion est correctement typé avec la valeur 'logout+jwt', contient le claim 'event' avec le nom de membre correct, et ne contient pas de claim 'nonce'. Noter qu'il est également recommandé de prévoir une expiration courte (par ex. 2 minutes).

Verify that, when using OIDC back-channel logout, the relying party mitigates denial of service through forced logout and cross-JWT confusion in the logout flow. The client must verify that the logout token is correctly typed with a value of 'logout+jwt', contains the 'event' claim with the correct member name, and does not contain a 'nonce' claim. Note that it is also recommended to have a short expiration (e.g., 2 minutes).

Réponse de Cybernetics : Sans objet. La déconnexion « back-channel » OIDC n'est pas utilisée.

​

10.6.1 · niveau 2 · Vérifier que l'OpenID Provider n'autorise que les valeurs 'code', 'ciba', 'id_token' ou 'id_token code' pour le mode de réponse. Noter que 'code' est préférable à 'id_token code' (flux OIDC Hybrid), et que 'token' (tout flux Implicit) ne doit pas être utilisé.

Verify that the OpenID Provider only allows values 'code', 'ciba', 'id_token', or 'id_token code' for response mode. Note that 'code' is preferred over 'id_token code' (the OIDC Hybrid flow), and 'token' (any Implicit flow) must not be used.

Réponse de Cybernetics : Sans objet. Cybernetics n'est pas un fournisseur OpenID.

​

10.6.2 · niveau 2 · Vérifier que l'OpenID Provider atténue le déni de service par déconnexion forcée, en obtenant une confirmation explicite de l'utilisateur final ou, le cas échéant, en validant les paramètres de la requête de déconnexion (initiée par la partie utilisatrice), tels que 'id_token_hint'.

Verify that the OpenID Provider mitigates denial of service through forced logout. By obtaining explicit confirmation from the end-user or, if present, validating parameters in the logout request (initiated by the relying party), such as the 'id_token_hint'.

Réponse de Cybernetics : Sans objet. Cybernetics n'est pas un fournisseur OpenID.

​

10.7.1 · niveau 2 · Vérifier que le serveur d'autorisation s'assure que l'utilisateur consent à chaque requête d'autorisation. Si l'identité du client ne peut pas être garantie, le serveur d'autorisation doit toujours demander explicitement le consentement de l'utilisateur.

Verify that the authorization server ensures that the user consents to each authorization request. If the identity of the client cannot be assured, the authorization server must always explicitly prompt the user for consent.

Réponse de Cybernetics : Sans objet. Le consentement est géré par Google et Microsoft.

​

10.7.2 · niveau 2 · Vérifier que, lorsque le serveur d'autorisation demande le consentement de l'utilisateur, il présente des informations suffisantes et claires sur l'objet du consentement. Le cas échéant, cela doit inclure la nature des autorisations demandées (généralement fondée sur le scope, le serveur de ressources, les détails d'autorisation des Rich Authorization Requests (RAR)), l'identité de l'application autorisée et la durée de validité de ces autorisations.

Verify that when the authorization server prompts for user consent, it presents sufficient and clear information about what is being consented to. When applicable, this should include the nature of the requested authorizations (typically based on scope, resource server, Rich Authorization Requests (RAR) authorization details), the identity of the authorized application, and the lifetime of these authorizations.

Réponse de Cybernetics : Sans objet. Le consentement est géré par Google et Microsoft.

​

10.7.3 · niveau 2 · Vérifier que l'utilisateur peut consulter, modifier et révoquer les consentements qu'il a accordés via le serveur d'autorisation.

Verify that the user can review, modify, and revoke consents which the user has granted through the authorization server.

Réponse de Cybernetics : Sans objet. Le consentement se révoque depuis les comptes Google ou Microsoft.

11.1.1 · niveau 2 · Vérifier qu'il existe une politique documentée de gestion des clés cryptographiques et un cycle de vie des clés cryptographiques conforme à une norme de gestion des clés telle que le NIST SP 800-57. Cela doit inclure la garantie que les clés ne sont pas partagées de manière excessive (par exemple, avec plus de deux entités pour les secrets partagés et plus d'une entité pour les clés privées).

Verify that there is a documented policy for management of cryptographic keys and a cryptographic key lifecycle that follows a key management standard such as NIST SP 800-57. This should include ensuring that keys are not overshared (for example, with more than two entities for shared secrets and more than one entity for private keys).

Réponse de Cybernetics : Partiellement. Des procédures de rotation existent pour les secrets d'infrastructure (tous les 12 mois et en cas de compromission) ; aucune politique écrite ne couvre encore le cycle de vie des clés cryptographiques applicatives (création, rotation, révocation, destruction).

​

11.1.2 · niveau 2 · Vérifier qu'un inventaire cryptographique est réalisé, maintenu, régulièrement mis à jour, et qu'il inclut l'ensemble des clés cryptographiques, algorithmes et certificats utilisés par l'application. Il doit également documenter où les clés peuvent et ne peuvent pas être utilisées dans le système, ainsi que les types de données qui peuvent et ne peuvent pas être protégés à l'aide de ces clés.

Verify that a cryptographic inventory is performed, maintained, regularly updated, and includes all cryptographic keys, algorithms, and certificates used by the application. It must also document where keys can and cannot be used in the system, and the types of data that can and cannot be protected using the keys.

Réponse de Cybernetics : Non. Il n'existe pas encore d'inventaire cryptographique (clés, algorithmes, certificats et usages autorisés) ; seul un inventaire des secrets d'infrastructure est tenu.

​

11.2.1 · niveau 2 · Vérifier que des implémentations validées par l'industrie (y compris les bibliothèques et les implémentations à accélération matérielle) sont utilisées pour les opérations cryptographiques.

Verify that industry-validated implementations (including libraries and hardware-accelerated implementations) are used for cryptographic operations.

Réponse de Cybernetics : Oui. Les opérations cryptographiques s'appuient sur des implémentations reconnues : le module crypto de Node.js (OpenSSL), Argon2, la bibliothèque jose et OVHcloud KMS.

​

11.2.2 · niveau 2 · Vérifier que l'application est conçue avec une agilité cryptographique telle que les algorithmes de génération de nombres aléatoires, de chiffrement authentifié, de MAC ou de hachage, les longueurs de clés, les nombres de tours, les chiffrements et les modes peuvent être reconfigurés, mis à niveau ou remplacés à tout moment, afin de se protéger contre les cassages cryptographiques. De même, il doit également être possible de remplacer les clés et les mots de passe et de rechiffrer les données. Cela permettra des migrations sans heurts vers la cryptographie post-quantique (PQC), une fois que des implémentations à haut niveau d'assurance de schémas ou normes PQC approuvés seront largement disponibles.

Verify that the application is designed with crypto agility such that random number, authenticated encryption, MAC, or hashing algorithms, key lengths, rounds, ciphers and modes can be reconfigured, upgraded, or swapped at any time, to protect against cryptographic breaks. Similarly, it must also be possible to replace keys and passwords and re-encrypt data. This will allow for seamless upgrades to post-quantum cryptography (PQC), once high-assurance implementations of approved PQC schemes or standards are widely available.

Réponse de Cybernetics : Partiellement. Le format chiffré indique le moteur utilisé et la clé, et les empreintes de mots de passe sont recalculées à la connexion quand les paramètres changent ; le format n'est pas encore versionné, et les clés applicatives ne peuvent pas tourner sans rechiffrement.

​

11.2.3 · niveau 2 · Vérifier que toutes les primitives cryptographiques offrent un minimum de 128 bits de sécurité, en fonction de l'algorithme, de la taille de clé et de la configuration. Par exemple, une clé ECC de 256 bits fournit environ 128 bits de sécurité, alors que RSA nécessite une clé de 3072 bits pour atteindre 128 bits de sécurité.

Verify that all cryptographic primitives utilize a minimum of 128-bits of security based on the algorithm, key size, and configuration. For example, a 256-bit ECC key provides roughly 128 bits of security where RSA requires a 3072-bit key to achieve 128 bits of security.

Réponse de Cybernetics : Oui. Les primitives offrent au moins 128 bits de sécurité : AES-256, HKDF-SHA256, clés de données de 256 bits et Argon2id.

​

11.3.1 · niveau 1 · Vérifier que les modes de chiffrement par blocs non sécurisés (par ex. ECB) et les schémas de bourrage faibles (par ex. PKCS#1 v1.5) ne sont pas utilisés.

Verify that insecure block modes (e.g., ECB) and weak padding schemes (e.g., PKCS#1 v1.5) are not used.

Réponse de Cybernetics : Oui. Aucun mode ECB ni remplissage PKCS#1 v1.5 n'est utilisé : les données sont chiffrées en AES-GCM, ou en AES-CBC accompagné d'un HMAC.

​

11.3.2 · niveau 1 · Vérifier que seuls des chiffrements et modes approuvés, tels que AES avec GCM, sont utilisés.

Verify that only approved ciphers and modes such as AES with GCM are used.

Réponse de Cybernetics : Partiellement. Les données chiffrées par le KMS utilisent AES-256-GCM ; les autres champs chiffrés (identifiants de connecteurs, adresses e-mail, chiffrement de secours) utilisent AES-256-CBC avec HMAC-SHA256, un mode approuvé dont le remplacement par AES-GCM est planifié.

​

11.3.3 · niveau 2 · Vérifier que les données chiffrées sont protégées contre toute modification non autorisée, de préférence en utilisant une méthode de chiffrement authentifié approuvée, ou en combinant une méthode de chiffrement approuvée avec un algorithme MAC approuvé.

Verify that encrypted data is protected against unauthorized modification preferably by using an approved authenticated encryption method or by combining an approved encryption method with an approved MAC algorithm.

Réponse de Cybernetics : Partiellement. Chaque valeur chiffrée est authentifiée (tag GCM ou HMAC) ; le contexte de chiffrement n'est pas encore lié au chiffré comme donnée authentifiée associée ni comparé à l'enregistrement qui le contient.

​

11.4.1 · niveau 1 · Vérifier que seules des fonctions de hachage approuvées sont utilisées pour les cas d'usage cryptographiques généraux, y compris les signatures numériques, HMAC, KDF et la génération de bits aléatoires. Les fonctions de hachage interdites, telles que MD5, ne doivent être utilisées à aucune fin cryptographique.

Verify that only approved hash functions are used for general cryptographic use cases, including digital signatures, HMAC, KDF, and random bit generation. Disallowed hash functions, such as MD5, must not be used for any cryptographic purpose.

Réponse de Cybernetics : Oui. Les usages cryptographiques reposent sur SHA-256 et HMAC-SHA256 ; SHA-1 ne sert qu'au protocole d'anonymat de Have I Been Pwned, sans rôle de sécurité, et MD5 n'est pas utilisé.

​

11.4.2 · niveau 2 · Vérifier que les mots de passe sont stockés à l'aide d'une fonction de dérivation de clé approuvée et coûteuse en calcul (également appelée « fonction de hachage de mots de passe »), avec des paramètres configurés selon les recommandations actuelles. Ces paramètres doivent équilibrer sécurité et performance afin de rendre les attaques par force brute suffisamment difficiles pour le niveau de sécurité requis.

Verify that passwords are stored using an approved, computationally intensive, key derivation function (also known as a "password hashing function"), with parameter settings configured based on current guidance. The settings should balance security and performance to make brute-force attacks sufficiently challenging for the required level of security.

Réponse de Cybernetics : Oui. Les mots de passe sont stockés avec Argon2id (64 Mio, 3 itérations, sel de 16 octets), au-dessus des recommandations de l'OWASP.

​

11.4.3 · niveau 2 · Vérifier que les fonctions de hachage utilisées dans les signatures numériques, dans le cadre de l'authentification ou de l'intégrité des données, sont résistantes aux collisions et ont des longueurs en bits appropriées. Si la résistance aux collisions est requise, la longueur de sortie doit être d'au moins 256 bits. Si seule la résistance aux attaques par seconde préimage est requise, la longueur de sortie doit être d'au moins 128 bits.

Verify that hash functions used in digital signatures, as part of data authentication or data integrity are collision resistant and have appropriate bit-lengths. If collision resistance is required, the output length must be at least 256 bits. If only resistance to second pre-image attacks is required, the output length must be at least 128 bits.

Réponse de Cybernetics : Oui. L'intégrité et l'authentification des données reposent sur SHA-256 et HMAC-SHA256, avec des sorties de 256 bits.

​

11.4.4 · niveau 2 · Vérifier que l'application utilise des fonctions de dérivation de clé approuvées avec des paramètres d'étirement de clé (key stretching) lors de la dérivation de clés secrètes à partir de mots de passe. Les paramètres utilisés doivent équilibrer sécurité et performance afin d'empêcher les attaques par force brute de compromettre la clé cryptographique résultante.

Verify that the application uses approved key derivation functions with key stretching parameters when deriving secret keys from passwords. The parameters in use must balance security and performance to prevent brute-force attacks from compromising the resulting cryptographic key.

Réponse de Cybernetics : Sans objet. Aucune clé de chiffrement n'est dérivée d'un mot de passe : les clés proviennent du KMS et sont dérivées par HKDF, et les mots de passe sont seulement hachés.

​

11.5.1 · niveau 2 · Vérifier que tous les nombres et chaînes aléatoires destinés à être non devinables doivent être générés à l'aide d'un générateur de nombres pseudo-aléatoires cryptographiquement sûr (CSPRNG) et posséder au moins 128 bits d'entropie. Noter que les UUID ne respectent pas cette condition.

Verify that all random numbers and strings which are intended to be non-guessable must be generated using a cryptographically secure pseudo-random number generator (CSPRNG) and have at least 128 bits of entropy. Note that UUIDs do not respect this condition.

Réponse de Cybernetics : Partiellement. Les jetons, sels, vecteurs d'initialisation et nonces sont produits par un générateur cryptographique, avec 192 à 256 bits d'entropie pour les jetons ; les mots de passe temporaires n'atteignent qu'environ 96 bits, et leur remplacement par des liens d'activation est planifié.

​

11.6.1 · niveau 2 · Vérifier que seuls des algorithmes cryptographiques et modes de fonctionnement approuvés sont utilisés pour la génération et l'initialisation (seeding) des clés, ainsi que pour la génération et la vérification des signatures numériques. Les algorithmes de génération de clés ne doivent pas générer de clés non sécurisées vulnérables à des attaques connues, par exemple des clés RSA vulnérables à la factorisation de Fermat.

Verify that only approved cryptographic algorithms and modes of operation are used for key generation and seeding, and digital signature generation and verification. Key generation algorithms must not generate insecure keys vulnerable to known attacks, for example, RSA keys which are vulnerable to Fermat factorization.

Réponse de Cybernetics : Oui. Les clés de données sont générées par OVHcloud KMS en AES-256, les aléas par le générateur cryptographique du système, et les signatures d'identité sont vérifiées par une bibliothèque reconnue à partir des clés publiées par le fournisseur.

12.1.1 · niveau 1 · Vérifier que seules les dernières versions recommandées du protocole TLS sont activées, telles que TLS 1.2 et TLS 1.3. La dernière version du protocole TLS doit être l'option privilégiée.

Verify that only the latest recommended versions of the TLS protocol are enabled, such as TLS 1.2 and TLS 1.3. The latest version of the TLS protocol must be the preferred option.

Réponse de Cybernetics : Oui. Seuls TLS 1.2 et TLS 1.3 sont acceptés, chez Cloudflare comme à l'origine, et TLS 1.3 est négocié en priorité.

​

12.1.2 · niveau 2 · Vérifier que seules les suites cryptographiques recommandées sont activées, les suites les plus robustes étant définies comme préférées. Les applications de niveau L3 ne doivent prendre en charge que les suites cryptographiques offrant la confidentialité persistante (forward secrecy).

Verify that only recommended cipher suites are enabled, with the strongest cipher suites set as preferred. L3 applications must only support cipher suites which provide forward secrecy.

Réponse de Cybernetics : Partiellement. L'origine n'accepte que des suites modernes à confidentialité persistante (ECDHE avec AES-GCM ou ChaCha20) ; la liste des suites acceptées par Cloudflare n'est pas encore restreinte explicitement.

​

12.1.3 · niveau 2 · Vérifier que l'application valide que les certificats clients mTLS sont de confiance avant d'utiliser l'identité du certificat pour l'authentification ou l'autorisation.

Verify that the application validates that mTLS client certificates are trusted before using the certificate identity for authentication or authorization.

Réponse de Cybernetics : Oui. Le TLS mutuel réserve l'origine à Cloudflare : le certificat client est vérifié à l'établissement de la connexion, et toute connexion sans certificat valide est refusée.

​

12.2.1 · niveau 1 · Vérifier que TLS est utilisé pour toute connectivité entre un client et les services HTTP exposés à l'extérieur, et qu'aucun repli vers des communications non sécurisées ou non chiffrées n'a lieu.

Verify that TLS is used for all connectivity between a client and external facing, HTTP-based services, and does not fall back to insecure or unencrypted communications.

Réponse de Cybernetics : Oui. Tous les services exposés sont servis uniquement en HTTPS, avec redirection systématique et HSTS d'un an, sous-domaines inclus, préchargé dans les navigateurs.

​

12.2.2 · niveau 1 · Vérifier que les services exposés à l'extérieur utilisent des certificats TLS reconnus publiquement.

Verify that external facing services use publicly trusted TLS certificates.

Réponse de Cybernetics : Oui. Les certificats publics sont émis par des autorités reconnues : certificats Cloudflare en périphérie et Let's Encrypt renouvelés automatiquement à l'origine.

​

12.3.1 · niveau 2 · Vérifier qu'un protocole chiffré tel que TLS est utilisé pour toutes les connexions entrantes et sortantes vers et depuis l'application, y compris les systèmes de supervision, les outils d'administration, l'accès distant et SSH, les middlewares, les bases de données, les mainframes, les systèmes partenaires ou les API externes. Le serveur ne doit pas se replier vers des protocoles non sécurisés ou non chiffrés.

Verify that an encrypted protocol such as TLS is used for all inbound and outbound connections to and from the application, including monitoring systems, management tools, remote access and SSH, middleware, databases, mainframes, partner systems, or external APIs. The server must not fall back to insecure or unencrypted protocols.

Réponse de Cybernetics : Partiellement. Les connexions à la base de données, aux API externes et aux services de messagerie sont chiffrées, et les URL de connecteurs saisies par les clients doivent être en HTTPS ; certains flux internes au cluster (relais du proxy vers les applications, supervision) circulent encore sans chiffrement sur le réseau privé.

​

12.3.2 · niveau 2 · Vérifier que les clients TLS valident les certificats reçus avant de communiquer avec un serveur TLS.

Verify that TLS clients validate certificates received before communicating with a TLS server.

Réponse de Cybernetics : Partiellement. Les clients TLS vérifient les certificats serveur, notamment pour la base de données ; deux connecteurs font encore exception, et leur correction est planifiée.

​

12.3.3 · niveau 2 · Vérifier que TLS ou un autre mécanisme approprié de chiffrement du transport est utilisé pour toute connectivité entre les services HTTP internes de l'application, et qu'aucun repli vers des communications non sécurisées ou non chiffrées n'a lieu.

Verify that TLS or another appropriate transport encryption mechanism used for all connectivity between internal, HTTP-based services within the application, and does not fall back to insecure or unencrypted communications.

Réponse de Cybernetics : Partiellement. Les échanges entre l'interface et l'API passent en HTTPS ; à l'intérieur du cluster, le TLS s'arrête au proxy d'entrée et le trafic vers les applications circule sur le réseau privé, protégé par des politiques réseau.

​

12.3.4 · niveau 2 · Vérifier que les connexions TLS entre services internes utilisent des certificats de confiance. Lorsque des certificats générés en interne ou auto-signés sont utilisés, le service consommateur doit être configuré pour ne faire confiance qu'à des AC internes spécifiques et à des certificats auto-signés spécifiques.

Verify that TLS connections between internal services use trusted certificates. Where internally generated or self-signed certificates are used, the consuming service must be configured to only trust specific internal CAs and specific self-signed certificates.

Réponse de Cybernetics : Partiellement. Là où le TLS est utilisé en interne (base de données), seule une autorité précise est approuvée ; les flux internes non chiffrés n'utilisent pas de certificats.

13.1.1 · niveau 2 · Vérifier que tous les besoins de communication de l'application sont documentés. Cela doit inclure les services externes dont dépend l'application ainsi que les cas où un utilisateur final pourrait fournir un emplacement externe auquel l'application se connectera ensuite.

Verify that all communication needs for the application are documented. This must include external services which the application relies upon and cases where an end user might be able to provide an external location to which the application will then connect.

Réponse de Cybernetics : Partiellement. Les flux réseau entrants et sortants sont documentés par composant, avec la liste des services tiers autorisés ; il n'existe pas encore d'inventaire applicatif unique des communications externes, y compris celles vers des adresses fournies par les clients.

​

13.2.1 · niveau 2 · Vérifier que les communications entre les composants backend de l'application qui ne prennent pas en charge le mécanisme standard de session utilisateur de l'application, y compris les API, les middlewares et les couches de données, sont authentifiées. L'authentification doit utiliser des comptes de service individuels, des jetons à courte durée de vie ou une authentification par certificat, et non des identifiants immuables tels que des mots de passe, des clés d'API ou des comptes partagés à accès privilégié.

Verify that communications between backend application components that don't support the application's standard user session mechanism, including APIs, middleware, and data layers, are authenticated. Authentication must use individual service accounts, short-term tokens, or certificate-based authentication and not unchanging credentials such as passwords, API keys, or shared accounts with privileged access.

Réponse de Cybernetics : Partiellement. Les échanges avec les bases de données se font en TLS vérifié avec des comptes dédiés, et le KMS est joint en TLS mutuel ; un même compte de base sert encore à tous les usages, et un même certificat d'accès au KMS est partagé entre tous les clients.

​

13.2.2 · niveau 2 · Vérifier que les communications entre les composants backend de l'application, y compris les services locaux ou du système d'exploitation, les API, les middlewares et les couches de données, sont effectuées avec des comptes disposant des privilèges minimaux nécessaires.

Verify that communications between backend application components, including local or operating system services, APIs, middleware, and data layers, are performed with accounts assigned the least necessary privileges.

Réponse de Cybernetics : Partiellement. Les pods n'ont pas de jeton Kubernetes monté et le réseau interne refuse tout flux par défaut ; le compte applicatif de la base dispose encore de droits sur le schéma et sur le journal d'audit, et l'agent installé sur les postes s'exécute avec des privilèges élevés.

​

13.2.3 · niveau 2 · Vérifier que, si un identifiant doit être utilisé pour l'authentification d'un service, l'identifiant utilisé par le consommateur n'est pas un identifiant par défaut (par ex. root/root ou admin/admin).

Verify that if a credential has to be used for service authentication, the credential being used by the consumer is not a default credential (e.g., root/root or admin/admin).

Réponse de Cybernetics : Oui. Aucun identifiant par défaut n'est utilisé : les mots de passe des bases sont générés par l'hébergeur, et les autres secrets sont injectés depuis le coffre, sans valeur de repli dans le code.

​

13.2.4 · niveau 2 · Vérifier qu'une liste d'autorisation est utilisée pour définir les ressources ou systèmes externes avec lesquels l'application est autorisée à communiquer (par ex. pour les requêtes sortantes, les chargements de données ou l'accès aux fichiers). Cette liste d'autorisation peut être mise en œuvre au niveau de la couche applicative, du serveur web, du pare-feu ou d'une combinaison de différentes couches.

Verify that an allowlist is used to define the external resources or systems with which the application is permitted to communicate (e.g., for outbound requests, data loads, or file access). This allowlist can be implemented at the application layer, web server, firewall, or a combination of different layers.

Réponse de Cybernetics : Partiellement. Les connexions sortantes sont limitées à une liste de plages d'adresses, et les adresses fournies par les clients sont filtrées contre les réseaux internes ; cette liste reste encore large pour certains fournisseurs d'hébergement.

​

13.2.5 · niveau 2 · Vérifier que le serveur web ou d'application est configuré avec une liste d'autorisation des ressources ou systèmes vers lesquels le serveur peut envoyer des requêtes ou depuis lesquels il peut charger des données ou des fichiers.

Verify that the web or application server is configured with an allowlist of resources or systems to which the server can send requests or load data or files from.

Réponse de Cybernetics : Partiellement. Une liste d'autorisation des flux sortants par adresses IP s'applique au niveau du réseau du cluster ; il n'existe pas encore de liste de noms d'hôtes autorisés dans l'application.

​

13.3.1 · niveau 2 · Vérifier qu'une solution de gestion des secrets, telle qu'un coffre de clés, est utilisée pour créer, stocker, contrôler l'accès et détruire de manière sécurisée les secrets du backend. Ceux-ci peuvent inclure des mots de passe, du matériel de clé, des intégrations avec des bases de données et des systèmes tiers, des clés et graines pour les jetons basés sur le temps, d'autres secrets internes et des clés d'API. Les secrets ne doivent pas être inclus dans le code source de l'application ni dans les artefacts de build. Pour une application de niveau L3, cela doit impliquer une solution à support matériel telle qu'un HSM.

Verify that a secrets management solution, such as a key vault, is used to securely create, store, control access to, and destroy backend secrets. These could include passwords, key material, integrations with databases and third-party systems, keys and seeds for time-based tokens, other internal secrets, and API keys. Secrets must not be included in application source code or included in build artifacts. For an L3 application, this must involve a hardware-backed solution such as an HSM.

Réponse de Cybernetics : Partiellement. Les secrets de la plateforme sont conservés dans OVHcloud KMS et distribués par External Secrets, avec des règles qui refusent tout secret créé hors de ce circuit ; certains secrets sont encore stockés chiffrés en base, et des secrets de construction doivent être retirés des pipelines.

​

13.3.2 · niveau 2 · Vérifier que l'accès aux actifs secrets respecte le principe du moindre privilège.

Verify that access to secret assets adheres to the principle of least privilege.

Réponse de Cybernetics : Partiellement. Chaque espace de noms n'accède qu'à ses propres secrets, avec des droits en lecture seule ; le certificat d'accès au KMS de l'application est encore commun à tous les clients.

​

13.4.1 · niveau 1 · Vérifier que l'application est déployée soit sans aucune métadonnée de gestion de versions, y compris les dossiers .git ou .svn, soit de telle manière que ces dossiers soient inaccessibles à la fois depuis l'extérieur et pour l'application elle-même.

Verify that the application is deployed either without any source control metadata, including the .git or .svn folders, or in a way that these folders are inaccessible both externally and to the application itself.

Réponse de Cybernetics : Oui. Les images de production ne contiennent que le code construit, sans métadonnées de gestion de sources.

​

13.4.2 · niveau 2 · Vérifier que les modes de débogage sont désactivés pour tous les composants dans les environnements de production afin d'empêcher l'exposition de fonctionnalités de débogage et la fuite d'informations.

Verify that debug modes are disabled for all components in production environments to prevent exposure of debugging features and information leakage.

Réponse de Cybernetics : Oui. Le mode débogage est désactivé en production pour l'API et l'interface, et les outils de développement ne sont pas embarqués.

​

13.4.3 · niveau 2 · Vérifier que les serveurs web n'exposent pas de listing de répertoires aux clients, sauf si cela est explicitement voulu.

Verify that web servers do not expose directory listings to clients unless explicitly intended.

Réponse de Cybernetics : Oui. Aucun listage de répertoires n'est exposé, et les fichiers cachés sont ignorés par le serveur de fichiers statiques.

​

13.4.4 · niveau 2 · Vérifier que l'utilisation de la méthode HTTP TRACE n'est pas prise en charge dans les environnements de production, afin d'éviter toute fuite potentielle d'informations.

Verify that using the HTTP TRACE method is not supported in production environments, to avoid potential information leakage.

Réponse de Cybernetics : Partiellement. La méthode TRACE est bloquée chez Cloudflare pour l'API ; les autres domaines ne sont pas encore couverts explicitement.

​

13.4.5 · niveau 2 · Vérifier que la documentation (par exemple celle des API internes) et les points de terminaison de supervision ne sont pas exposés, sauf si cela est explicitement voulu.

Verify that documentation (such as for internal APIs) and monitoring endpoints are not exposed unless explicitly intended.

Réponse de Cybernetics : Oui. Aucune documentation d'API n'est publiée en production ; seul un point de contrôle de santé minimal est exposé, et le tableau de bord du proxy n'est accessible qu'en interne, avec authentification.

14.1.1 · niveau 2 · Vérifier que toutes les données sensibles créées et traitées par l'application ont été identifiées et classifiées en niveaux de protection. Cela inclut les données qui sont seulement encodées et donc facilement décodables, telles que les chaînes Base64 ou la charge utile en clair d'un JWT. Les niveaux de protection doivent tenir compte de toute réglementation et norme en matière de protection des données et de vie privée auxquelles l'application doit se conformer.

Verify that all sensitive data created and processed by the application has been identified and classified into protection levels. This includes data that is only encoded and therefore easily decoded, such as Base64 strings or the plaintext payload inside a JWT. Protection levels need to take into account any data protection and privacy regulations and standards which the application is required to comply with.

Réponse de Cybernetics : Partiellement. Les champs d'identité sensibles sont identifiés et chiffrés dans le code, mais il n'existe pas encore de classification documentée des données par niveau de protection.

​

14.1.2 · niveau 2 · Vérifier que tous les niveaux de protection des données sensibles disposent d'un ensemble documenté d'exigences de protection. Cela doit inclure (sans s'y limiter) des exigences relatives au chiffrement général, à la vérification de l'intégrité, à la conservation, à la manière dont les données doivent être journalisées, aux contrôles d'accès aux données sensibles dans les journaux, au chiffrement au niveau de la base de données, à la vie privée et aux technologies de renforcement de la vie privée à utiliser, ainsi qu'aux autres exigences de confidentialité.

Verify that all sensitive data protection levels have a documented set of protection requirements. This must include (but not be limited to) requirements related to general encryption, integrity verification, retention, how the data is to be logged, access controls around sensitive data in logs, database-level encryption, privacy and privacy-enhancing technologies to be used, and other confidentiality requirements.

Réponse de Cybernetics : Partiellement. Seule la rétention des journaux est documentée ; les exigences de protection par niveau de sensibilité (chiffrement, intégrité, journalisation, accès) restent à formaliser.

​

14.2.1 · niveau 1 · Vérifier que les données sensibles ne sont envoyées au serveur que dans le corps du message HTTP ou dans les champs d'en-tête, et que l'URL et la chaîne de requête ne contiennent pas d'informations sensibles, telles qu'une clé d'API ou un jeton de session.

Verify that sensitive data is only sent to the server in the HTTP message body or header fields, and that the URL and query string do not contain sensitive information, such as an API key or session token.

Réponse de Cybernetics : Partiellement. Les jetons de session passent dans des cookies ou des en-têtes ; certaines requêtes transmettent encore une adresse e-mail ou un jeton d'invitation dans l'URL.

​

14.2.2 · niveau 2 · Vérifier que l'application empêche la mise en cache des données sensibles dans les composants serveur, tels que les répartiteurs de charge et les caches applicatifs, ou s'assure que les données sont purgées de manière sécurisée après utilisation.

Verify that the application prevents sensitive data from being cached in server components, such as load balancers and application caches, or ensures that the data is securely purged after use.

Réponse de Cybernetics : Partiellement. Aucune règle de cache n'est appliquée à l'API chez Cloudflare, mais les réponses ne portent pas encore d'en-tête anti-cache, et des clés de données déchiffrées restent environ une minute en mémoire.

​

14.2.3 · niveau 2 · Vérifier que les données sensibles définies ne sont pas envoyées à des tiers non fiables (par ex. des traceurs d'utilisateurs) afin d'empêcher toute collecte de données non désirée hors du contrôle de l'application.

Verify that defined sensitive data is not sent to untrusted parties (e.g., user trackers) to prevent unwanted collection of data outside of the application's control.

Réponse de Cybernetics : Partiellement. Aucun traceur publicitaire n'est intégré ; l'outil de support reçoit le nom, l'adresse e-mail et l'identifiant de l'entreprise de l'utilisateur, avec vérification d'identité, sans que cet envoi soit encore encadré par une classification documentée.

​

14.2.4 · niveau 2 · Vérifier que les contrôles relatifs aux données sensibles concernant le chiffrement, la vérification de l'intégrité, la conservation, la manière dont les données doivent être journalisées, les contrôles d'accès aux données sensibles dans les journaux, la vie privée et les technologies de renforcement de la vie privée, sont mis en œuvre tels que définis dans la documentation pour le niveau de protection des données concernées.

Verify that controls around sensitive data related to encryption, integrity verification, retention, how the data is to be logged, access controls around sensitive data in logs, privacy and privacy-enhancing technologies, are implemented as defined in the documentation for the specific data's protection level.

Réponse de Cybernetics : Partiellement. Plusieurs contrôles sont en place (chiffrement par entreprise, masquage des secrets dans les journaux, purges planifiées), mais ils ne s'appuient pas encore sur une politique écrite, et les données des entreprises supprimées restent dans les sauvegardes.

​

14.3.1 · niveau 1 · Vérifier que les données authentifiées sont effacées du stockage client, tel que le DOM du navigateur, après la terminaison du client ou de la session. Le champ d'en-tête de réponse HTTP 'Clear-Site-Data' peut y contribuer, mais le côté client doit également être capable de procéder à ce nettoyage si la connexion au serveur n'est pas disponible au moment de la terminaison de la session.

Verify that authenticated data is cleared from client storage, such as the browser DOM, after the client or session is terminated. The 'Clear-Site-Data' HTTP response header field may be able to help with this but the client-side should also be able to clear up if the server connection is not available when the session is terminated.

Réponse de Cybernetics : Oui. À la déconnexion, le cookie de session est supprimé, l'état de l'application est réinitialisé, le module de support est arrêté et la déconnexion est propagée aux autres onglets.

​

14.3.2 · niveau 2 · Vérifier que l'application définit des champs d'en-tête de réponse HTTP anti-cache suffisants (c'est-à-dire Cache-Control: no-store) afin que les données sensibles ne soient pas mises en cache dans les navigateurs.

Verify that the application sets sufficient anti-caching HTTP response header fields (i.e., Cache-Control: no-store) so that sensitive data is not cached in browsers.

Réponse de Cybernetics : Non. L'en-tête Cache-Control: no-store n'est posé que sur une seule réponse de l'API, et aucune règle ne couvre encore les pages authentifiées.

​

14.3.3 · niveau 2 · Vérifier que les données conservées dans le stockage du navigateur (telles que localStorage, sessionStorage, IndexedDB ou les cookies) ne contiennent pas de données sensibles, à l'exception des jetons de session.

Verify that data stored in browser storage (such as localStorage, sessionStorage, IndexedDB, or cookies) does not contain sensitive data, with the exception of session tokens.

Réponse de Cybernetics : Oui. Le jeton de session est conservé dans un cookie HttpOnly, et le stockage local ne contient que des préférences d'affichage ; l'adresse e-mail n'est conservée que brièvement pendant l'étape de double authentification.

15.1.1 · niveau 1 · Vérifier que la documentation de l'application définit des délais de remédiation fondés sur le risque pour les versions de composants tiers présentant des vulnérabilités et pour la mise à jour des bibliothèques en général, afin de minimiser le risque lié à ces composants.

Verify that application documentation defines risk based remediation time frames for 3rd party component versions with vulnerabilities and for updating libraries in general, to minimize the risk from these components.

Réponse de Cybernetics : Partiellement. Une procédure fixe les délais de correction des vulnérabilités selon leur gravité (critique : 7 jours, haute : 30 jours, moyenne : 90 jours) ; la cadence de mise à jour générale des bibliothèques n'est pas encore formalisée.

​

15.1.2 · niveau 2 · Vérifier qu'un catalogue d'inventaire, tel qu'une nomenclature logicielle (SBOM), est maintenu pour toutes les bibliothèques tierces utilisées, y compris la vérification que les composants proviennent de dépôts prédéfinis, de confiance et maintenus en continu.

Verify that an inventory catalog, such as software bill of materials (SBOM), is maintained of all third-party libraries in use, including verifying that components come from pre-defined, trusted, and continually maintained repositories.

Réponse de Cybernetics : Oui. Un inventaire logiciel (SBOM) des images et des hôtes est produit en continu, avec analyse de composition des dépendances ; les versions sont figées par fichiers de verrouillage et proviennent de registres identifiés.

​

15.1.3 · niveau 2 · Vérifier que la documentation de l'application identifie les fonctionnalités chronophages ou gourmandes en ressources. Cela doit inclure la manière de prévenir une perte de disponibilité due à la surutilisation de ces fonctionnalités et la manière d'éviter une situation où la construction d'une réponse prend plus de temps que le délai d'attente du consommateur. Les défenses possibles incluent le traitement asynchrone, l'utilisation de files d'attente et la limitation des traitements parallèles par utilisateur et par application.

Verify that the application documentation identifies functionality which is time-consuming or resource-demanding. This must include how to prevent a loss of availability due to overusing this functionality and how to avoid a situation where building a response takes longer than the consumer's timeout. Potential defenses may include asynchronous processing, using queues, and limiting parallel processes per user and per application.

Réponse de Cybernetics : Non. Aucune documentation n'identifie encore les fonctionnalités coûteuses en ressources ni la stratégie pour préserver la disponibilité.

​

15.2.1 · niveau 1 · Vérifier que l'application ne contient que des composants n'ayant pas dépassé les délais documentés de mise à jour et de remédiation.

Verify that the application only contains components which have not breached the documented update and remediation time frames.

Réponse de Cybernetics : Partiellement. Les outils de détection (analyse des dépendances, Dependabot, analyse des images) et les délais de correction sont en place ; le respect de ces délais n'est pas encore suivi par un indicateur publié.

​

15.2.2 · niveau 2 · Vérifier que l'application a mis en œuvre des défenses contre la perte de disponibilité due à des fonctionnalités chronophages ou gourmandes en ressources, sur la base des décisions et stratégies de sécurité documentées à ce sujet.

Verify that the application has implemented defenses against loss of availability due to functionality which is time-consuming or resource-demanding, based on the documented security decisions and strategies for this.

Réponse de Cybernetics : Partiellement. Des limites de débit, des quotas, des tailles maximales de requête et des délais d'attente sortants protègent la disponibilité ; les synchronisations lourdes s'exécutent encore dans la requête, sans file d'attente, et la stratégie n'est pas documentée.

​

15.2.3 · niveau 2 · Vérifier que l'environnement de production n'inclut que les fonctionnalités nécessaires au fonctionnement de l'application, et n'expose pas de fonctionnalités superflues telles que du code de test, des extraits d'exemple et des fonctionnalités de développement.

Verify that the production environment only includes functionality that is required for the application to function, and does not expose extraneous functionality such as test code, sample snippets, and development functionality.

Réponse de Cybernetics : Partiellement. Les routes de test ne sont actives qu'en environnement de test et les dépendances de développement sont exclues de l'image ; quelques outils de développement et le code de test sont encore embarqués dans l'image de l'API.

​

15.3.1 · niveau 1 · Vérifier que l'application ne renvoie que le sous-ensemble requis de champs d'un objet de données. Par exemple, elle ne doit pas renvoyer un objet de données entier, certains champs individuels ne devant pas être accessibles aux utilisateurs.

Verify that the application only returns the required subset of fields from a data object. For example, it should not return an entire data object, as some individual fields should not be accessible to users.

Réponse de Cybernetics : Partiellement. Les champs sensibles sont exclus des réponses par une liste d'exclusion ; la plupart des réponses renvoient encore l'objet complet plutôt qu'une liste explicite de champs autorisés.

​

15.3.2 · niveau 2 · Vérifier que, lorsque le backend de l'application effectue des appels vers des URL externes, il est configuré pour ne pas suivre les redirections, sauf si cela fait partie de la fonctionnalité prévue.

Verify that where the application backend makes calls to external URLs, it is configured to not follow redirects unless it is intended functionality.

Réponse de Cybernetics : Partiellement. Le client HTTP commun des connecteurs refuse les redirections et bloque les adresses internes ; certaines bibliothèques tierces conservent leur comportement par défaut.

​

15.3.3 · niveau 2 · Vérifier que l'application dispose de contre-mesures contre les attaques par affectation de masse (mass assignment) en limitant les champs autorisés par contrôleur et par action, de sorte qu'il ne soit par exemple pas possible d'insérer ou de mettre à jour la valeur d'un champ qui n'était pas censé faire partie de cette action.

Verify that the application has countermeasures to protect against mass assignment attacks by limiting allowed fields per controller and action, e.g., it is not possible to insert or update a field value when it was not intended to be part of that action.

Réponse de Cybernetics : Partiellement. Les entrées passent par des validateurs qui écartent les champs inconnus ; certaines mises à jour acceptent encore des champs qui ne devraient pas être modifiables par l'appelant.

​

15.3.4 · niveau 2 · Vérifier que tous les composants de proxy et middlewares transmettent correctement l'adresse IP d'origine de l'utilisateur à l'aide de champs de données de confiance ne pouvant pas être manipulés par l'utilisateur final, et que l'application et le serveur web utilisent cette valeur correcte pour la journalisation et les décisions de sécurité telles que la limitation de débit, en tenant compte du fait que même l'adresse IP d'origine peut ne pas être fiable en raison des IP dynamiques, des VPN ou des pare-feu d'entreprise.

Verify that all proxying and middleware components transfer the user's original IP address correctly using trusted data fields that cannot be manipulated by the end user, and the application and web server use this correct value for logging and security decisions such as rate limiting, taking into account that even the original IP address may not be reliable due to dynamic IPs, VPNs, or corporate firewalls.

Réponse de Cybernetics : Oui. Seuls les en-têtes de transfert provenant du réseau interne et des plages du fournisseur de périphérie sont pris en compte ; l'adresse IP ainsi obtenue sert aux journaux de connexion et aux limites de débit.

​

15.3.5 · niveau 2 · Vérifier que l'application s'assure explicitement que les variables sont du type correct et effectue des opérations d'égalité et de comparaison strictes. L'objectif est d'éviter les vulnérabilités de jonglage de types (type juggling) ou de confusion de types causées par une hypothèse du code de l'application sur le type d'une variable.

Verify that the application explicitly ensures that variables are of the correct type and performs strict equality and comparator operations. This is to avoid type juggling or type confusion vulnerabilities caused by the application code making an assumption about a variable type.

Réponse de Cybernetics : Partiellement. Les entrées sont typées par la validation et les comparaisons strictes dominent ; le mode strict de TypeScript n'est pas encore totalement activé.

​

15.3.6 · niveau 2 · Vérifier que le code JavaScript est écrit de manière à empêcher la pollution de prototype, par exemple en utilisant Set() ou Map() au lieu de littéraux d'objets.

Verify that JavaScript code is written in a way that prevents prototype pollution, for example, by using Set() or Map() instead of object literals.

Réponse de Cybernetics : Partiellement. Le framework neutralise les clés dangereuses lors de l'analyse du JSON et des formulaires ; le code applicatif n'applique pas encore de règle systématique pour les dictionnaires construits dynamiquement.

​

15.3.7 · niveau 2 · Vérifier que l'application dispose de défenses contre les attaques par pollution de paramètres HTTP, en particulier si le framework applicatif ne fait aucune distinction quant à la source des paramètres de requête (chaîne de requête, paramètres du corps, cookies ou champs d'en-tête).

Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters (query string, body parameters, cookies, or header fields).

Réponse de Cybernetics : Partiellement. Le typage strict des validateurs rejette les paramètres dupliqués ; la validation fusionne toutefois les paramètres d'URL et le corps de la requête sans distinguer leur origine.

16.1.1 · niveau 2 · Vérifier qu'il existe un inventaire documentant la journalisation effectuée à chaque couche de la pile technologique de l'application, les événements journalisés, les formats de journaux, l'emplacement de stockage des journaux, leur utilisation, la manière dont leur accès est contrôlé et leur durée de conservation.

Verify that an inventory exists documenting the logging performed at each layer of the application's technology stack, what events are being logged, log formats, where that logging is stored, how it is used, how access to it is controlled, and for how long logs are kept.

Réponse de Cybernetics : Partiellement. Une procédure recense les sources de journaux, leurs finalités, leurs durées de conservation et leurs accès ; elle ne détaille pas encore les événements par couche, les formats ni les journaux locaux de l'agent.

​

16.2.1 · niveau 2 · Vérifier que chaque entrée de journal inclut les métadonnées nécessaires (telles que quand, où, qui, quoi) permettant une investigation détaillée de la chronologie lorsqu'un événement se produit.

Verify that each log entry includes necessary metadata (such as when, where, who, what) that would allow for a detailed investigation of the timeline when an event happens.

Réponse de Cybernetics : Partiellement. Les journaux applicatifs portent l'horodatage, le niveau, l'hôte et des identifiants de trace corrélés ; le journal d'audit des modifications n'enregistre pas encore l'auteur, la requête ni la source de chaque action.

​

16.2.2 · niveau 2 · Vérifier que les sources de temps de tous les composants de journalisation sont synchronisées, et que les horodatages des métadonnées d'événements de sécurité utilisent l'UTC ou incluent un décalage de fuseau horaire explicite. L'UTC est recommandé pour garantir la cohérence entre systèmes distribués et éviter toute confusion lors des changements d'heure d'été.

Verify that time sources for all logging components are synchronized, and that timestamps in security event metadata use UTC or include an explicit time zone offset. UTC is recommended to ensure consistency across distributed systems and to prevent confusion during daylight saving time transitions.

Réponse de Cybernetics : Partiellement. Les horloges sont synchronisées par NTP et les journaux du serveur utilisent des horodatages sans ambiguïté de fuseau ; les journaux locaux de l'agent n'indiquent pas encore explicitement le fuseau.

​

16.2.3 · niveau 2 · Vérifier que l'application ne stocke ou ne diffuse les journaux que vers les fichiers et services documentés dans l'inventaire de journalisation.

Verify that the application only stores or broadcasts logs to the files and services that are documented in the log inventory.

Réponse de Cybernetics : Partiellement. Les journaux du serveur sont envoyés vers la plateforme d'observabilité et vers la base de journalisation ; les fichiers journaux écrits sur les postes par l'agent ne figurent pas encore dans l'inventaire.

​

16.2.4 · niveau 2 · Vérifier que les journaux peuvent être lus et corrélés par le processeur de journaux en usage, de préférence en utilisant un format de journalisation commun.

Verify that logs can be read and correlated by the log processor that is in use, preferably by using a common logging format.

Réponse de Cybernetics : Oui. Les journaux applicatifs sont émis en JSON structuré, corrélés aux traces et exploités par la plateforme d'observabilité.

​

16.2.5 · niveau 2 · Vérifier que, lors de la journalisation de données sensibles, l'application applique une journalisation fondée sur le niveau de protection des données. Par exemple, il peut être interdit de journaliser certaines données, telles que des identifiants ou des informations de paiement. D'autres données, telles que les jetons de session, ne peuvent être journalisées que sous forme hachée ou masquée, intégralement ou partiellement.

Verify that when logging sensitive data, the application enforces logging based on the data's protection level. For example, it may not be allowed to log certain data, such as credentials or payment details. Other data, such as session tokens, may only be logged by being hashed or masked, either in full or partially.

Réponse de Cybernetics : Partiellement. Le serveur masque les secrets, jetons, cookies et adresses e-mail dans ses journaux ; l'agent peut encore écrire sur le poste, sans masquage, le contenu d'une requête en échec, et sa correction est planifiée.

​

16.3.1 · niveau 2 · Vérifier que toutes les opérations d'authentification sont journalisées, y compris les tentatives réussies et échouées. Des métadonnées supplémentaires, telles que le type d'authentification ou les facteurs utilisés, doivent également être collectées.

Verify that all authentication operations are logged, including successful and unsuccessful attempts. Additional metadata, such as the type of authentication or factors used, should also be collected.

Réponse de Cybernetics : Partiellement. Les connexions réussies et échouées sont journalisées avec leur type et l'adresse IP ; les connexions par passkey sont enregistrées mais pas encore affichées dans les journaux de l'entreprise, et les jetons refusés ainsi que les échecs de réauthentification ne sont pas encore journalisés.

​

16.3.2 · niveau 2 · Vérifier que les tentatives d'autorisation échouées sont journalisées. Pour le niveau L3, cela doit inclure la journalisation de toutes les décisions d'autorisation, y compris lorsque des données sensibles sont accédées (sans journaliser les données sensibles elles-mêmes).

Verify that failed authorization attempts are logged. For L3, this must include logging all authorization decisions, including logging when sensitive data is accessed (without logging the sensitive data itself).

Réponse de Cybernetics : Partiellement. Les refus d'autorisation sont journalisés techniquement, mais pas encore dans un journal de sécurité qui porte l'identité de l'utilisateur.

​

16.3.3 · niveau 2 · Vérifier que l'application journalise les événements de sécurité définis dans la documentation, ainsi que les tentatives de contournement des contrôles de sécurité, tels que la validation des entrées, la logique métier et l'anti-automatisation.

Verify that the application logs the security events that are defined in the documentation and also logs attempts to bypass the security controls, such as input validation, business logic, and anti-automation.

Réponse de Cybernetics : Partiellement. Les dépassements de limite de débit et les modifications de données sont tracés ; il n'existe pas encore de liste documentée des événements de sécurité, et les rejets de validation ne sont pas journalisés.

​

16.3.4 · niveau 2 · Vérifier que l'application journalise les erreurs inattendues et les défaillances des contrôles de sécurité, telles que les échecs TLS côté backend.

Verify that the application logs unexpected errors and security control failures such as backend TLS failures.

Réponse de Cybernetics : Partiellement. Les erreurs inattendues, les erreurs cryptographiques et les échecs de connecteurs sont journalisés ; certains échecs TLS ne peuvent pas être détectés tant que deux connecteurs ne vérifient pas les certificats.

​

16.4.1 · niveau 2 · Vérifier que tous les composants de journalisation encodent correctement les données afin d'empêcher l'injection dans les journaux.

Verify that all logging components appropriately encode data to prevent log injection.

Réponse de Cybernetics : Partiellement. Le serveur sérialise ses journaux en JSON, ce qui empêche l'injection de lignes ; l'agent écrit encore ses journaux locaux en texte brut, sans encodage des messages.

​

16.4.2 · niveau 2 · Vérifier que les journaux sont protégés contre les accès non autorisés et ne peuvent pas être modifiés.

Verify that logs are protected from unauthorized access and cannot be modified.

Réponse de Cybernetics : Partiellement. L'accès aux journaux est réservé aux administrateurs authentifiés ; la base de journalisation reste modifiable par l'application et aucune intégrité cryptographique ne protège encore les entrées.

​

16.4.3 · niveau 2 · Vérifier que les journaux sont transmis de manière sécurisée vers un système logiquement séparé pour l'analyse, la détection, l'alerte et l'escalade. L'objectif est de garantir que, si l'application est compromise, les journaux ne le sont pas.

Verify that logs are securely transmitted to a logically separate system for analysis, detection, alerting, and escalation. The aim is to ensure that if the application is breached, the logs are not compromised.

Réponse de Cybernetics : Partiellement. Les journaux applicatifs sont envoyés vers une plateforme d'observabilité distincte ; les journaux de sécurité métier (audit, connexions) restent dans une base accessible par l'application.

​

16.5.1 · niveau 2 · Vérifier qu'un message générique est renvoyé au consommateur lorsqu'une erreur inattendue ou sensible sur le plan de la sécurité se produit, garantissant qu'aucune donnée interne sensible du système, telle que des traces de pile, des requêtes, des clés secrètes ou des jetons, n'est exposée.

Verify that a generic message is returned to the consumer when an unexpected or security-sensitive error occurs, ensuring no exposure of sensitive internal system data such as stack traces, queries, secret keys, and tokens.

Réponse de Cybernetics : Partiellement. En production, les erreurs internes ne renvoient pas de trace de pile ; certaines exceptions peuvent encore exposer leur message technique, et leur correction est planifiée.

​

16.5.2 · niveau 2 · Vérifier que l'application continue de fonctionner de manière sécurisée lorsque l'accès à une ressource externe échoue, par exemple en utilisant des modèles tels que les disjoncteurs (circuit breakers) ou la dégradation progressive.

Verify that the application continues to operate securely when external resource access fails, for example, by using patterns such as circuit breakers or graceful degradation.

Réponse de Cybernetics : Partiellement. Les appels vers les services externes ont des délais d'attente, un nombre limité de tentatives et une isolation des erreurs par connecteur ; il n'existe pas encore de disjoncteur ni de stratégie de fonctionnement dégradé documentée.

​

16.5.3 · niveau 2 · Vérifier que l'application échoue de manière contrôlée et sécurisée, y compris lorsqu'une exception se produit, en empêchant les situations de type fail-open telles que le traitement d'une transaction malgré des erreurs issues de la logique de validation.

Verify that the application fails gracefully and securely, including when an exception occurs, preventing fail-open conditions such as processing a transaction despite errors resulting from validation logic.

Réponse de Cybernetics : Partiellement. La validation intervient avant tout traitement et les écritures critiques sont transactionnelles ; un échec d'écriture du journal d'audit est journalisé mais ne bloque pas l'opération.

17.1.1 · niveau 2 · Vérifier que le service Traversal Using Relays around NAT (TURN) n'autorise l'accès qu'à des adresses IP non réservées à des usages particuliers (par ex. réseaux internes, diffusion, bouclage). Noter que cela s'applique aux adresses IPv4 comme IPv6.

Verify that the Traversal Using Relays around NAT (TURN) service only allows access to IP addresses that are not reserved for special purposes (e.g., internal networks, broadcast, loopback). Note that this applies to both IPv4 and IPv6 addresses.

Réponse de Cybernetics : Sans objet. Cybernetics n'utilise aucune fonctionnalité WebRTC ni service TURN (vérifié dans le code).

​

17.2.1 · niveau 2 · Vérifier que la clé du certificat Datagram Transport Layer Security (DTLS) est gérée et protégée conformément à la politique documentée de gestion des clés cryptographiques.

Verify that the key for the Datagram Transport Layer Security (DTLS) certificate is managed and protected based on the documented policy for management of cryptographic keys.

Réponse de Cybernetics : Sans objet. Aucun serveur média ni DTLS, faute de WebRTC.

​

17.2.2 · niveau 2 · Vérifier que le serveur de médias est configuré pour utiliser et prendre en charge des suites cryptographiques Datagram Transport Layer Security (DTLS) approuvées et un profil de protection sécurisé pour l'extension DTLS d'établissement de clés pour le Secure Real-time Transport Protocol (DTLS-SRTP).

Verify that the media server is configured to use and support approved Datagram Transport Layer Security (DTLS) cipher suites and a secure protection profile for the DTLS Extension for establishing keys for the Secure Real-time Transport Protocol (DTLS-SRTP).

Réponse de Cybernetics : Sans objet. Aucun serveur média ni DTLS-SRTP, faute de WebRTC.

​

17.2.3 · niveau 2 · Vérifier que l'authentification Secure Real-time Transport Protocol (SRTP) est contrôlée au niveau du serveur de médias afin d'empêcher que les attaques par injection Real-time Transport Protocol (RTP) ne conduisent à un déni de service ou à l'insertion de médias audio ou vidéo dans les flux de médias.

Verify that Secure Real-time Transport Protocol (SRTP) authentication is checked at the media server to prevent Real-time Transport Protocol (RTP) injection attacks from leading to either a Denial of Service condition or audio or video media insertion into media streams.

Réponse de Cybernetics : Sans objet. Aucun flux SRTP, faute de WebRTC.

​

17.2.4 · niveau 2 · Vérifier que le serveur de médias est capable de continuer à traiter le trafic média entrant lorsqu'il rencontre des paquets Secure Real-time Transport Protocol (SRTP) malformés.

Verify that the media server is able to continue processing incoming media traffic when encountering malformed Secure Real-time Transport Protocol (SRTP) packets.

Réponse de Cybernetics : Sans objet. Aucun flux SRTP, faute de WebRTC.

​

17.3.1 · niveau 2 · Vérifier que le serveur de signalisation est capable de continuer à traiter les messages de signalisation entrants légitimes pendant une attaque par inondation. Cela doit être réalisé en mettant en œuvre une limitation de débit au niveau de la signalisation.

Verify that the signaling server is able to continue processing legitimate incoming signaling messages during a flood attack. This should be achieved by implementing rate limiting at the signaling level.

Réponse de Cybernetics : Sans objet. Aucun serveur de signalisation WebRTC.

​

17.3.2 · niveau 2 · Vérifier que le serveur de signalisation est capable de continuer à traiter les messages de signalisation légitimes lorsqu'il rencontre des messages de signalisation malformés susceptibles de provoquer un déni de service. Cela peut inclure la mise en œuvre d'une validation des entrées, la gestion sûre des débordements d'entiers, la prévention des débordements de tampon et l'emploi d'autres techniques robustes de gestion des erreurs.

Verify that the signaling server is able to continue processing legitimate signaling messages when encountering malformed signaling message that could cause a denial of service condition. This could include implementing input validation, safely handling integer overflows, preventing buffer overflows, and employing other robust error-handling techniques.

Réponse de Cybernetics : Sans objet. Aucun serveur de signalisation WebRTC.

Une question ? Nous contacter.