Lire en anglais Modifier

Partager via


FAQ sur la sécurité de Power Pages

Comment Power Pages aide à protéger contre les risques de détournement de clic (clicjacking) ?

Le clicjacking (détournement de clic) utilise des iFrames intégrés ou d’autres composants pour détourner les interactions d’un utilisateur avec une page Web.
Power Pages fournit les paramètres de site HTTP/X-Frame-Options avec SAMEORIGIN par défaut pour vous protéger contre les attaques de détournement de clic.

Pour plus d’informations : Configurer les en-têtes HTTP dans Power Pages

Les stratégies de sécurité du contenu sont-elles prises en charge par Power Pages ?

Power Pages prend en charge la stratégie de sécurité du contenu (CSP). Il est recommandé d’effectuer des tests approfondis après avoir activé CSP sur les sites web Power Pages.

Pour plus d’informations : Gérer la stratégie de sécurité du contenu de votre site

Power Pages prend-il en charge la stratégie HTTP Strict Transport Security ?

Par défaut, Power Pages prend en charge les redirections HTTP vers HTTPS. Si cette option est activée, vérifiez si la demande est bloquée au niveau du service d’application. Si la demande n’aboutit pas (code de réponse >= 400), il s’agit d’un faux positif.

Pourquoi les cookies sans indicateurs HTTPOnly/SameSite sont-ils détectés/signalés par les outils de test de pénétration ?

Power Pages définit les indicateurs HTTPOnly/SameSite pour chaque cookie critique. Il existe certains cookies non critiques pour lesquels HTTPOnly/SameSite n’est pas défini et ceux-ci ne doivent pas être considérés comme une vulnérabilité.

Pour plus d’informations : Cookies dans Power Pages

Mon rapport de test de pénétration indique Fin de vie/Logiciel obsolète – Bootstrap 3. Que dois-je faire ?

Il n’existe aucune vulnérabilité connue sur Bootstrap 3 ; cependant, vous pouvez migrer votre site vers Bootstrap 5.

Quels chiffrements sont pris en charge par Power Pages ? Quelle est la feuille de route pour évoluer continuellement vers des chiffrements plus forts ?

Tous les services et produits Microsoft sont configurés pour utiliser les suites de chiffrement approuvées, dans l’ordre exact indiqué par la carte de chiffrement Microsoft.

Pour la liste complète et l’ordre exact, voir la Documentation relative à Power Platform.

Les informations relatives aux obsolescences des suites de chiffrement sont communiquées via la documentation Modifications importantes de Power Platform.

Pourquoi Power Pages prend toujours en charge les chiffrements RSA-CBC (TLS_ECDHE_RSA_with_AES_128_CBC_SHA256 (0xC027) et TLS_ECDHE_RSA_with_AES_256_CBC_SHA384 (0xC028)) qui sont considérés comme plus faibles ?

Microsoft évalue le risque relatif et la perturbation des opérations des clients dans le choix de la prise en charge des suites de chiffrement. Les suites de chiffrement RSA-CBC n’ont pas encore été brisées. Nous les avons activées pour garantir la cohérence dans nos services et produits et pour prendre en charge toutes les configurations clientes ; toutefois, elles sont en bas de la liste des priorités.

Nous abandonnons ces chiffrements en fonction de l’évaluation continue de Microsoft Crypto Board.

Pour plus d’informations : Quelles suites de chiffrement TLS 1.2 sont prises en charge par Power Pages ?

Quelle protection offre Power Pages contre les attaques DDoS par déni de service distribué ?

Power Pages est basé sur Microsoft Azure et utilise Azure DDoS Protection pour se protéger contre les attaques DDoS. L’activation d’OOB/AFD tiers/WAF peut également ajouter une protection supplémentaire au site.

Pour plus d’informations :

Le rapport du test de pénétration signale une vulnérabilité dans CKEditor. Comment puis-je atténuer cette vulnérabilité ?

Le contrôle RTE PCF remplacera bientôt CKEditor. Si vous souhaitez atténuer ce problème avant le lancement du contrôle RTE PCF, désactivez CKEditor en configurant le paramètre de site DisableCkEditorBundle = true. Un champ de texte remplace CKEditor une fois désactivé.

Comment protéger mon site Web contre les attaques XSS ?

Nous vous recommandons d’effectuer le codage HTML avant d’afficher les données provenant d’une source non fiable.

Pour plus d’informations : Filtres de codage disponibles.

Comment protéger mon site contre les attaques par injection ?

Par défaut, la fonctionnalité de validation des demandes d’ASP.Net est activée dans les formulaires Power Pages pour empêcher les attaques par injection de script. Si vous créez votre propre formulaire à l’aide de l’API, Power Pages incorpore plusieurs mesures pour empêcher les attaques par injection.

  • Effectuez un assainissement HTML approprié lors du traitement des entrées utilisateur à partir d’un formulaire ou de tout contrôle de données qui utilise l’API Web.
  • Mettez en œuvre l’assainissement des entrées et des sorties pour toutes les données d’entrée et de sortie avant de les afficher sur la page. Cela inclut les données récupérées via Liquid/WebAPI ou insérées/mises à jour dans Dataverse via ces canaux.
  • Si des vérifications spéciales sont nécessaires avant d’insérer ou de mettre à jour les données du formulaire, vous pouvez écrire des plug-ins qui s’exécutent pour valider les données côté serveur.

Pour plus d’informations : Livre blanc sur la sécurité de Power Pages.