La sécurité Web n’est pas un réglage unique que l’on active une fois pour toutes. Elle repose sur plusieurs couches qui réduisent chacune une famille de risques : transport chiffré, contrôle des ressources chargées, limitation des capacités du navigateur, authentification et vérification de l’intégrité.
Cette collection Sécuriser un site Web explique ces mécanismes sans les confondre avec la confidentialité des fichiers. Le Local First, la confidentialité des PDF ou les métadonnées d’image répondent à une autre question : où vont les données et quelles informations contiennent-elles ? Ici, on s’intéresse aux protections techniques d’un site et de ses échanges.
Penser en couches plutôt qu’en solution miracle
HTTPS protège le transport entre le navigateur et le serveur, mais ne corrige pas une application vulnérable. Une Content Security Policy peut limiter l’impact de certaines injections, mais elle ne remplace pas l’échappement des données ni une validation correcte. Un mot de passe robuste ne compense pas une mauvaise gestion de session.
Une défense cohérente combine donc plusieurs mécanismes :
- HTTPS pour chiffrer les échanges en transit ;
- en-têtes HTTP de sécurité pour donner au navigateur des règles explicites ;
- CSP pour contrôler les origines autorisées à fournir scripts, styles, images ou connexions ;
- SRI pour vérifier l’intégrité d’une ressource externe attendue ;
- authentification et sessions pour contrôler l’accès ;
- hashs et empreintes pour comparer des données sans les confondre avec du chiffrement.
Commencer par ce qui est observable
Avant d’ajouter des protections, il faut connaître les réponses HTTP réellement envoyées et les dépendances réellement chargées. Un en-tête présent dans un fichier de configuration mais absent de la réponse finale ne protège rien.
Le générateur d’en-têtes de sécurité aide à préparer une configuration, tandis que les guides suivants expliquent le rôle et les limites de chaque mécanisme.
Sécurité et confidentialité ne sont pas synonymes
Un site peut être correctement protégé contre de nombreuses attaques tout en collectant beaucoup de données. À l’inverse, une application Local First peut limiter les transferts de fichiers tout en devant appliquer de bonnes pratiques Web classiques.
Cette séparation est importante : la sécurité cherche à empêcher des actions non autorisées ; la confidentialité cherche notamment à limiter l’exposition et l’usage des données. Les deux se complètent, mais ne se remplacent pas.
Un ordre de travail raisonnable
Pour un site moderne, commencez par HTTPS et une configuration serveur saine. Vérifiez ensuite les en-têtes, introduisez une CSP progressivement, contrôlez les dépendances tierces, puis examinez les mécanismes d’authentification et de stockage des secrets.
La suite de cette collection détaille chacune de ces briques et fournit des liens vers les outils Bethemesh adaptés.
Partir d’un modèle de menace simple
Avant de choisir une protection, demandez-vous ce que vous essayez d’empêcher. Un site vitrine, une application avec comptes et un back-office exposent des risques différents. Quelques questions suffisent déjà à structurer le travail : quelles données sont sensibles ? quelles actions nécessitent une authentification ? quelles ressources viennent de tiers ? quelles pages peuvent être intégrées ailleurs ? quelles API sont accessibles depuis le navigateur ?
Cette démarche évite deux erreurs opposées : installer des mécanismes sans comprendre leur rôle, ou considérer qu’un site « peu important » n’a rien à protéger. Même une page statique peut servir des scripts tiers, être intégrée dans une iframe ou exposer des informations par ses en-têtes.