Infrastructure et déploiement

L'application peut être parfaite et le serveur rester grand ouvert. Ces contrôles portent sur la manière et le lieu où elle s'exécute.

Liste de contrôle

• N'exposez que les ports que vous voulez réellement exposer. Un pare-feu d'hôte qui autorise 22, 80 et 443 ne suffit pas à lui seul : Docker publie les ports des conteneurs en écrivant des règles iptables qui contournent ufw, donc un -p 9000:9000 peut être joignable depuis Internet même lorsque le pare-feu « n'autorise que 443 ». Liez les ports des conteneurs à 127.0.0.1 sauf s'ils doivent être publics, et scannez votre propre IP publique pour confirmer ce qui est réellement ouvert.
• Gardez les panneaux d'administration hors d'Internet public. Les tableaux de bord comme Portainer, les outils d'administration de bases de données et les interfaces de métriques ne doivent jamais être accessibles depuis Internet. Un panneau d'administration fraîchement installé, sans compte configuré, donne un contrôle total : quiconque l'atteint pendant la phase d'installation possède la machine. Les politiques de redémarrage peuvent rouvrir cette fenêtre.
• Liez les serveurs d'application au loopback et placez-les derrière un reverse proxy. L'application écoute sur 127.0.0.1 ; nginx ou la périphérie termine le TLS et transmet les requêtes.
• Rendez l'origine inaccessible sauf via la périphérie. Si vous utilisez Cloudflare ou un service similaire, imposez-le par des authenticated origin pulls (mTLS) ou une liste blanche d'IP, afin que les attaquants ne puissent pas contourner le WAF en frappant l'IP de l'origine.
• Configurez les en-têtes de sécurité. Strict-Transport-Security, X-Content-Type-Options: nosniff, X-Frame-Options: DENY (ou frame-ancestors 'none'), une Content-Security-Policy stricte (idéalement script-src 'self' sans unsafe-inline ni unsafe-eval), un Referrer-Policy et un Permissions-Policy verrouillé.
• Ne divulguez pas la version ni la pile technique. Supprimez les bannières Server et X-Powered-By.
• Bloquez l'accès aux fichiers cachés et aux sorties de compilation. /.env, /.git/, les fichiers de configuration et les source maps ne doivent pas être accessibles depuis le web. Vérifiez que chacun renvoie 403 ou 404.
• Affichez des erreurs génériques. Aucune trace de pile ni chemin interne ne doit être montré aux utilisateurs ; journalisez le détail côté serveur.
• Maintenez le runtime à jour et exécutez l'application avec un utilisateur non root, aux privilèges minimaux, dans un conteneur ou un bac à sable lorsque c'est possible.

Comment tester

• Depuis une machine extérieure à votre réseau, scannez vos IP publiques à la recherche de ports ouverts.
• Demandez /.env, /.git/config et un fichier .map sur votre domaine.
• Lisez les en-têtes de réponse de votre page d'accueil et vérifiez chaque point ci-dessus.

Voir aussi

• Disponibilité et abus
• Secrets et protection des données
• Dépendances, journalisation et processus