6. Considérations de sécurité

6. Considérations de sécurité

Les applications utilisant HTTP doivent examiner attentivement la sécurité. Cette section met en évidence certaines considérations de sécurité clés; voir également [HTTP] Section 17.

Les applications DEVRAIENT utiliser TLS [RFC8446] pour toutes les communications. En particulier, les applications DOIVENT utiliser TLS lors de la transmission d'informations sensibles telles que des informations d'authentification ou des données personnelles. Voir [RFC7258] pour plus d'informations sur la nécessité d'un chiffrement omniprésent.

Les applications DEVRAIENT utiliser le schéma URI "https" plutôt que "http" pour garantir que TLS est utilisé. Lorsque TLS est utilisé, les applications DEVRAIENT suivre les meilleures pratiques actuelles, notamment:

• Utiliser TLS 1.3 [RFC8446] ou ultérieur.

• Valider les certificats du serveur.

• Utiliser des suites de chiffrement appropriées.

• Envisager l'utilisation de HTTP Strict Transport Security (HSTS) [RFC6797] pour garantir que les navigateurs utilisent toujours HTTPS.

Les applications doivent être conscientes de diverses attaques basées sur le Web et de la manière de les atténuer:

• Cross-Site Scripting (XSS): Si une application renvoie du contenu qui peut être interprété comme HTML ou JavaScript par un navigateur, elle doit correctement échapper ou assainir ce contenu pour empêcher les attaques XSS. Utiliser Content-Type de manière appropriée et définir des en-têtes Content-Security-Policy [CSP] peut aider.

• Cross-Site Request Forgery (CSRF): Les applications qui maintiennent un état (par exemple, en utilisant des cookies) doivent se protéger contre les attaques CSRF, où un site malveillant trompe le navigateur d'un utilisateur pour qu'il fasse des requêtes à l'application. Les atténuations courantes incluent l'utilisation de jetons CSRF et la vérification des champs d'en-tête Origin ou Referer.

• Attaques par injection: Les applications qui intègrent des entrées utilisateur dans des requêtes, des commandes ou d'autres données structurées doivent correctement valider et assainir cette entrée pour empêcher les attaques par injection (par exemple, injection SQL).

• Divulgation d'informations: Les applications doivent faire attention aux informations qu'elles incluent dans les messages d'erreur, les champs d'en-tête et autres réponses. Des messages d'erreur détaillés peuvent aider les attaquants à comprendre les mécanismes internes de l'application.

Les applications DEVRAIENT tenir compte des implications de sécurité de la mise en cache. En particulier:

• Les informations sensibles NE DEVRAIENT PAS être mises en cache, ou si elles doivent être mises en cache, elles ne devraient être mises en cache que de manière privée (en utilisant Cache-Control: private).

• Les informations d'authentification NE DEVRAIENT PAS être incluses dans les URL, car elles pourraient être enregistrées ou mises en cache.

Les applications utilisant l'authentification doivent tenir compte de:

• La manière dont les informations d'authentification sont transmises (elles devraient être protégées par TLS).

• La durée de vie des sessions d'authentification et la manière dont elles peuvent être révoquées.

• Comment se protéger contre les attaques par force brute sur l'authentification.

• Si l'authentification multifactorielle est appropriée.

Les applications DEVRAIENT être conscientes que les clients et les serveurs peuvent ne pas être sous le contrôle des concepteurs de l'application. En particulier:

• Les intermédiaires (proxies, CDN, etc.) peuvent mettre en cache, enregistrer ou modifier les requêtes et les réponses.

• Les clients peuvent être malveillants ou compromis.

• Les serveurs peuvent être compromis.

Les applications DEVRAIENT donc:

• Utiliser le chiffrement et l'authentification de bout en bout lorsque cela est approprié.

• Ne pas se fier uniquement à la sécurité de la couche de transport pour les opérations sensibles.

• Valider toutes les entrées des clients.

• Être conscientes du principe du moindre privilège et éviter de donner aux clients ou aux serveurs plus d'accès que nécessaire.

Les applications qui permettent aux utilisateurs de télécharger du contenu ou d'exécuter du code doivent être extrêmement prudentes quant à l'isolation et au sandboxing. Même les fonctionnalités apparemment bénignes peuvent être abusées:

• Les téléchargements de fichiers peuvent contenir du contenu malveillant qui pourrait exploiter des vulnérabilités dans les analyseurs ou les visualiseurs.

• Les URL contrôlées par l'utilisateur peuvent être utilisées pour des attaques Server-Side Request Forgery (SSRF).

• Les fonctionnalités qui exécutent du code fourni par l'utilisateur (par exemple, JavaScript dans un contexte de navigateur) nécessitent une forte isolation.

Les applications accessibles depuis les navigateurs Web doivent être particulièrement prudentes car les navigateurs ont un modèle de sécurité complexe avec de nombreux pièges potentiels. Les applications DEVRAIENT:

• Utiliser des en-têtes Content-Security-Policy appropriés [CSP] pour limiter ce que les navigateurs peuvent faire.

• Utiliser des politiques CORS appropriées [FETCH] pour contrôler l'accès inter-origine.

• Définir les cookies avec des indicateurs appropriés (Secure, HttpOnly, SameSite).

• Envisager d'utiliser X-Frame-Options ou la directive frame-ancestors de CSP pour empêcher le clickjacking.

• Être conscientes des comportements spécifiques au navigateur tels que le préchargement, le préchargement DNS et la préconnexion.

• Envisager d'utiliser Subresource Integrity (SRI) pour s'assurer que les ressources hébergées en externe n'ont pas été altérées.

Les applications DEVRAIENT être conscientes que les fonctionnalités HTTP peuvent parfois être abusées:

• Les redirections peuvent être utilisées pour le phishing ou pour contourner les contrôles de sécurité.

• Les grandes requêtes ou réponses peuvent être utilisées pour des attaques par déni de service.

• L'analyse complexe des champs d'en-tête ou du contenu peut conduire à des vulnérabilités.

Enfin, les applications DEVRAIENT avoir une politique de sécurité claire et devraient être conçues avec la sécurité à l'esprit dès le début. La sécurité ne devrait pas être une réflexion après coup.