Ce que les clients d'un site web devraient aussi savoir — Utiliser le guide de l'IPA « Comment créer un site web sécurisé » comme checklist

Interrogée sur « la sécurité de notre site web, est-ce que ça va ? », peu d’entreprises peuvent répondre « oui » avec de véritables arguments à l’appui.

On croit souvent que tout va bien parce qu’on en a confié la réalisation à un prestataire, ou qu’un site de simple présentation d’entreprise n’intéresse pas les attaquants. Mais dès qu’il existe un seul formulaire de contact, un programme traite les données saisies, et si vous utilisez un CMS comme WordPress, l’écran d’administration comme les extensions constituent des surfaces d’attaque. Qui plus est, la plupart des attaques ne visent pas une entreprise en particulier : elles recherchent mécaniquement les sites les plus fragiles.

Alors, sur quels critères vérifier que « tout va bien » ? La référence officielle utilisée de longue date à cet effet est le document Comment créer un site web sécurisé de l’IPA (Information-technology Promotion Agency, agence japonaise de promotion des technologies de l’information).

Cet article présente ce que nous enseigne ce document, dans un langage accessible aussi bien au client qui passe commande d’un site web qu’à celui qui l’exploite.

1. L’essentiel en bref

• « Comment créer un site web sécurisé » est un document qui rassemble, à partir des vulnérabilités réellement signalées à l’IPA, 11 catégories de faiblesses des sites web et leurs contre-mesures. Il est utile non seulement aux développeurs, mais aussi comme référence pour la commande et la recette
• Les contre-mesures se répartissent entre « solution fondamentale » (qui élimine la cause) et « mesure de secours » (qui atténue les dégâts). La base est la solution fondamentale, à laquelle s’ajoutent les mesures de secours
• La « checklist de mise en œuvre de la sécurité » fournie peut être utilisée telle quelle comme liste de vérification lors de la commande auprès d’un prestataire et lors de la recette
• Le volume complémentaire « Spécification du bilan de santé d’un site web » sert de référence pour les points de contrôle lors de l’inspection périodique d’un site en exploitation
• Dans la pratique d’un site d’entreprise, les deux principaux risques concernent les parties qui reçoivent des saisies (formulaires, etc.) et l’exploitation du CMS (WordPress, etc.). Il convient de définir, dès la commande, une organisation d’exploitation qui ne s’arrête pas une fois le site livré

2. Qu’est-ce que « Comment créer un site web sécurisé » ?

« Comment créer un site web sécurisé » est un document que l’IPA a compilé à l’intention des développeurs et exploitants de sites web, en retenant, parmi les informations relatives aux vulnérabilités qui lui ont été signalées, celles qui ont fait l’objet du plus grand nombre de signalements ou dont l’impact est le plus important en cas d’attaque, ainsi que les contre-mesures correspondantes. La version la plus récente actuellement publiée est la 7e édition révisée, qui compte 115 pages au total. Le PDF diffusé est celui mis à jour le 31 mars 2021 au titre du 4e tirage. Outre le PDF, une page HTML est également publiée pour chaque vulnérabilité.

Il se compose de trois chapitres.

Par ailleurs, les documents suivants sont publiés indépendamment du corps principal.

• Checklist de mise en œuvre de la sécurité (format Excel) : un tableau permettant de vérifier si les contre-mesures du document principal ont été mises en œuvre
• Volume complémentaire « Comment appeler SQL en toute sécurité » : un document approfondissant les contre-mesures liées aux vulnérabilités autour des bases de données
• Volume complémentaire « Spécification du bilan de santé d’un site web » : une spécification regroupant 13 points de diagnostic pour évaluer un site en exploitation

Tous ces documents peuvent être téléchargés gratuitement depuis la page de l’IPA.

2.1. Comment juger de l’actualité du document

Avant d’utiliser ce document comme référence, il y a un point de contexte à connaître. La 7e édition révisée a été publiée en mars 2015 ; des corrections ont ensuite été apportées à chaque réimpression, et le PDF actuellement diffusé est le 4e tirage de la 7e édition, mis à jour le 31 mars 2021. À la date de rédaction de cet article (juillet 2026), aucune 8e édition n’a été publiée.

S’il reste malgré tout utilisable comme référence, c’est parce qu’il traite de faiblesses qui découlent de la manière même dont on construit une application web. Insérer des valeurs saisies dans une requête SQL ou dans du HTML, identifier une personne au moyen d’une session, envoyer un courriel à partir de la saisie d’un formulaire : ces mécanismes n’ont pas changé. Les 11 catégories de vulnérabilités et la distinction entre « solution fondamentale » et « mesure de secours » restent valables aujourd’hui comme critères de vérification d’une mise en œuvre.

