Skip to main content
Suivez les directives ci-dessous pour rédiger du code Actions performant, sécurisé et clair, afin d’assurer un environnement de production fluide.

​
Principes de base des Actions

  • Utilisez le moins de requêtes HTTP possible et définissez un délai d’expiration raisonnable (moins de 10 secondes) afin d’éviter l’accumulation de requêtes pendant la connexion.
  • Utilisez les métadonnées de l’application pour filtrer des applications précises et déterminer si une Action doit être exécutée.
    • Exemple : valeurs propres à l’application ou valeurs de regroupement d’applications utilisées pour faire varier partiellement ou entièrement l’exécution de l’Action.
  • Utilisez user_metadata/app_metadata pour enregistrer des données personnalisées dans le profil de l’utilisateur.
    • Exemple : préférences de l’utilisateur ou valeurs d’état.
  • Utilisez les métadonnées de transaction pour partager des données entre les déclencheurs post-login pendant une même exécution.
    • Exemple : valeurs récupérées à partir de services externes ou calculées, qui doivent être réutilisées dans des Actions subséquentes et qui sont liées à l’exécution en cours.
  • Utilisez le cache pour les données qui doivent être partagées par des Actions appartenant à différentes exécutions.
    • Exemple : valeurs récupérées à partir de services externes ou calculées, qui doivent être réutilisées par des Actions et qui ne sont liées ni à l’utilisateur ni à l’exécution en cours.
  • Assurez-vous que les Actions qui fournissent une vérification ou déclenchent la ne peuvent pas être contournées, intentionnellement ou de façon malveillante.
  • Les Actions ne devraient jamais générer intentionnellement une erreur; si des processus s’arrêtent en raison d’une erreur ou d’une condition, utilisez la méthode api appropriée, comme api.access.deny().
  • Utilisez event.request.hostname pour le domaine utilisé dans les requêtes vers l’Authentication API; il peut s’agir du domaine par défaut du tenant Auth0 ou d’un domaine personnalisé.
Le code des Actions ne doit contenir aucun renseignement personnel identifiable (PII). Ne codez pas en dur, ne stockez pas et ne traitez pas de PII (comme les adresses courriel, les numéros de téléphone ou les noms des utilisateurs) directement dans le code de vos Actions ou Actions Modules. Pour gérer de façon sécuritaire les valeurs de configuration sensibles, utilisez toujours le Secrets Manager.

​
Actions Modules

  • Utilisez Actions Modules lorsqu’il faut réutiliser des fonctions dans différentes Actions afin d’éviter la redondance du code.
  • Réduisez le temps d’instanciation des objets lorsque c’est possible en appliquant le patron Singleton pour réutiliser des instances d’objet dans l’Action Module.
  • Suivez les lignes directrices applicables présentées dans ce document concernant le code, la sécurité, la journalisation, les dépendances et les données utilisateur.
  • Lorsque vous utilisez un Action Module dans une Action, tenez toujours compte de la version du module utilisée.
Lorsque vous publiez une nouvelle version d’un Action Module, Auth0 ne met pas automatiquement à jour la version référencée par les Actions, ce qui évite des problèmes potentiels si la mise à niveau n’est pas compatible avec l’Action.

​
Principes de base du codage

  • Vérifiez l’égalité stricte === pour toutes les données entrantes ou stockées.
  • Utilisez une instruction return lorsque le processus Action doit s’arrêter.
  • Exécutez un linter, comme ESLint, et un analyseur, comme Semgrep, pour améliorer la qualité du code et repérer automatiquement les problèmes.

​
Principes de base de la sécurité

  • N’écrivez pas de secrets ni d’artefacts de code sensibles en texte brut dans votre code Actions. Utilisez plutôt le Secrets Manager ou votre propre gestionnaire en l’intégrant au code Actions.
  • Ne transmettez pas de renseignements personnels identifiables (PII) non chiffrés en clair, par exemple dans les URL ou les messages d’erreur.
  • Utilisez toujours des URL HTTPS pour les redirections et les appels d’API.
  • Ajoutez les adresses IP à l’AllowList lorsque c’est possible.
  • Soyez attentif aux données entrantes qui peuvent être falsifiées (paramètres d’URL, agent utilisateur, etc.).

​
Programmation défensive

  • Interceptez les erreurs et gérez-les au besoin.
  • Utilisez des clauses de garde et prévoyez un retour immédiat si le traitement de l’Action ne doit pas se poursuivre.

​
Journalisation

  • Ne consignez jamais de données sensibles, de secrets ni de PII.
  • Limitez-vous à un maximum de 256 caractères consignés par Action.

​
Dépendances

  • Utilisez des paquets de confiance et bien maintenus.
  • Vérifiez s’il existe des CVE non corrigées à l’aide de la fonction d’audit de npm ou d’un vérificateur automatisé de dépendances lié à un dépôt.
  • Utilisez la version la plus récente d’un paquet, si possible.

​
Données utilisateur

  • Vérifiez si une adresse courriel est vérifiée avec event.user.email_verified lorsqu’elle est utilisée dans un contexte sensible ou de haute sécurité.
  • Les différentes connexions fournissent des données de profil utilisateur différentes; le seul champ du profil utilisateur garanti est user_id.

​
Redirect Actions dans le flux de connexion

  • Le jeton renvoyé par api.redirect.encodeToken est signé, mais non chiffré; les données sensibles ou les PII ne doivent donc pas être incluses dans le payload.
  • Le flux de connexion s’exécute après une connexion réussie, notamment dans les cas suivants :
    • SSO (aucun formulaire de connexion n’est affiché)
    • authentification silencieuse (vérification d’une session à l’aide de prompt=none dans l’URL d’autorisation)
    • échange de jeton d’actualisation (aucune interaction utilisateur)
    • grants par mot de passe RO (informations d’identification recueillies par une application et échangées avec le point de terminaison des jetons)
  • Les Actions qui redirigent doivent tenir compte des cas ci-dessus et soit rejeter l’accès si une interaction est requise, soit permettre intentionnellement le contournement, ce qui transfère la responsabilité à l’application qui demande la connexion.