asset 1
asset 2
asset 3
asset 2
asset 21

Sécurité web : ce que protège votre hébergeur… et ce que vous devez protéger vous-même

24 octobre 2025

Un site sécu­ri­sé repose autant sur l’infrastructure de son héber­geur que sur la vigi­lance de son pro­prié­taire. Entre le ser­veur, le code du site et la mes­sa­ge­rie, cha­cun joue un rôle essen­tiel pour évi­ter pira­tages, pertes de don­nées ou usur­pa­tions. Décryp­tons ensemble les grands piliers de la sécu­ri­té web.

Comprendre les grands piliers de la sécurité web

Un site web, ce n’est pas seule­ment des pages visibles sur Inter­net : c’est aus­si un ensemble de don­nées, de fichiers et d’échanges qu’il faut pro­té­ger au quo­ti­dien. Et contrai­re­ment à ce qu’on pour­rait croire, la sécu­ri­té d’un site ne dépend pas uni­que­ment de son héber­geur : elle se construit à plu­sieurs niveaux.

Un héber­geur fiable assure la pro­tec­tion du ser­veur, du réseau et des don­nées sto­ckées. Un site bien entre­te­nu garan­tit la sécu­ri­té de son conte­nu et des uti­li­sa­teurs. Et la mes­sa­ge­rie, sou­vent oubliée, joue un rôle essen­tiel dans la pré­ven­tion du phi­shing et de l’usurpation d’identité.

La sécu­ri­té web n’est donc pas une fonc­tion unique, mais une com­bi­nai­son de pro­tec­tions com­plé­men­taires qui, ensemble, garan­tissent la confiance des visi­teurs et la sta­bi­li­té du site.

Dans cet article, nous allons par­cou­rir les trois grands axes de la sécu­ri­té web : héber­geur, site et mes­sa­ge­rie. Voir com­ment ils se com­plètent, et com­prendre à quelles menaces cha­cun répond.

Schéma présentant les trois piliers de la sécurité web : hébergeur, site web et messagerie, interconnectés par des flèches symbolisant leur interdépendance.
Les trois piliers de la sécu­ri­té web : héber­geur, site web et mes­sa­ge­rie. Cha­cun joue un rôle com­plé­men­taire dans la pro­tec­tion d’un site.

Sécurité côté hébergeur : protéger l’environnement technique et les données hébergées

Un héber­geur web joue un rôle fon­da­men­tal dans la sécu­ri­té d’un site : il gère le ser­veur, l’infrastructure réseau et la pro­tec­tion des don­nées sto­ckées. Son objec­tif : garan­tir un envi­ron­ne­ment stable, iso­lé et résis­tant face aux attaques.

1. Un environnement serveur sécurisé

Un héber­geur doit en pre­mier lieu pro­té­ger ses ser­veurs phy­siques et logiciels :

  • Iso­la­tion des comptes : chaque site héber­gé doit être sépa­ré des autres, afin qu’une faille sur l’un ne com­pro­mette pas les fichiers d’un autre.
  • Mises à jour et cor­rec­tifs : les logi­ciels sys­tème (PHP, MariaDB/MySQL, etc.) doivent être main­te­nus à jour pour éli­mi­ner les failles connues.
  • Pare-feu appli­ca­tif (WAF) : il filtre en amont les attaques cou­rantes (injec­tions SQL, XSS, ten­ta­tives de connexion massives).
  • Sur­veillance conti­nue : des sys­tèmes d’alerte détectent les ano­ma­lies, les pics de charge ou les scripts suspects.

Chez o2switch, l’isolation repose sur le sys­tème Mon Uni­vers Web, qui per­met de créer plu­sieurs “lunes” tota­le­ment indé­pen­dantes les unes des autres au sein d’un même hébergement.

2. Sauvegardes et redondance

La sécu­ri­té ne se limite pas à pré­ve­nir les attaques : il faut aus­si pou­voir res­tau­rer les don­nées en cas de pro­blème. Un héber­geur fiable assure :

  • Des sau­ve­gardes auto­ma­tiques et régu­lières.
  • Une redon­dance maté­rielle (RAID, ser­veurs miroirs).
  • Des pro­cé­dures de res­tau­ra­tion rapides en cas de défaillance.

Ces méca­nismes assurent la conti­nui­té de ser­vice même en cas de panne, d’erreur ou de sup­pres­sion accidentelle.