À l’inverse, ce document ne peut pas couvrir l’évolution récente des menaces. Les attaques par rançongiciel, les intrusions passant par un partenaire commercial ou un sous-traitant, les risques liés à l’usage de l’IA générative : ces sujets n’ont jamais relevé de son périmètre. Il faut les compléter par des documents mis à jour chaque année.

Il n’est pas nécessaire de lire les trois documents séparément. Il suffit de répartir les rôles — « ce document pour les critères de mise en œuvre, les 10 principales menaces pour l’actualité des menaces, les directives pour l’organisation de l’entreprise » — et d’aller consulter uniquement celui dont on a besoin. Le contenu de l’édition 2026 des 10 principales menaces est traité dans notre article présentant les 10 principales menaces de sécurité de l’information 2026, et la version 4.0 des directives dans notre article présentant la version 4.0 des directives.

3. Lire les 11 vulnérabilités sous l’angle de « ce qui se produit »

Les 11 catégories de vulnérabilités traitées au chapitre 1 sont énoncées avec un vocabulaire technique destiné aux développeurs, mais si on les reformule en « ce qui se produit sur son propre site si on laisse faire », on comprend qu’elles ne concernent pas uniquement le prestataire, même du point de vue du client qui passe commande.

La colonne de droite donne des exemples d’endroits où ces vulnérabilités posent le plus souvent problème sur un site d’entreprise. Selon que votre site dispose ou non de la même fonctionnalité, vous pouvez repérer les lignes qui vous concernent.

Par exemple, « l’injection d’en-têtes de courriel » s’applique directement au formulaire de contact d’un simple site de présentation d’entreprise. Un formulaire mal protégé est détourné comme source de spams, ce qui nuit même à la réputation du domaine de l’entreprise (la question de savoir si ses courriels parviennent réellement à leurs destinataires). Comme évoqué dans Pourquoi les courriels du formulaire de contact ne sont pas délivrés, un formulaire dont les courriels cessent d’arriver se traduit directement par une perte d’opportunités commerciales.

4. « Solution fondamentale » et « mesure de secours » — comment penser les contre-mesures

Ce qui fait la force de ce document, c’est qu’il présente les contre-mesures selon deux catégories.

• Solution fondamentale : une mise en œuvre qui élimine la cause même de la vulnérabilité. Pour l’injection SQL, par exemple, construire les requêtes SQL avec des marqueurs de position plutôt que par concaténation de chaînes
• Mesure de secours : une contre-mesure qui réduit le taux de réussite ou l’impact d’une attaque lorsqu’une vulnérabilité subsiste. Par exemple, ne pas afficher tel quel un message d’erreur dans le navigateur

Cette distinction donne au client un repère pour évaluer les explications qu’on lui fournit sur la sécurité. Une explication du type « nous mettons en place un WAF (un dispositif qui détecte et bloque les attaques), vous pouvez être rassuré » relève de la mesure de secours : ce n’est pas un substitut à une solution fondamentale au niveau de l’application elle-même. À l’inverse, mettre en œuvre une solution fondamentale puis y superposer un WAF constitue une architecture cohérente. Le simple fait de distinguer de quel niveau on parle permet déjà de mieux juger de la pertinence d’une proposition.

5. Comment l’utiliser lors de la commande et de la recette

« Comment créer un site web sécurisé » est un document destiné aux développeurs, mais son intérêt pratique pour le client est qu’il peut servir de référence pour formuler des exigences et effectuer des vérifications.

• Au stade du devis et des exigences : ajouter au cahier des charges ou à l’appel d’offres une phrase du type « mettre en œuvre les contre-mesures pour les vulnérabilités listées dans le document IPA “Comment créer un site web sécurisé” ». Citer une référence précise rend l’exigence bien plus concrète qu’une formule vague comme « prendre en compte la sécurité »
• Au stade de la recette : demander la remise des résultats de vérification pour les points correspondants de la checklist de mise en œuvre de la sécurité
• Au stade du contrat : préciser par écrit qui assurera la mise à jour du CMS, des extensions et du serveur après la mise en ligne, et si la réponse à une vulnérabilité découverte ultérieurement relève du contrat de maintenance ou d’un devis distinct

Le troisième point est particulièrement important. La sécurité d’un site web n’est pas acquise une fois pour toutes au moment de sa construction : elle se maintient en suivant les nouvelles vulnérabilités découvertes après la mise en ligne. Cette question de « qui continue à s’en occuper » relève de la même logique que le périmètre de maintenance évoqué dans notre article sur les contrats de développement externalisé et de maintenance.

5.1. Exemple de rédaction pour un cahier des charges ou un appel d’offres

Avec la formule « prendre en compte la sécurité », rien ne détermine à partir de quand l’exigence est réputée satisfaite. En désignant le document de référence et les livrables attendus, l’exigence devient vérifiable. On peut par exemple écrire ceci.

Exigences de sécurité

