La sécurité web ne se résume ni à un cadenas HTTPS ni à un scan avant lancement. Une application expose du code, des identités, des données, des fournisseurs et des opérations ; un attaquant n’a besoin que d’un chemin exploitable entre ces éléments.
1. En bref : protéger les chemins, pas collectionner les outils
La cybersécurité web est l’ensemble des décisions de conception, développement et exploitation qui empêchent un utilisateur ou un système non autorisé de lire, modifier, supprimer, détourner ou rendre indisponible un service et ses données.
Elle se juge par scénarios : un client voit-il le dossier d’un autre en changeant un identifiant ? Un compte éditeur compromis autorise-t-il l’injection d’un script ? Une intégration est-elle capable de rejouer un paiement ? Une sauvegarde résiste-t-elle à la compromission du compte cloud ? L’équipe détecte-t-elle une extraction inhabituelle ?
Un WAF, un scanner et un pentest peuvent aider. Aucun ne remplace l’autorisation correcte, la minimisation des données, la revue des changements, la surveillance ni la restauration.
2. Chiffres clés : l’exploitation des failles devient une porte d’entrée majeure
| Donnée | Source et périmètre | Ce qu’elle permet de décider | Précaution |
|---|---|---|---|
| 31 % | Compromissions commençant par l’exploitation d’une vulnérabilité dans le Verizon DBIR 2026. | Prioriser composants exposés, failles exploitables et délai de correctif. | Le DBIR agrège des contributeurs mondiaux ; votre risque dépend de l’exposition. |
| +55 % | Hausse annuelle de cette voie d’accès selon Verizon. | Réduire la fenêtre entre divulgation, qualification et correction. | Une vulnérabilité non exposée n’a pas la même urgence qu’un service Internet activement attaqué. |
| 43 jours | Temps médian de résolution complète d’une vulnérabilité critique dans le même corpus DBIR 2026. | Mesurer le vrai délai découverte-correction, pas seulement la création du ticket. | La médiane mondiale n’est pas un objectif acceptable pour une faille exploitée. |
| 48 % | Compromissions impliquant un tiers, après une hausse annuelle de 60 %, Verizon 2026. | Inclure fournisseurs, scripts, plugins, API et accès de support dans le modèle de menace. | L’implication d’un tiers couvre des situations différentes. |
| 48 % | Compromissions impliquant un ransomware, Verizon DBIR 2026. | Préparer segmentation, sauvegardes séparées et reconstruction, même pour un service web. | « Implique » ne signifie pas que le site web était toujours le point d’entrée. |
| 4 875 incidents | Périmètre de l’ENISA Threat Landscape 2025, du 1er juillet 2024 au 30 juin 2025. | Utiliser un paysage européen récent pour les scénarios de disponibilité, données et fournisseurs. | Le corpus reflète les incidents connus de l’agence. |
| 3 586 événements | Événements traités par l’ANSSI en 2025, dont 1 366 incidents. | Prévoir remontée, qualification et coordination, pas seulement prévention. | Le périmètre ANSSI n’est pas l’ensemble des incidents français. |
| 6 167 violations | Notifications reçues par la CNIL en 2025 ; une sur deux relevait d’un piratage. | Relier sécurité technique, données personnelles, notification et sous-traitants. | Une notification couvre parfois des volumes et causes très différents. |
| 50 % | Part des contrôles et actions répressives que la CNIL prévoit de consacrer à la sécurité des données en 2026, CNIL. | Documenter les mesures et décisions, pas seulement déployer des outils. | Une priorité de contrôle ne préjuge pas d’une sanction. |
| 16 % | TPE-PME déclarant au moins un incident dans les douze mois, baromètre Cybermalveillance 2025. | Inclure les petites structures dans la préparation et tester les mesures de base. | Enquête déclarative : sous-détection et biais de mémoire sont possibles. |
| 3/4 | TPE-PME dépensant moins de 2 000 € en cybersécurité selon le même baromètre 2025. | Prioriser quelques contrôles à fort effet plutôt qu’un catalogue inaccessible. | Le budget déclaré ne mesure ni l’exposition ni l’efficacité. |
| 10 catégories | Périmètre de l’OWASP Top 10:2025. | Utiliser une base de sensibilisation pour les risques applicatifs. | L’OWASP rappelle que dix catégories ne couvrent pas tous les risques. |
Ces statistiques ne doivent pas servir à annoncer qu’« une PME sera attaquée ». Elles justifient une approche proportionnée : connaître l’exposition, protéger les chemins les plus rentables pour un attaquant et préparer la reprise.
3. Le trajet d’une attaque web : sept surfaces à fermer
3.1. Surface 1 — Exposition : ce qui répond sur Internet
Domaines oubliés, sous-domaines de test, consoles, API, buckets, ports et anciennes versions élargissent le périmètre sans toujours apparaître dans le CMS. Commencez par un inventaire vu de l’extérieur et rapprochez-le du registre interne.
Chaque actif reçoit propriétaire, environnement, technologie, données, authentification, criticité et date de retrait. Un service inconnu ne sera ni patché ni surveillé. Automatisez la découverte DNS et certificats, mais faites confirmer la finalité par une personne.
Réduisez l’exposition : administration derrière authentification forte et restriction adaptée, environnements de test non publics, messages d’erreur sobres, répertoires et sauvegardes non servis, stockage privé par défaut. Protégez domaine et registrar avec MFA, verrouillage et contacts maîtrisés.
Question d’exposition : un observateur externe découvre-t-il un actif que l’équipe ne sait pas attribuer en moins d’une heure ?
3.2. Surface 2 — Identité : comptes, sessions et récupération
L’authentification prouve une identité ; l’autorisation décide ce qu’elle a le droit de faire. Les failles les plus graves viennent souvent de la seconde. Ne faites jamais confiance à un identifiant, un rôle ou un prix envoyé par le navigateur.
Imposez MFA résistant au phishing lorsque le risque le justifie, bloquez mots de passe compromis, limitez essais, protégez récupération et évitez les comptes partagés. Les sessions doivent posséder durée, révocation, rotation après changement de privilège et cookies Secure, HttpOnly et SameSite adaptés.
Construisez une matrice rôle-action-objet. Testez horizontalement — un client vers un autre — et verticalement — un rôle faible vers une fonction d’administration. L’autorisation côté serveur s’applique à chaque requête et chaque objet.
Question d’autorisation : changer l’identifiant d’une URL, d’un champ caché ou d’un appel API retourne-t-il une donnée appartenant à un autre compte ?
3.3. Surface 3 — Logique métier : le code fait-il une chose autorisée de la mauvaise manière ?
Les scanners trouvent mieux certaines injections que les abus du processus. Un coupon réutilisé, un stock réservé indéfiniment, un remboursement négatif, un vote répété ou un workflow sauté peuvent utiliser des requêtes parfaitement valides.
Cartographiez les invariants : un paiement ne finance qu’une commande ; une approbation ne doit pas être donnée par son demandeur ; un quota ne descend pas sous zéro ; une transition exige l’état précédent. Faites appliquer ces règles côté serveur et, lorsque nécessaire, dans la base par contrainte ou transaction.
Protégez contre replay, concurrence et automatisation : idempotency keys, limitation, détection de vélocité, verrou adapté, expiration et confirmation indépendante. Le CAPTCHA ralentit parfois certains abus ; il ne garantit pas la règle métier.
Question de logique : que se passe-t-il si la même action est envoyée deux fois, dans le désordre, très vite ou avec une valeur extrême ?
3.4. Surface 4 — Données : collecter moins, cloisonner mieux, sortir proprement
Inventoriez les données réellement nécessaires, leur finalité, durée, sensibilité et destinataires. La minimisation réduit simultanément risque cyber, charge RGPD et impact d’un incident.
Chiffrez en transit et au repos selon le contexte, mais protégez surtout les clés et les accès. Séparez environnements ; les données de production ne doivent pas être copiées dans un test sans justification et transformation. Utilisez requêtes paramétrées, validation de schéma, encodage au bon contexte et politique stricte d’upload.
Journalisez les accès sensibles et les exports. Une extraction de dix millions de lignes ne doit pas ressembler à une consultation normale. Préparez suppression, restitution et notification avec le DPO ; les obligations ne se découvrent pas pendant la crise.
Question de traçabilité : l’entreprise sait-elle expliquer qui a exporté quelles données, quand et par quel chemin ?
3.5. Surface 5 — Chaîne logicielle : dépendances, build et fournisseurs
Le site intègre code open source, packages, images, plugins, scripts marketing, polices, CDN et API. Le tiers n’est pas extérieur au produit : il s’exécute parfois avec ses privilèges et ses données.
Conservez inventaire des composants, verrouillez versions, protégez registres et CI/CD, signez ou vérifiez les artefacts selon le risque, puis séparez droits de build et production. Analysez dépendances avant fusion et régulièrement après, car une version saine aujourd’hui risque de recevoir une vulnérabilité demain.
Pour les scripts tiers, demandez finalité, données, propriétaire, alternatives et plan de retrait. Une balise ajoutée pour une campagne reste parfois plusieurs années. Content Security Policy, Subresource Integrity dans les cas adaptés et réduction des domaines autorisés limitent certains scénarios.
Le NIST SSDF organise les pratiques autour de préparation, protection, production sécurisée et réponse. Il fournit une base de programme ; le modèle de menace choisit la profondeur nécessaire.
Test utile : une dépendance critique compromise peut-elle atteindre les secrets de production ou publier sans seconde approbation ?
3.6. Surface 6 — Exploitation : configuration, détection et restauration
Un code robuste risque d’être affaibli par une clé exposée, une console ouverte, un bucket public ou une règle réseau trop large. Versionnez l’infrastructure, définissez des baselines et détectez les dérives.
Centralisez les journaux utiles : authentifications, refus d’accès, changements de rôle, administration, exports, erreurs, WAF et déploiements. Protégez leur intégrité, synchronisez les horloges et fixez une rétention. Une alerte doit indiquer quoi vérifier, pas seulement qu’un seuil abstrait a bougé.
Les sauvegardes doivent être séparées, protégées et restaurées. Préparez un environnement propre, les dépendances et l’ordre de reconstruction. Le ransomware ne se résout pas avec une copie inaccessible ou contaminée.
Test utile : l’équipe peut-elle détecter un compte administrateur se connectant d’un nouveau pays puis exportant toutes les données ?
3.7. Surface 7 — Réponse : décider sous pression
Le plan précise responsable d’incident, suppléant, canaux hors bande, prestataires, juridique, DPO, assureur et autorités pertinentes. Il contient des critères de sévérité et des pouvoirs : couper une fonction, révoquer des sessions, isoler une intégration, restaurer ou informer.
Préservez les preuves avant de nettoyer. Documentez chronologie, décisions et impact. Une communication régulière, factuelle et sans cause prématurée protège mieux la confiance qu’un silence suivi d’une certitude fragile.
Après restauration, corrigez la cause et les facteurs contributifs. Le contre-test doit démontrer que le chemin a été fermé sans casser le service. Partagez les apprentissages avec produit, développement et exploitation.
Test utile : lors d’un exercice, combien de temps faut-il pour réunir les décideurs, révoquer les accès et confirmer une restauration ?
4. Tests de sécurité web : produire une preuve, pas un volume de constats
Le scanner détecte. La revue contextualise. Le pentest enchaîne. Le contre-test confirme.
Ces quatre opérations n’ont ni la même couverture ni le même objectif : l’analyse automatisée traite rapidement des familles connues, la revue examine architecture et logique, le test d’intrusion tente d’exploiter des chemins sur un périmètre défini, puis le contre-test vérifie que la correction ferme effectivement le scénario sans créer une nouvelle régression.
Un rapport utile distingue l’observation, la condition d’exploitation, l’impact, la preuve reproductible et la recommandation. Il évite d’additionner cent informations faibles pour produire un « score de risque » impressionnant. La direction doit surtout savoir quels chemins sont ouverts, quelles pertes deviennent plausibles et quelle décision réduit le risque dans le délai compatible avec l’exposition.
Le périmètre compte. Beaucoup. Une API non testée, un rôle oublié ou un environnement exclu restent hors conclusion. Le commanditaire doit donc comparer inventaire réel, échantillon retenu et limites avant d’interpréter une absence de découverte comme une absence de vulnérabilité.
5. Mesures minimales selon le risque du service
| Niveau | Exemple | Socle attendu | Assurance supplémentaire |
|---|---|---|---|
| Faible | Site éditorial sans compte ni donnée sensible. | MFA admin, mises à jour, sauvegarde, HTTPS, contrôle domaine, formulaires protégés, logs. | Scan régulier et revue des scripts tiers. |
| Modéré | Site de leads, CMS multi-auteurs, CRM. | Socle faible + rôles, anti-abus, gestion secrets, environnement test, supervision et procédure de violation. | Revue de code ciblée, tests d’autorisation et exercice. |
| Élevé | E-commerce, portail client, données personnelles importantes. | SDLC sécurisé, modèle de menace, segmentation, journaux, restauration, surveillance, gestion fournisseur. | Pentest indépendant avant lancement majeur et après changement critique. |
| Critique | Paiement complexe, santé, infrastructure ou droits sensibles. | Contrôles élevés + exigences sectorielles, redondance, équipe réponse et traçabilité forte. | Audits réguliers, red team adaptée, tests de crise et supervision renforcée. |
La classification ne dépend pas de la taille de l’entreprise. Un petit service est susceptible de traiter des données sensibles ou de concentrer tout le revenu.
6. Méthode recommandée : intégrer la sécurité aux quatre décisions produit
6.1. Cadrage — définir les pertes inacceptables
Identifiez actifs, attaquants plausibles, chemins, impact et obligations. Le livrable est un modèle de menace lisible par la direction, relié au backlog et aux critères de risque accepté.
6.2. Conception — supprimer ou contenir les chemins
Minimisez données et privilèges, choisissez des services éprouvés, dessinez frontières, modes dégradés et journaux. Faites une revue d’architecture avant que les choix coûteux deviennent irréversibles.
6.3. Delivery — empêcher les régressions
Ajoutez critères de sécurité aux stories, revues, tests unitaires et d’intégration, analyse de code/dépendances et contrôle des secrets. Les outils détectent ; une personne qualifie l’exploitabilité et le contexte.
6.4. Exploitation — prouver que le contrôle tient
Surveillez, testez les alertes, restaurez, appliquez les correctifs et révisez les droits. Suivez exposition et risque résiduel, pas le seul nombre de vulnérabilités ouvertes.
7. Prioriser les vulnérabilités sans se noyer
La sévérité technique n’est qu’une entrée. Utilisez au minimum : exploitabilité connue, exposition Internet, privilège requis, sensibilité des données, impact métier, contrôles compensatoires et difficulté de correction.
| Situation | Priorité | Décision |
|---|---|---|
| Faille exploitée, composant exposé, chemin confirmé | Urgence | Isoler ou corriger immédiatement, surveiller les signes d’exploitation. |
| Critique théorique, fonction désactivée ou non atteignable | Haute mais contextualisée | Vérifier la non-exposition, planifier le correctif et documenter l’exception. |
| Faible score, mais permet l’accès à un objet sensible | Haute | Corriger l’autorisation ; le score générique sous-estime la logique métier. |
| Dépendance sans correctif, usage remplaçable | Réduction d’exposition | Désactiver, filtrer, isoler ou remplacer ; suivre la publication du correctif. |
| Information sans chemin d’impact | Basse | Regrouper, corriger dans la maintenance, éviter le bruit d’alerte. |
Le délai médian de 43 jours du DBIR ne doit pas devenir une norme. Une faille activement exploitée exige parfois une réponse en quelques heures ; une mise à jour risquée et non exposée nécessite un test maîtrisé.
8. Conseils Logiks : le socle de départ pour une PME
- posséder domaines, comptes cloud et dépôts ;
- MFA et comptes nominatifs pour administration, email et code ;
- inventaire des actifs exposés et des versions ;
- sauvegarde séparée avec restauration trimestrielle ;
- procédure accélérée pour vulnérabilité exploitée ;
- tests d’autorisation sur chaque rôle ;
- journalisation des accès sensibles, exports et changements ;
- exercice annuel d’incident avec direction, technique et DPO.
Ce socle ne remplace pas l’analyse propre au service. Il crée une base que l’entreprise sait réellement maintenir.
9. Feuille de route 30 / 60 / 90 jours
9.1. Jours 1 à 30 — Voir l’exposition
- inventorier domaines, applications, API, comptes et fournisseurs ;
- classer données et parcours critiques ;
- corriger accès orphelins, MFA, sauvegardes et actifs de test exposés ;
- construire trois scénarios de menace prioritaires ;
- nommer propriétaire et risque accepté.
9.2. Jours 31 à 60 — Fermer les chemins probables
- tester authentification, autorisation, upload, intégrations et logique métier ;
- traiter vulnérabilités exploitables et dépendances critiques ;
- sécuriser CI/CD, secrets et administration ;
- installer journaux et alertes ;
- documenter déploiement, rollback et restauration.
9.3. Jours 61 à 90 — Éprouver la réponse
- réaliser un pentest ciblé si le niveau le justifie ;
- contre-tester les corrections ;
- restaurer une sauvegarde isolée ;
- simuler compromission d’un compte et extraction ;
- inscrire sécurité et dette dans la revue produit mensuelle.
10. FAQ
10.1. Comment sécuriser un site web ?
Commencez par l’inventaire, les comptes administrateurs, les mises à jour, les sauvegardes testées, les droits, les formulaires et les journaux. Ajoutez ensuite modèle de menace, tests de logique métier, sécurité du delivery et réponse selon les données et la criticité.
10.2. Un certificat HTTPS suffit-il ?
Non. HTTPS protège le transport entre navigateur et serveur. Il ne corrige ni autorisation cassée, injection, compte compromis, données excessives, dépendance vulnérable ni sauvegarde inutilisable.
10.3. Faut-il faire un pentest ?
Oui pour une application à risque, avant une ouverture importante, après un changement sensible ou lorsqu’une exigence l’impose. Le pentest échantillonne un périmètre à une date ; il complète le développement sécurisé et l’exploitation, sans les remplacer.
10.4. À quelle vitesse corriger une vulnérabilité ?
Selon exploitation, exposition et impact. Une faille Internet activement exploitée exige parfois une isolation ou une correction immédiate. Définissez des cibles par risque, mesurez de la détection au déploiement et documentez les exceptions.
10.5. Qui est responsable de la sécurité dans le cloud ?
Le fournisseur protège les couches définies par son service ; le client reste responsable de nombreux réglages, identités, données, application et usages. La frontière varie entre IaaS, PaaS et SaaS et doit être écrite.
10.6. Quelle différence avec un audit de cybersécurité ?
Le service de cybersécurité met en place et exploite des protections. L’audit examine un périmètre, collecte des preuves et formule des constats indépendants à un moment donné. L’un construit ; l’autre évalue.
11. Conclusion
La cybersécurité web consiste à empêcher qu’un chemin technique devienne une perte métier. Elle commence par ce qui est exposé, traverse identités, règles, données et fournisseurs, puis se vérifie dans l’exploitation et la réponse.
La meilleure défense n’est pas la plus longue liste d’outils. C’est un petit nombre de contrôles reliés à des scénarios, possédés par des personnes et régulièrement testés.
12. Sources principales
- Verizon — Data Breach Investigations Report 2026, mai 2026.
- Verizon — Infographie PME DBIR/BIS 2026, juin 2026.
- ENISA — Threat Landscape 2025, octobre 2025, révision janvier 2026.
- ANSSI — Panorama de la cybermenace 2025, mars 2026.
- CNIL — Rapport annuel 2025, mai 2026.
- Cybermalveillance.gouv.fr — Baromètre de maturité cyber des TPE-PME 2025, octobre 2025.
- Cybermalveillance.gouv.fr — Rapport d’activité et état de la menace 2025, mars 2026.
- OWASP — Top 10:2025, consulté le 13 juillet 2026.
- NIST — Secure Software Development Framework 1.1, consulté le 13 juillet 2026.
- CNIL — Guide RGPD du développeur, mis à jour janvier 2025.