Sécurité

Nous considérons la confidentialité comme un droit, et non un privilège, et elle est au cœur des fondations de notre entreprise. En utilisant la plateforme développeurs X et en respectant notre politique développeur, vous jouez un rôle essentiel pour veiller à ce que la plateforme serve la conversation publique sur X et protège notre engagement en matière de confidentialité.

Nous souhaitons vous rappeler l’importance de développer en toute sécurité afin de protéger à la fois vos propres données et celles des utilisateurs de vos Apps. Il vous incombe de vous prémunir contre les failles de sécurité, et nous partageons la responsabilité de protéger les personnes qui utilisent X. Cette page décrit nos attentes en matière de création d’applications sécurisées et de protection des données et des accès autant que possible.

Veuillez prendre connaissance des technologies de sécurité disponibles pour la X Developer Platform, notamment l’authentification, TLS et les autorisations d’App, ainsi que, du point de vue des utilisateurs de X, des recommandations pour l’usage d’applications et de sessions tierces.

​

Signaler des problèmes de sécurité

Les utilisateurs de la X Developer Platform doivent informer X, au plus tard 48 heures après l’apparition de la première suspicion qu’un incident de sécurité s’est produit, via le programme de signalement des vulnérabilités de X.

​

Bonnes pratiques de sécurité

Veuillez les garder à l’esprit lorsque vous développez sur la plateforme développeur X, ainsi que partout ailleurs sur Internet.

​

Sécurité dès la conception

Envisagez de faire appel à des spécialistes de la sécurité pour réaliser une analyse de modèle de menaces et/ou un test d’intrusion. Une bonne société de sécurité ira en profondeur pour mettre au jour d’éventuels problèmes. Pour en savoir plus sur la manière dont X a adopté cet état d’esprit, consultez cet article sur notre blog.

Par ailleurs, X exige de tous les partenaires ce qui suit :

• Maintenir le code dans un dépôt sécurisé.
• Mener une analyse des risques tout au long du cycle de vie de développement des systèmes (SDLC).
• Veiller à ce que les problèmes de sécurité soient identifiés et atténués tout au long du SDLC.
• Garantir la ségrégation des environnements tout au long du SDLC.
• S’assurer que tous les défauts détectés lors des tests sont corrigés, retestés et clôturés.

​

Surveillez et soyez alerté

Si vous pensez qu’un problème affecte votre application web, comment en avoir le cœur net ? Assurez-vous de conserver des journaux exploitables et d’être notifié des exceptions et erreurs critiques. Vous pouvez envisager de créer un tableau de bord d’indicateurs clés afin de voir d’un coup d’œil si quelque chose ne va pas.

​

Créer un canal de signalement

Facilitez à vos utilisateurs la prise de contact pour vous signaler d’éventuels problèmes de sécurité rencontrés avec votre App. Si un problème est découvert et affecte des utilisateurs X et des data, il vous incombe également de signaler ce problème à X. Prévoyez un plan/processus d’action pour informer les utilisateurs concernés en cas d’incident de sécurité.

​

Tests adéquats

Assurez-vous que vos tests de bout en bout sont exhaustifs et à jour, et qu’ils incluent des échecs attendus pour des scénarios de sécurité tels que l’accès non autorisé. Adoptez la perspective d’un attaquant et mettez en place des tests système destinés à empêcher toute tentative d’obtenir un accès non autorisé aux données X ou d’exploiter des fonctionnalités protégées.

​

Sécurisation des API Key et des tokens

En tant que développeur sur la plateforme X, vous avez un accès programmatique à vos données et à celles de vos utilisateurs stockées par X, sous réserve qu’ils aient autorisé votre App développeur. Toutes les requêtes à l’API doivent être authentifiées via OAuth avec la clé et le secret de votre App développeur et, dans certains cas, les access tokens d’un utilisateur autorisant. Il vous incombe de protéger vos informations d’identification.

Quelques bonnes pratiques recommandées :

• Mettre en place une rotation de renouvellement des mots de passe/jetons.
• Chiffrer systématiquement les données sensibles selon les besoins et éviter de les déchiffrer trop en amont.
• Stocker les access tokens de vos utilisateurs dans un coffre/stockage chiffré.
• Régénérez ou invalidez les clés et les jetons si vous pensez qu’ils ont été compromis.

Pour en savoir plus sur le débogage et le développement avec OAuth pour X, consultez la catégorie sécurité du forum de la communauté.

​

Validation des entrées