3. Chiffrement et certificats SSL

La sécu­ri­sa­tion des échanges entre le navi­ga­teur du visi­teur et le site repose sur un cer­ti­fi­cat SSL/TLS.

  • Il authen­ti­fie le ser­veur : le navi­ga­teur sait qu’il s’adresse bien au bon site.
  • Il chiffre les don­nées échan­gées (for­mu­laires, paie­ments, identifiants).
  • Il per­met d’afficher le cade­nas HTTPS dans la barre d’adresse.

De nom­breux héber­geurs, dont o2switch, intègrent aujourd’hui Let’s Encrypt, un ser­vice qui délivre gra­tui­te­ment et renou­velle auto­ma­ti­que­ment les cer­ti­fi­cats SSL.

4. Performances, référencement et sécurité vont de pair

Un héber­ge­ment bien confi­gu­ré amé­liore à la fois la vitesse, la sta­bi­li­té et la pro­tec­tion du site.
Un ser­veur per­for­mant réduit les risques d’erreur et de sur­charge, tan­dis qu’un envi­ron­ne­ment sécu­ri­sé limite les failles et les inter­rup­tions de ser­vice.
Ces deux aspects ont un impact direct sur le réfé­ren­ce­ment natu­rel : un site rapide et fiable est mieux per­çu par les moteurs de recherche, alors qu’un site lent, instable ou pira­té peut voir sa visi­bi­li­té chuter.

En pra­tique, la per­for­mance tech­nique et la sécu­ri­té ne s’opposent pas : elles se ren­forcent mutuellement.

Les principaux mécanismes de sécurité côté hébergeur

Méca­nismeObjec­tifRisque évi­té
Iso­la­tion des comptesCloi­son­ner les sites hébergésConta­mi­na­tion croisée
Mises à jour serveurCor­ri­ger les failles systèmeExploi­ta­tion de vulnérabilités
Pare-feu (WAF)Fil­trer les requêtes malveillantesAttaques auto­ma­ti­sées
Sau­ve­gardes automatiquesRes­tau­rer les donnéesPerte, sup­pres­sion, ransomware
Cer­ti­fi­cat SSL / HTTPSChif­frer les échangesInter­cep­tion de données
Redon­dance matérielleMain­te­nir la disponibilitéPanne ser­veur

Sécurité côté site web : protéger le contenu, le code et les accès utilisateurs

Même si l’hébergeur assure une grande par­tie de la sécu­ri­té ser­veur, la pro­tec­tion du site lui-même reste sous la res­pon­sa­bi­li­té de son pro­prié­taire.
Un site mal entre­te­nu, un mot de passe faible ou une appli­ca­tion obso­lète peuvent suf­fire à com­pro­mettre l’ensemble.

1. Maintenir son site à jour

C’est la pre­mière règle de sécurité.

  • Mettre à jour le CMS ou la solu­tion uti­li­sée dès qu’une nou­velle ver­sion est disponible.
  • Actua­li­ser les modules, thèmes ou exten­sions selon la tech­no­lo­gie employée.
  • Sup­pri­mer les élé­ments inutiles : anciens scripts, outils de test ou fichiers lais­sés après une refonte.

Les failles connues sont sou­vent exploi­tées auto­ma­ti­que­ment : un site non à jour devient une cible facile.

2. Sécuriser les accès et les comptes utilisateurs

  • Uti­li­ser des mots de passe forts et uniques, idéa­le­ment gérés via un ges­tion­naire de mots de passe.
  • Acti­ver, quand c’est pos­sible, l’authentification à deux fac­teurs (2FA) pour les comptes sensibles.
  • Limi­ter le nombre de comptes admi­nis­tra­teurs et attri­buer des droits adap­tés selon les besoins.

La majo­ri­té des pira­tages pro­vient de mots de passe faibles ou réutilisés.

3. Vérifier régulièrement l’état de son site

Même avec un bon héber­ge­ment, un site n’est jamais tota­le­ment à l’abri d’un pro­blème tech­nique ou d’une ten­ta­tive d’intrusion. Pre­nez l’habitude de le consul­ter régu­liè­re­ment, comme le ferait un visiteur :

  • Tes­ter les pages prin­ci­pales et les formulaires.
  • Véri­fier que les liens et les images s’affichent correctement.
  • De temps à autre, ana­ly­ser votre site avec un outil en ligne comme Sucu­ri Site­Check pour détec­ter d’éventuelles anomalies.

