Directives de codage d’actions

Suivez les directives ci-dessous pour écrire un code d’actions performant, sécurisé et clair pour un environnement de production simplifié.

• Utilisez le nombre minimum de demandes HTTP possible et définissez un délai d’attente raisonnable (moins de 10 secondes) pour éviter les demandes accumulées lors de la connexion.

• Utilisez les métadonnées d’application pour filtrer les applications spécifiques afin de déterminer si une Action doit être exécutée.

• Veiller à ce que les Actions qui fournissent une vérification ou déclenchent une MFA ne puissent être contournées de façon non intentionnelle ou malveillante.

• Les actions ne devraient jamais lancer intentionnellement une erreur; si les processus s’arrêtent à cause 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 appels d’Authentication API; il peut s’agir du domaine de locataire Auth0 par défaut ou d’un domaine personnalisé.

• Vérifier la stricte égalité === avec toutes les données entrantes ou stockées.

• Utiliser un énoncé de return lorsque le processus d’action doit s’arrêter.

• Exécutez un linter de code, comme ESLint, et un analyseur, comme Semgrep, pour améliorer la qualité du code et trouver les problèmes automatiquement.

• Ne pas écrire de secrets ou d’artefacts de code sensibles en texte brut dans le cadre de votre code d’actions. Utilisez plutôt le Gestionnaire de secrets ou tirez parti de votre propre gestionnaire en l’intégrant dans le code d’actions.

• Ne transmettez pas d’informations personnelles identifiables (PII) en vue, comme dans les URL ou les messages d’erreur.

• Utilisez toujours des URL HTTPS pour les redirections et les appels d’API.

• AllowList les adresses IP lorsque cela est possible.

• Surveiller les données entrantes pouvant être modifiées (paramètres d’URL, agent utilisateur, etc.).

• Détecter les erreurs et traiter au besoin.

• Utiliser les clauses de garde et retourner tôt si le traitement des Actions ne doit pas se poursuivre.

• Ne jamais enregistrer de données sensibles, de secrets ou de PII.

• Rester en dessous du maximum de 256 caractères enregistrés par Action.

• Utiliser des packages approuvés et maintenus.

• Vérifier les CVE en cours à l’aide de la fonction d’audit de npm ou d’un vérificateur de dépendance automatisé connecté à un référentiel.

• Utilisez la dernière version d’un package lorsque cela est possible.

• Vérifier si un courriel est vérifié avec event.user.email_verified s’il est utilisé dans un contexte sensible ou de haute sécurité.

• Différentes connexions fournissent des données de profil utilisateur différentes; le seul champ du profil utilisateur garanti est le user_id.

• Le jeton retourné par api.redirect.encodeToken est signé mais pas chiffré, donc les données sensibles ou PII ne doivent pas être incluses dans la charge utile.

• Le flux de connexion s’exécute après une connexion réussie, qui comprend :

  • Authentification unique (aucun formulaire de connexion n’est affiché)

  • authentification silencieuse (vérification d’une session en utilisant prompt=none dans l’URL d’autorisation )

  • échange de jetons d’actualisation (sans interaction utilisateur)

  • Les mots de passe RO (informations d’identification recueillies à partir d’une application et échangées avec le point de terminaison du jeton)

• Les Actions qui redirigent doivent tenir compte des cas ci-dessus et refuser l’accès si une interaction est requise ou permettre intentionnellement le contournement, ce qui place la charge sur l’application demandant la connexion.