Par exemple, si nécessaire, donnez accès à l’administrateur ou au modérateur aux fonctions des thèmes, mais désactivez par exemple l’accès pour voir les secrets de l’API à partir des connexions sociales.
Et séparez les modérateurs, par exemple, donnez le rôle de modérateur à certaines personnes dans la branche de la communauté sur le forum pour des personnes de confiance avec des restrictions…
Toute personne ayant un accès en écriture aux thèmes peut complètement détourner la session d’un utilisateur. Si vous ne faites pas confiance à quelqu’un pour faire cela, vous ne devriez pas lui faire confiance du tout. Et si vous lui faites confiance, vous pouvez simplement en faire un administrateur.
C’était un exemple, plus clairement, je ne veux pas donner accès aux clés d’API, mais à d’autres sections de configuration. Pour éviter que l’administrateur ne copie ces clés et ne les utilise ailleurs à l’avenir, par exemple pour tester quelque chose.
Pas nécessairement même pour de mauvaises intentions, pourtant c’est une section assez alarmante dans le cas, par exemple, d’une clé GitHub. L’administrateur peut ne pas être du tout lié au dépôt, mais administrer le forum si nécessaire. Mais je ne voulais pas qu’il compromette accidentellement les clés, simplement en les “copiant et qu’elles soient ensuite volées”.
ou les supprime par erreur.
par paresse d’en obtenir de propres, et dans le cas de Twitter et Google, tout est plutôt contradictoire là-bas, car ces clés ne sont plus distribuées à tous ceux qui demandent un accès, et même un compromis accidentel des clés peut entraîner la désactivation de l’accès à l’API.
comment les pages de solution comme celle-ci peuvent-elles être protégées par un mot de passe supplémentaire lors des prochaines versions si nécessaire
Je pense qu’il est préférable de réfléchir à toutes les vulnérabilités possibles et de prévenir même si elles sont peu probables