Ne partez pas du principe que vos utilisateurs vous fourniront des données valides et fiables. Assainissez toutes les données provenant de vos utilisateurs susceptibles d’être utilisées dans des requêtes X API. Définissez une liste d’autorisation des types d’entrées acceptés par votre application et rejetez tout ce qui n’y figure pas.

​

Communication chiffrée

X exige que toutes les requêtes à l’API soient effectuées via TLS. Les communications avec vos propres serveurs doivent également être chiffrées autant que possible.

​

Informations de débogage exposées

Assurez-vous de ne pas exposer de données sensibles X ni des identifiants via des écrans ou journaux de débogage. Certains frameworks web facilitent l’accès aux informations de débogage si votre application n’est pas correctement configurée. Pour les développeurs desktop et mobiles, il est facile de livrer par inadvertance une build avec des indicateurs ou des symboles de débogage activés. Intégrez des vérifications de compilation pour ces configurations dans votre processus de déploiement/compilation. Par ailleurs, si vous partagez des traces de pile ou des vidages de crash à des fins de rapport, veillez à anonymiser/masquer les données des utilisateurs X privés.

​

Entrée non filtrée, sortie non échappée

Une méthode mnémotechnique pour la validation des entrées est FIEO : Filtrer l’entrée, Échapper la sortie.

Filtrez tout ce qui provient de l’extérieur de votre application, notamment les données de l’X API, les cookies, les données saisies par les utilisateurs dans des formulaires, les paramètres d’URL, les données issues des bases de données, etc. Échappez toutes les sorties émises par votre application, y compris le SQL envoyé à votre serveur de bases de données, le HTML que vous envoyez aux navigateurs des utilisateurs, la sortie JSON envoyée à d’autres systèmes, ainsi que les commandes transmises aux interpréteurs de commandes (shell).

​

Cross-site scripting (XSS)

Les attaques de XSS sont, de loin, l’un des problèmes de sécurité les plus courants sur le Web. Si un attaquant parvient à injecter son propre code JavaScript dans votre application, il peut causer de sérieux dommages. Partout où vous stockez et affichez des données non fiables fournies par des utilisateurs, il faut les vérifier, les assainir et les échapper en HTML. Bien faire cela est difficile, car les attaquants disposent de nombreuses façons de mener des attaques XSS. Votre langage ou votre framework de développement Web propose probablement un mécanisme éprouvé pour se prémunir contre le cross-site scripting ; utilisez-le.

​

Injection SQL

Si votre application utilise une base de données, vous devez être conscient(e) de l’injection SQL. Tout point d’entrée où vous acceptez des données est une cible potentielle permettant à un attaquant de sortir du champ de saisie et d’accéder à votre base de données. Utilisez des bibliothèques de gestion de base de données qui protègent systématiquement contre l’injection SQL. Si vous vous écartez de cette approche et écrivez des requêtes SQL personnalisées, rédigez des tests rigoureux pour vous assurer que vous ne vous exposez pas à ce type d’attaque. Les deux principales approches pour se défendre contre l’injection SQL sont l’échappement avant la construction de la requête SQL et l’utilisation de paramètres pour créer les requêtes. La seconde est recommandée, car elle est moins sujette aux erreurs de programmation.

​

Falsification de requête intersite (CSRF)

Êtes-vous sûr que les requêtes adressées à votre application proviennent bien de celle-ci ? Les attaques de CSRF exploitent cette incertitude en amenant des utilisateurs connectés à votre site à ouvrir, à leur insu, des URL qui déclenchent des actions. Dans le cas d’une App développeur, cela peut signifier que des attaquants utilisent votre App pour forcer des utilisateurs à publier des Tweets indésirables ou à suivre des comptes de spam.

La manière la plus rigoureuse de se prémunir contre le CSRF consiste à inclure un jeton aléatoire dans chaque formulaire et à le stocker dans un emplacement de confiance ; si un formulaire ne présente pas le bon jeton, générez une erreur. Les frameworks web modernes proposent des mécanismes systématiques pour gérer cela, et le font parfois même par défaut. Une mesure préventive simple (mais qui ne saurait suffire à elle seule) consiste à exiger une requête POST pour toute action qui crée, modifie ou supprime des data.

​

Absence de limite de taux

Utilisez des CAPTCHA lorsque cela est approprié pour ralentir les spammeurs et les attaquants potentiels.

---

Si vous découvrez un problème de sécurité qui affecte directement X, nous proposons un programme de primes aux vulnérabilités.