Vous pou­vez aus­si ins­tal­ler une exten­sion de sécu­ri­té : elle sur­veille les connexions, bloque les attaques les plus cou­rantes et alerte en cas de com­por­te­ment sus­pect. C’est une façon simple de ren­for­cer la pro­tec­tion du site sans ajou­ter de complexité.

4. Sauvegarder régulièrement

Avoir une copie de secours récente est indis­pen­sable pour pou­voir res­tau­rer le site en cas d’incident.
Il est conseillé de com­bi­ner les sau­ve­gardes auto­ma­tiques de l’hébergeur avec une copie externe (cloud, disque dur ou autre ser­veur).
Et sur­tout, de tes­ter la res­tau­ra­tion de temps à autre pour s’assurer que la sau­ve­garde est bien exploitable.

Une sau­ve­garde n’a de valeur que si elle peut être res­tau­rée facilement.

Les bonnes pratiques pour sécuriser son site

Bonne pra­tiqueObjec­tifRisque évi­té
Mises à jour régulièresCor­ri­ger les failles connuesExploi­ta­tion automatique
Sécu­ri­sa­tion des accèsBlo­quer les intrusionsVol de compte
Véri­fi­ca­tion du siteDétec­ter les anomaliesFichiers ou scripts malveillants
Sau­ve­gardes externesRes­tau­rer en cas d’incidentSup­pres­sion ou infection
Exten­sion de sécuritéSur­veiller et alerterAttaques répé­tées

Sécurité côté messagerie : sécuriser les échanges e‑mail au niveau du nom de domaine

La mes­sa­ge­rie est sou­vent le maillon faible de la sécu­ri­té web. Pour­tant, elle joue un rôle essen­tiel : un domaine mal confi­gu­ré peut être uti­li­sé pour envoyer de faux mes­sages, trom­per les des­ti­na­taires ou pro­pa­ger des logi­ciels mal­veillants. Sécu­ri­ser ses e‑mails, c’est donc pro­té­ger à la fois son iden­ti­té de domaine et ses échanges.

1. Authentifier les e‑mails envoyés depuis votre domaine

Trois pro­to­coles per­mettent de véri­fier qu’un mes­sage a bien été émis par un ser­veur autorisé :

  • SPF (Sen­der Poli­cy Fra­me­work) : indique quelles adresses ou ser­veurs sont auto­ri­sés à envoyer des e‑mails pour votre domaine.
  • DKIM (Domain­Keys Iden­ti­fied Mail) : ajoute une signa­ture numé­rique au mes­sage, prou­vant qu’il n’a pas été modi­fié pen­dant la trans­mis­sion.
  • DMARC (Domain-based Mes­sage Authen­ti­ca­tion, Repor­ting and Confor­mance) : com­bine les deux pré­cé­dents et pré­cise ce que doit faire le ser­veur du des­ti­na­taire si le mes­sage semble fal­si­fié (le reje­ter, le signa­ler, etc.).

Ces trois pro­to­coles sont com­plé­men­taires : ensemble, ils réduisent for­te­ment le risque d’usurpation et de phishing.

2. Chiffrer la connexion à votre messagerie

Que vous consul­tiez vos e‑mails via un logi­ciel (Out­look, Thun­der­bird) ou sur votre télé­phone, la connexion au ser­veur doit être chif­frée. L’accès se fait alors en IMAP, POP ou SMTP sécu­ri­sé (SSL/TLS), empê­chant toute inter­cep­tion des iden­ti­fiants ou du conte­nu des mes­sages.
Les para­mètres de connexion four­nis par l’hébergeur pré­cisent tou­jours les ports sécu­ri­sés à utiliser.

3. Filtrer les spams et les virus

Les ser­veurs de mes­sa­ge­rie intègrent géné­ra­le­ment un fil­trage anti­spam et anti­vi­rus.
Il bloque la majo­ri­té des mes­sages sus­pects avant qu’ils n’arrivent dans la boîte de récep­tion.
Ces filtres ne sont pas infaillibles : il reste impor­tant de res­ter vigi­lant, sur­tout face aux liens ou pièces jointes inattendus.

4. Bonnes pratiques côté utilisateur