1. L’application web objet du présent marché doit mettre en œuvre, pour chacune des vulnérabilités listées au chapitre 1 du document IPA « Comment créer un site web sécurisé, 7e édition révisée », les contre-mesures classées comme « solution fondamentale » dans ce même document.
2. À la livraison, le prestataire doit remettre le résultat de son auto-évaluation pour l’ensemble des points de la « checklist de mise en œuvre de la sécurité » fournie avec ce document. Pour les points jugés « sans objet », il doit en indiquer également la raison (fonctionnalité correspondante absente, etc.).
3. Pour les écrans comportant un traitement dynamique (formulaire de contact, recherche, connexion, téléchargement de fichiers, etc.), le document de conception doit préciser la manière dont les valeurs saisies sont traitées et la politique d’échappement appliquée en sortie.
4. Le contrat de maintenance doit préciser qui met à jour le cœur du CMS, le thème, les extensions et l’environnement d’exécution après la mise en ligne, et à quelle fréquence, ainsi que le délai de réaction et la prise en charge des coûts en cas de publication d’une vulnérabilité urgente.

Il n’est pas nécessaire d’inclure les quatre points dès le départ. Pour un site essentiellement vitrine, même avec les seuls points 1 et 2, la conversation au moment de la recette n’a plus rien à voir avec celle qui suit une commande passée sur un simple « je vous laisse gérer la sécurité ».

5.2. Ce que contient la checklist

La checklist tient dans un unique fichier Excel : elle aligne, par catégorie parmi les 11 vulnérabilités, les 47 points de mise en œuvre correspondant au chapitre 1 de « Comment créer un site web sécurisé, 7e édition révisée ». Chaque ligne comporte la catégorie de vulnérabilité, la nature de la contre-mesure (solution fondamentale ou mesure de secours), la case de vérification (traité / non traité / sans objet), l’énoncé du point de mise en œuvre et le numéro de la section correspondante du document principal.

Les points eux-mêmes sont formulés, par exemple, de la manière suivante.

(Les énoncés des points de mise en œuvre sont cités de la checklist de mise en œuvre de la sécurité fournie avec le document IPA « Comment créer un site web sécurisé, 7e édition révisée ».)

Ce qui rend la checklist commode pour le client, c’est la présence de la mention « sans objet » parmi les cases de vérification. Sur un site dépourvu de fonction de connexion, il est normal que les points relatifs à la gestion de session restent vides ; mais tant que rien n’est renseigné, on ne peut pas distinguer un « sans objet parce que la fonctionnalité n’existe pas » d’un simple oubli. Il suffit de demander que « sans objet » soit inscrit avec sa justification pour que la conversation de recette devienne concrète.

6. Faire un « bilan de santé » d’un site en exploitation

Pour un site déjà en ligne, le volume complémentaire « Spécification du bilan de santé d’un site web » est utile. Il s’agit d’une spécification regroupant des points de diagnostic (13 au total) pour vérifier la sécurité d’un site web en exploitation, qui sert aussi de repère quant au contenu à attendre d’un service de diagnostic de vulnérabilités.

Pour le site web d’une PME, dans la pratique, le risque tend à se concentrer particulièrement sur deux points.

• Les parties qui reçoivent des saisies : formulaire de contact, champ de recherche, connexion des membres, etc. La plupart des vulnérabilités du chapitre 1 concernent cet aspect
• L’exploitation du CMS : sur un site où les mises à jour du cœur, du thème ou des extensions d’un CMS comme WordPress se sont arrêtées, le scénario type est celui d’une faiblesse connue exploitée pour falsifier le site. Il est très fréquent que personne n’ait déterminé à qui incombent les mises à jour, et que le site soit tout simplement laissé à l’abandon

Si vous souhaitez repenser la charge de mise à jour du CMS en même temps que l’ensemble de l’organisation d’exploitation, notre article sur la migration depuis WordPress peut également vous être utile. Il existe aussi le choix de conception consistant à réduire d’emblée le traitement dynamique au profit d’une structure de site statique, ce qui réduit la surface d’attaque elle-même. Notre propre adoption d’une structure statique fondée sur le système de design de l’Agence numérique pour la réalisation de sites s’inscrit dans le prolongement de cette même logique.

Notons par ailleurs que l’exploitation sécurisée d’un site web figure aussi parmi les points de contrôle du self-diagnostic de la 4.0e édition des « Directives de sécurité de l’information pour les PME » de l’IPA. Pour situer ce point dans l’ensemble des mesures de sécurité d’une entreprise, consultez notre article présentant la 4.0e édition des directives.

7. Mini-glossaire

Voici, parmi les termes qui reviennent lors des réunions avec un prestataire, ceux que cet article a employés. Dès lors que l’on sait en donner le sens en une ligne, on peut juger soi-même, lorsqu’on reçoit une explication, s’il est question d’une solution fondamentale ou d’une mesure de secours.

Résumé

Récapitulons les points clés du document IPA « Comment créer un site web sécurisé ».

• Un document de référence (7e édition révisée, 115 pages) couvrant 11 catégories de faiblesses des sites web et leurs contre-mesures, fondé sur des vulnérabilités réellement signalées à l’IPA
• Les contre-mesures se répartissent en deux niveaux : solution fondamentale et mesure de secours. Une mesure de secours comme un WAF ne remplace pas une solution fondamentale
• Le client peut l’utiliser en citant nommément ce document dans ses exigences, en vérifiant la livraison à l’aide de la checklist, et en fixant contractuellement l’organisation des mises à jour après la mise en ligne
• Pour un site en exploitation, effectuer des contrôles périodiques en s’appuyant sur la « Spécification du bilan de santé d’un site web » comme référence
• Le risque réaliste pour le site d’une entreprise tend à se concentrer sur le traitement des saisies (formulaires, etc.) et sur un CMS laissé à l’abandon

La sécurité tend à se réduire à un choix binaire entre « dépenser ce que le prestataire recommande » ou « ne rien faire du tout ». Mais le simple fait de connaître des références publiques permet de formuler ses exigences et d’effectuer ses vérifications avec ses propres mots.

Vous envisagez de créer ou de refondre votre site web ?

Chez Komura Software LLC, lors de la création ou de la refonte d’un site web, nous formulons nos propositions en suivant la logique présentée dans cet article : mise en œuvre des formulaires, structure statique ne dépendant pas excessivement d’un CMS, et organisation des mises à jour après la mise en ligne. Nous pouvons également vous accompagner dès l’étape d’un simple état des lieux, si vous ne savez pas exactement où en est votre site actuel.

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Qu'est-ce que le document « Comment créer un site web sécurisé » ?

Il s'agit d'un document de sécurité publié par l'IPA (Information-technology Promotion Agency, agence japonaise de promotion des technologies de l'information), destiné aux développeurs et exploitants de sites web. Parmi les informations relatives aux vulnérabilités signalées à l'IPA, il retient celles qui ont fait l'objet du plus grand nombre de signalements ou dont l'impact potentiel est le plus important, et en explique les menaces et les contre-mesures. La 7e édition révisée, la plus récente, a été publiée en mars 2021 et compte 115 pages. Outre le document principal, une checklist de mise en œuvre de la sécurité ainsi que deux volumes complémentaires — « Comment appeler SQL en toute sécurité » et « Spécification du bilan de santé d'un site web » — sont mis à disposition gratuitement.

Un simple site vitrine de présentation d'entreprise a-t-il aussi besoin de mesures de sécurité ?

Oui. Dès qu'il existe un formulaire de contact, un programme traite les données saisies ; si vous utilisez un CMS comme WordPress, l'écran d'administration et les extensions constituent autant de surfaces d'attaque. Les attaquants ne choisissent pas nécessairement leurs cibles selon la taille de l'entreprise : ils recherchent mécaniquement les sites vulnérables et les détournent comme tremplins pour de la falsification, de la diffusion de virus ou de l'envoi de spams. Ce qui rend un site web dangereux, c'est que l'on peut être à la fois victime et, en même temps, causer du tort à ses partenaires commerciaux et à ses visiteurs.

Quelle est la différence entre une solution fondamentale et une mesure de secours ?

« Comment créer un site web sécurisé » présente les contre-mesures selon deux catégories. La solution fondamentale est une méthode de mise en œuvre qui élimine la cause même de la vulnérabilité (par exemple, utiliser des marqueurs de position plutôt que la concaténation de chaînes pour construire une requête SQL). La mesure de secours est une contre-mesure qui réduit le taux de réussite ou l'impact d'une attaque lorsqu'une vulnérabilité subsiste (par exemple, ne pas afficher tel quel un message d'erreur). Comme les mesures de secours seules laissent subsister la cause du problème, l'ordre correct consiste à considérer la solution fondamentale comme la base, et à y ajouter des mesures de secours.

Que faut-il vérifier en matière de sécurité lors de la commande auprès d'un prestataire ?

Nous recommandons de vérifier au minimum trois points dès l'étape du devis : (1) si les contre-mesures listées dans « Comment créer un site web sécurisé » sont mises en œuvre, (2) si les résultats de vérification peuvent être présentés à l'aide de la checklist de mise en œuvre de la sécurité ou d'un document équivalent, et (3) qui assurera la mise à jour du CMS et des extensions après la mise en ligne (autrement dit, si cela relève du périmètre du contrat d'exploitation et de maintenance). Ajouter des exigences de sécurité après coup entraîne souvent des reprises coûteuses ; il est donc important de les préciser par écrit avant la signature du contrat.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.