Quelques réflexes simples ren­forcent encore la sécu­ri­té des échanges :

  • Uti­li­ser des mots de passe forts et uniques pour chaque compte de messagerie.
  • Ne pas cli­quer sur les liens ou pièces jointes d’un mes­sage douteux.
  • Chan­ger le mot de passe immé­dia­te­ment en cas de com­por­te­ment inha­bi­tuel (erreurs d’envoi, mes­sages incon­nus dans les “Élé­ments envoyés”).
  • Évi­ter de par­ta­ger ses iden­ti­fiants de mes­sa­ge­rie, même temporairement.

Les protections à mettre en place pour sa messagerie

Mesure de sécu­ri­téObjec­tifRisque évi­té
SPFAuto­ri­ser uni­que­ment cer­tains ser­veurs d’envoiUsur­pa­tion d’identité
DKIMSigner numé­ri­que­ment les messagesAlté­ra­tion du contenu
DMARCDéfi­nir les règles en cas de mes­sage suspectPhi­shing, spam
Connexion sécu­ri­sée (SSL/TLS)Chif­frer les échangesInter­cep­tion des données
Fil­trage anti­spam / antivirusBlo­quer les e‑mails malveillantsMal­ware, phishing

Attaques les plus courantes et protections associées

Les menaces en ligne évo­luent sans cesse, mais la majo­ri­té des attaques repose sur des tech­niques bien connues. Savoir les iden­ti­fier per­met de com­prendre l’importance des pro­tec­tions mises en place par l’hébergeur et des bonnes pra­tiques côté utilisateur.

1. Brute-force ou force brute

Une attaque qui consiste à tes­ter auto­ma­ti­que­ment des mil­liers de com­bi­nai­sons pour devi­ner un mot de passe.
Pro­tec­tion : mots de passe forts, limi­ta­tion du nombre de ten­ta­tives de connexion, authen­ti­fi­ca­tion à deux facteurs.

2. Injection SQL

L’attaquant exploite un champ de for­mu­laire ou une faille de code pour exé­cu­ter des com­mandes dans la base de don­nées.
Pro­tec­tion : mises à jour du CMS et des exten­sions, fil­trage des entrées, pare-feu appli­ca­tif (WAF).

3. Phishing et usurpation d’identité

Des e‑mails imitent une entre­prise ou un ser­vice pour inci­ter le des­ti­na­taire à cli­quer sur un lien frau­du­leux ou à divul­guer ses iden­ti­fiants.
Pro­tec­tion : pro­to­coles SPF, DKIM et DMARC, vigi­lance face aux liens sus­pects, fil­trage antispam.

4. Malware et scripts malveillants

Des fichiers infec­tés peuvent être ajou­tés au site ou trans­mis par e‑mail pour voler des don­nées ou redi­ri­ger les visi­teurs.
Pro­tec­tion : ana­lyse régu­lière du site, fil­trage anti­vi­rus, sup­pres­sion des fichiers suspects.

5. Attaques par déni de service (DDoS)

Des mil­liers de requêtes simul­ta­nées saturent un ser­veur pour le rendre indis­po­nible.
Pro­tec­tion : infra­struc­ture redon­dante, fil­trage réseau, pare-feu au niveau de l’hébergeur.

6. Interception des données (attaque « man-in-the-middle »)

Un pirate inter­cepte les échanges entre le navi­ga­teur et le ser­veur pour récu­pé­rer des iden­ti­fiants ou infor­ma­tions sen­sibles.
Pro­tec­tion : chif­fre­ment SSL/TLS et for­çage du HTTPS.

Les principales attaques et leurs parades

Type d’attaqueCiblePro­tec­tion asso­ciéeGérée par
Brute-forceSite / accès admin2FA, blo­cage IPClient
Injec­tion SQLBase de donnéesMises à jour, WAFLes deux
Phi­shingMes­sa­ge­rieSPF, DKIM, DMARCLes deux
Mal­ware / scriptSite ou mailFil­trage, sup­pres­sion, analyseLes deux
DDoSSer­veurFil­trage réseau, redondanceHéber­geur
Inter­cep­tion de donnéesRéseauSSL/TLS, HTTPSLes deux

Mais pourquoi avoir piraté mon site ?

C’est sou­vent la pre­mière ques­tion que l’on se pose après une intru­sion. On ima­gine qu’un site doit conte­nir des don­nées sen­sibles pour inté­res­ser un pirate, mais c’est rare­ment le cas. La plu­part des attaques sont auto­ma­ti­sées : des robots par­courent le web à la recherche de failles connues.
Si votre site en pré­sente une, il devient une cible par­mi des mil­liers d’autres, sans avoir été choi­si spé­ci­fi­que­ment. Quelques rai­sons fréquentes :

  • Exploi­ter les res­sources de l’hébergement : envoyer du spam, héber­ger des fichiers mal­veillants ou relayer des attaques vers d’autres sites.
  • Mani­pu­ler le réfé­ren­ce­ment : ajou­ter des pages cachées, des redi­rec­tions ou des liens vers des sites frauduleux.
  • Ins­tal­ler une porte déro­bée : gar­der un accès per­ma­nent pour lan­cer de futures attaques ou revendre cet accès à d’autres.
  • Détour­ner l’affichage du site : rem­pla­cer la page d’accueil, affi­cher un mes­sage ou un conte­nu choquant.
  • Récu­pé­rer des infor­ma­tions : adresses e‑mail, for­mu­laires, fichiers clients, listes d’abonnés… ces don­nées peuvent être reven­dues ou réutilisées.

En résu­mé, un site pira­té n’est pas for­cé­ment visé pour ce qu’il contient, mais pour ce qu’il per­met de faire : héber­ger, pro­pa­ger, redi­ri­ger, ou ser­vir de point d’appui. C’est pour­quoi il est essen­tiel d’appliquer les bonnes pra­tiques de sécu­ri­té, même sur un site vitrine.

Et si l’attaque venait de la messagerie ?

Un pira­tage ne passe pas tou­jours par le site web. Les adresses e‑mail liées à un nom de domaine peuvent, elles aus­si, être com­pro­mises. Un compte de mes­sa­ge­rie volé per­met d’envoyer du spam, de dif­fu­ser des liens mal­veillants ou d’usurper votre iden­ti­té auprès de vos contacts. Les failles les plus exploi­tées sont :

  • Un mot de passe faible ou réuti­li­sé.
  • Une connexion non chif­frée à la messagerie.
  • L’absence de pro­to­coles d’authentification comme SPF, DKIM et DMARC.

Ces méca­nismes, cor­rec­te­ment confi­gu­rés, indiquent aux ser­veurs de récep­tion que vos mes­sages sont bien envoyés depuis des sources auto­ri­sées. Ils réduisent for­te­ment les risques d’usurpation et amé­liorent la répu­ta­tion du domaine.
Une mes­sa­ge­rie bien confi­gu­rée contri­bue ain­si à la fia­bi­li­té glo­bale de votre pré­sence en ligne, tout autant qu’un site cor­rec­te­ment protégé.

Sécurité web : une responsabilité partagée

La sécu­ri­té d’un site web repose sur une double vigi­lance. L’hébergeur assure la pro­tec­tion de l’environnement tech­nique, tan­dis que le pro­prié­taire du site doit veiller à la main­te­nance, aux accès et aux bonnes pra­tiques quo­ti­diennes. Ces deux niveaux se com­plètent pour garan­tir la sta­bi­li­té, la confi­den­tia­li­té et la fia­bi­li­té du site.

Ce que fait l’hébergeur

  • Isole les comptes pour évi­ter qu’un site com­pro­mis n’en conta­mine un autre.
  • Main­tient à jour les com­po­sants ser­veur (PHP, base de don­nées, pare-feu, antivirus).
  • Met en place des sau­ve­gardes auto­ma­tiques et une redon­dance matérielle.
  • Four­nit un cer­ti­fi­cat SSL/TLS pour acti­ver le HTTPS.
  • Filtre les connexions sus­pectes et sur­veille le réseau pour pré­ve­nir les attaques.

Ce que doit faire le client

  • Mettre à jour régu­liè­re­ment son site, ses exten­sions et ses thèmes.
  • Uti­li­ser des mots de passe forts et acti­ver l’authentification à deux fac­teurs quand c’est possible.
  • Véri­fier le bon fonc­tion­ne­ment du site et le scan­ner ponc­tuel­le­ment en ligne.
  • Conser­ver des sau­ve­gardes externes et tes­ter leur restauration.
  • Confi­gu­rer les pro­to­coles SPF, DKIM et DMARC pour sécu­ri­ser la messagerie.
  • For­mer ses uti­li­sa­teurs aux bonnes pra­tiques (vigi­lance face aux liens et pièces jointes douteux).

Ce que protège l’hébergeur et ce qui relève du client

NiveauGéré par l’hébergeurGéré par le client
Infra­struc­ture et réseauOuiNon
Logi­ciels ser­veur (PHP, MyS­QL, WAF)OuiNon
Cer­ti­fi­cats SSL / HTTPSOuiIns­tal­la­tion et acti­va­tion HTTPS
Code du site et CMSNonOui
Comptes et accès utilisateursNonOui
Sau­ve­gardesAuto­ma­tiquesCopie externe conseillée
Mes­sa­ge­rie (SPF, DKIM, DMARC)Par­tiel­le­mentOui

Un site sécu­ri­sé est donc le résul­tat d’un équi­libre : celui entre les pro­tec­tions mises en place par l’hébergeur et la rigueur quo­ti­dienne de son propriétaire.

La sécu­ri­té web n’est pas réser­vée aux experts ni aux grandes struc­tures. Elle repose avant tout sur des gestes simples et sur la confiance entre l’hébergeur et le pro­prié­taire du site. Un héber­geur solide offre un socle tech­nique fiable ; un site bien entre­te­nu réduit consi­dé­ra­ble­ment les risques.
Com­bi­nées, ces deux dimen­sions per­mettent à tout site, même modeste, de res­ter sûr, rapide et digne de confiance.

7 Comments

  1. Mutamba Bil dit :

    Mutam­ba Bil, Infir­mier BAC+5, Lea­der de la vac­ci­na­tion cer­ti­fié par la fon­da­tion Genève et déve­lop­peur full stack. Je vous remer­cie beau­coup pour cet article com­plet et gra­tuit. O2Switch est l’hébergeur le plus rapide et le plus sécu­ri­sé que j’aie connu.

    Mal­gré la guerre qui sévit dans ma région, ici à Goma (RDC), cela ne m’a pas empê­ché d’héberger mon site web. J’héberge donc mon site http://​www​.soi​gnants​.org depuis un mois.

    La chose la plus remar­quable que je puisse dire est la rapi­di­té de mon site web, la per­for­mance de mon héber­geur ain­si que la puis­sance de mon ser­veur. Il est vrai­ment incomparable.

  2. Thierry Laval dit :

    Super article, très clair et instructif ! 👌
    On voit bien que l’hébergeur joue un rôle clé dans la sécu­ri­té, notam­ment pour les ser­veurs, les sau­ve­gardes et le fil­trage des attaques.

    J’ai quelques ques­tions tech­niques qui me trottent dans la tête :

    1 ‑Dans le cadre d’attaques par injec­tion SQL ou XSS, quelles pro­tec­tions côté héber­geur sont vrai­ment effi­caces et jusqu’où doit-on inter­ve­nir côté site pour être tota­le­ment sécurisé ?

    2 – Pour des sites mul­ti-uti­li­sa­teurs, le simple SSL côté héber­geur suf­fit-il à pro­té­ger les don­nées sen­sibles, ou faut-il aus­si implé­men­ter un chif­fre­ment sup­plé­men­taire côté application ?

    3 – Enfin, sur un héber­ge­ment mutua­li­sé, quelles mesures d’isolation côté ser­veur sont réel­le­ment fiables pour évi­ter qu’une vul­né­ra­bi­li­té sur un site n’affecte les autres sites du serveur ?

    Mer­ci d’avance pour vos éclai­rages, j’aimerais vrai­ment com­prendre les limites de la pro­tec­tion côté héber­geur et ce qui doit res­ter côté site.

    Belle jour­née à tous et mer­ci pour cet excellent article que je par­tage avec joie à mes clients.

    • Bon­jour,

      Mer­ci pour votre retour ! 

      Concer­nant vos questions :

      1) Ces attaques ciblent avant tout le code applicatif
      L’hébergeur peut limi­ter leur impact indi­rec­te­ment via :
      • un fire­wall appli­ca­tif (WAF) pour blo­quer les requêtes suspectes,
      • des mises à jour ser­veur régu­lières (PHP, MyS­QL, etc.),
      • un fil­trage des pat­terns connus (mod_security par exemple).

      Mais la vraie pro­tec­tion se fait côté site : vali­da­tion et échap­pe­ment des don­nées, requêtes pré­pa­rées, contrôle des entrées uti­li­sa­teurs, etc.
      Aucun héber­geur ne peut cor­ri­ger une faille de code interne, c’est donc un tra­vail com­plé­men­taire entre les deux couches.

      2) Le SSL/TLS (HTTPS) four­ni par l’hébergeur chiffre les échanges entre le navi­ga­teur et le ser­veur, donc il pro­tège la trans­mis­sion des données.
      Mais pour un site mul­ti-uti­li­sa­teurs mani­pu­lant des don­nées sen­sibles (ex. fichiers, mes­sages pri­vés, etc.), il faut chif­frer ou hacher cer­taines infor­ma­tions au niveau appli­ca­tif (ex. mots de passe avec bcrypt).
      Cela évite qu’une com­pro­mis­sion ser­veur donne accès à des don­nées en clair.
      Le SSL pro­tège le trans­port, mais le chif­fre­ment appli­ca­tif pro­tège la don­née elle-même.

      3) Chez o2switch, nous uti­li­sons Cloud­li­nux avec Cagefs pour le cloisonnement.
      Cela per­met de cloi­son­ner les res­sources, les fichiers, etc…
      Un héber­gé A ne peut pas impac­ter un héber­gé B que ce soit au niveau des fichiers ou de la consom­ma­tion des ressources.
      C’est le même fonc­tion­ne­ment pour les Lunes.

      Ludo­vic.

  3. Aurélien dit :

    Bon­jour,

    Quelles sont les pro­tec­tions mises en place concer­nant un éven­tuel fichier mal­veillant télé­char­gé sur un champ de télé­char­ge­ment de fichier d’un for­mu­laire de contact ? 100% sécu­ri­sé côté, aucun risque ?

    Cor­dia­le­ment.

    • Éric Martin dit :

      Mer­ci pour cette ques­tion pertinente 🙂
      La sécu­ri­té d’un champ de télé­char­ge­ment repose à la fois sur l’hébergeur et sur la confi­gu­ra­tion du site.

      Côté héber­geur (o2switch)
      Le fire­wall appli­ca­tif (WAF) et Mod­Se­cu­ri­ty ana­lysent les fichiers entrants et bloquent les signa­tures mal­veillantes connues.
      L’isolation des comptes empêche toute pro­pa­ga­tion entre sites en cas de compromission.

      Côté site ou développeur
      Il est recom­man­dé de com­plé­ter ces pro­tec­tions en restrei­gnant les types et la taille des fichiers auto­ri­sés, selon les besoins réels du formulaire.
      Il faut éga­le­ment désac­ti­ver l’exécution de code dans le dos­sier de sto­ckage (via .htac­cess) et contrô­ler les fichiers reçus avant enre­gis­tre­ment, pour véri­fier qu’ils cor­res­pondent bien au type atten­du et leur attri­buer un nom de fichier neutre.

      Ces pro­tec­tions com­plé­men­taires réduisent for­te­ment le risque.

  4. Kambro dit :

    Mer­ci pour cet article.
    1° Si l’on uti­lise toutes les sécu­ri­tés pro­po­sées dans WP-Tiger et dans Tiger pro­tect, est-il encore néces­saire d’ins­tal­ler des plu­gins de sécu­ri­té tels que Word­fence ou autres ?
    2° Com­ment sécu­ri­ser en double authen­ti­fi­ca­tion l’ac­cès au CPanel ?
    Je vous remer­cie d’avance.

    • Éric Martin dit :

      Bon­jour, mer­ci pour votre commentaire.
      1/ Pour la par­tie Word­Press, l’essentiel est de com­pa­rer les pro­tec­tions offertes par Word­fence et celles déjà pré­sentes dans votre cPa­nel. L’idée est d’éviter les dou­blons et d’activer uni­que­ment ce qui apporte une pro­tec­tion com­plé­men­taire et utile. Selon le site, WP Tiger et Tiger Pro­tect peuvent suf­fire sans ajou­ter un plu­gin de sécu­ri­té supplémentaire.

      2/ Pour la double authen­ti­fi­ca­tion du cPa­nel, un module dédié est dis­po­nible direc­te­ment dans votre cPa­nel : Authen­ti­fi­ca­tion à deux fac­teurs. Allez dans le moteur de recherche en haut à droite et tapez Authen­ti­fi­ca­tion pour le trou­ver facilement.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *