Vous êtes ici : Accueil | Tutoriels WordPress | Le guide ultime du fichier .htaccess dans WordPress

Le guide ultime du fichier .htaccess dans WordPress

htaccess-wordpress

Saviez-vous que 100% des sites utilisant WordPress possèdent un fichier .htaccess ?

En effet, WordPress le crée automatiquement lors de l’installation pour y inclure le paramétrage des permaliens du site.

Lorsque vous allez dans Réglages > Permaliens pour choisir un format d’URL (normalement Nom de l’article), le fichier .htaccess est modifié.

Malgré tout, il faut savoir que ce fichier peut jouer un rôle beaucoup plus important.

Le fichier .htaccess est un fichier de configuration d’Apache, le logiciel qu’utilise votre serveur pour fonctionner.

Le contenu de ce fichier va donner des directives à Apache pour que le serveur se comporte de telle ou telle manière.

Grâce au fichier .htaccess on va notamment pouvoir :

  • Améliorer la sécurité d’un site
  • Augmenter la vitesse de chargement
  • Mettre en place des redirections
  • Limiter le spam
  • Et même faire des petites blagues 🙂

Ça vous intéresse n’est-ce pas ?

Si vous n’avez pas le temps de tout lire aujourd’hui, cliquez ici pour télécharger le pack .htaccess de la Marmite. Il contient cet article au format PDF et les 30 morceaux de code à copier/coller.

Alors continuez la lecture, vous ne serez pas déçu ! Voici le programme :

Avant de commencer

Avant de plonger dans le vif du sujet, nous allons étudier les bases afin que les débutants ne soient pas largués dès le début de l’article 😉

Fonctionnement des fichiers .htaccess

Ceci étant posé, nous allons bientôt pouvoir commencer. La dernière information que vous devez connaître est qu’un site peut posséder plusieurs fichiers .htaccess.

Tout d’abord, il y a le fichier .htaccess principal qui est situé à la racine du site. La racine d’un site est l’endroit où se trouvent les fichiers de WordPress (dossiers wp-admin, wp-includes et wp-content plus quelques autres fichiers).

Le contenu du fichier .htaccess principal aura une influence sur l’ensemble du site.

D’autres fichiers .htaccess peuvent être créé dans des sous-répertoires. Dans le cas de WordPress, on peut en placer un dans le répertoire wp-admin ou wp-content/uploads par exemple.

Les fichiers .htaccess secondaires auront une influence sur les répertoires dans lesquels ils sont situés ainsi que dans leurs sous-répertoires.

Si on imagine qu’un fichier .htaccess est présent dans wp-content/uploads, le répertoire uploads et tous ses sous-répertoires seront impactés par ce qui sera défini dans le fichier .htaccess.

Surtout, prenez vos précautions !

Attention aux yeux, ça peut piquer

Personnaliser le code d’un fichier .htaccess est assez simple (surtout avec les morceaux de code que propose la suite de cet article 😉 ) mais il ne faut tout de même pas y aller la fleur au fusil !

Avant toute modification, sauvegardez le contenu initial de votre fichier .htaccess. Pour ce faire, vous pouvez :

  • Dupliquer le fichier .htaccess de votre serveur en un fichier .htaccess-initial
  • Copier le contenu du fichier dans un fichier texte sur votre ordinateur

En cas de problème, vous pourrez restaurer facilement le contenu d’origine.

Pour effectuer des modifications, suivez la procédure suivante :

  • Ouvrez le fichier dans votre éditeur de code
  • Placez vos ajouts dans le fichier
  • Sauvegardez le tout
  • Actualisez votre site pour voir si tout va bien

L’actualisation de votre site est très importante car il faut être certain que le code ajouté ne pose pas de problème.

En général, une erreur 500 « Internal Server Error » s’affichera à l’écran en cas d’erreur :

Internal Server Error

Dans ce cas, annulez vos modifications et sauvegardez à nouveau et tout devrait rentrer dans l’ordre.

Parfois, il arrive que certains hébergeurs n’acceptent pas tel ou tel code dans le fichier .htaccess

Il faut faire avec.

Contactez le support de votre hébergeur pour en savoir plus. Avec un peu de chance, il n’y a besoin que d’une légère modification pour que ça fonctionne.

Comment créer un fichier .htaccess ?

Logiquement, votre site devrait avoir au moins un fichier .htaccess, celui situé à la racine de votre site. Vous pouvez le modifier à l’aide de votre éditeur de code.

Il existe d’autres solutions comme le plugin WP Htaccess Editor pour le modifier directement à partir de WordPress mais en cas de probleme il faudra passer par le FTP et votre éditeur de code, donc autant le faire directement.

Si vous devez ajouter un fichier .htaccess dans un sous-répertoire, suivez les instructions suivantes :

Créer un fichier .htaccess depuis votre ordinateur :

  • Créez un nouveau fichier texte et nommez le htaccess.txt
  • Éditez-le à votre guise
  • Envoyez-le à la racine de votre serveur
  • Renommez-le en .htaccess

Créer un fichier .htaccess directement depuis votre serveur :

  • Faites un clic droit dans le répertoire où il devra se trouver
  • Ajoutez un nouveau fichier et nommez-le .htaccess
  • Editez-le avec votre éditeur de code (Notepad++, Coda, SublimeText ou autre)

Les commentaires dans .htaccess

Comme dans la totalité des langages informatiques, le fichier .htaccess permet d’inclure des commentaires.

Dans notre cas, il suffit de placer le symbole # en début de ligne pour quelle soit ignorée. Cela est très pratique pour se rappeler de ce que réalisent des lignes de code.

Vous aurez l’occasion de voir des commentaires dans les exemples de cet article.

Nous pouvons commencer à entrer dans le vif du sujet avec le fichier…

.htaccess à la racine du site

Si votre installation s’est bien passée, vous trouverez un fichier .htaccess à la racine de votre site. Il contiendra le code suivant :

# BEGIN WordPress

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress
Code par défaut du fichier .htaccess de WordPress

Si vous utilisez WordPress en mode multisite, le code par défaut du fichier .htaccess sera différent. Cela ne vous concernera pas dans la majorité des cas.

Maintenant que vous avez localisé ce fichier, vous allez pouvoir enrichir son contenu avec les morceaux de codes ci-dessous pour obtenir des choses bien précises. Cela peut concerner la sécurité mais aussi d’autres choses.

Veillez à ne pas inclure de code entre les commentaires # BEGIN WordPress et # END WordPress car il est possible que ce code soit modifié dans certains cas.

Avertissement : Faites une sauvegarde de votre fichier .htaccess d’origine avant d’effectuer la moindre modification. Vous devez pouvoir revenir en arrière en cas de problème !

Désactiver l’affichage des répertoires

Par défaut, si vous essayez d’accéder aux répertoires d’un site, le serveur les affichera. La mise en forme ressemblera à ceci :

Fichiers et répertoires visibles de WordPress

Vous vous doutez bien que cela est du pain bénit pour les pirates. Le fait qu’ils puissent voir les fichiers de votre site vont les aider à mieux pouvoir l’attaquer. Insérez le code suivant dans votre fichier .htaccess pour protéger votre site :

# Désactiver l'affichage du contenu des répertoires
Options All -Indexes

Il est aussi possible d’utiliser ce code pour empêcher le listage des répertoires :

# Alternative pour empêcher le listage des répertoires
IndexIgnore *

Cacher les informations du serveur

Chez certains hébergeurs, les pages affichées peuvent contenir des informations relatives au serveur. Ces informations peuvent donner des informations à d’éventuels assaillants.

Il est donc préférable de les masquer avec le code suivant :

# Masquer les informations du serveur
ServerSignature Off

Activer le suivi des liens symboliques

Je dois vous parler chinois mais il est important d’insérer cette ligne de code dans votre fichier .htaccess principal.

# Activation du suivi des liens symboliques
Options +FollowSymLinks

Grâce à cela votre serveur pourra suivre ce que l’on appelle des liens symboliques, c’est à dire des raccourcis.

Mettre votre serveur à l’heure

Cela n’est pas vraiment important mais si votre serveur se trouve à l’étranger, vous pouvez lui indiquer de se caler sur votre fuseau horaire avec cette ligne de code :

# Choix du fuseau horaire
SetEnv TZ Europe/Paris

Cet article présente la liste des valeurs à employer si vous n’êtes pas en France.

Définir l’encodage des caractères par défaut

Le code suivant permet de définir l’encodage des caractères des fichiers textes et HTML en tant que UTF-8. Sans cela, il y a des risques que les accents soient mal pris en compte.

# Encodage par défaut des fichiers textes et HTML
AddDefaultCharset UTF-8

Protéger le fichier wp-config.php

Le fichier de configuration de votre site (wp-config.php) contient les identifiants pour se connecter à la base de données. C’est le fichier le plus sensible de votre site. Il sera clairement la cible d’éventuels pirates. Il est possible de le protéger en ajoutant ce code au fichier .htaccess principal :

# Protéger le fichier wp-config.php
<files wp-config.php>
order allow,deny
deny from all
</files>

Protéger le fichier .htaccess lui-même

Tout comme le fichier wp-config.php, le fichier .htaccess doit être protégé au maximum. Pour ce faire, insérez ce code :

# Protéger les fichiers .htaccess et .htpasswds
<Files ~ "^.*\.([Hh][Tt][AaPp])">
order allow,deny
deny from all
satisfy all
</Files>

Limiter le spam des commentaires

Vous le savez autant que moi si vos avez un blog, le spam de commentaires est une vraie plaie.

Heureusement, il y a une astuce pour s’en prémunir directement dans le fichier .htaccess. Cela n’est pas une solution miracle mais combiné avec le plugin Akismet, la majorité des spams devrait être filtrée.

# Éviter le spam de commentaires
<IfModule mod_rewrite.c>
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .wp-comments-post\.php*
RewriteCond %{HTTP_REFERER} !.monsite.com.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) ^http://%{REMOTE_ADDR}/$ [R=301,L]
</IfModule>

N’oubliez pas de remplacer monsite.com par votre nom de domaine.

Éviter que l’on découvre l’identifiant d’un auteur

Même si vous utilisez un identifiant utilisateur complexe, il peut cependant être découvert.

Bien sûr, j’imagine que vous ne l’affichez pas déjà publiquement avec votre thème (ça peut arriver) 😉

Essayez de taper monsite.com/?author=x en remplaçant x par 1 pour l’administrateur ou l’ID d’un de vos auteurs. Si vous n’êtes pas protégé, vous serez redirigé vers une page du type monsite.com/author/idenfiant_auteur.

Voilà comment on trouve un identifiant en 2 secondes. À partir de là, il ne reste plus qu’à tenter de deviner votre mot de passe.

Pour vous protéger de cette technique, utilisez le code suivant :

# Éviter que l'on découvre l'identifiant d'un auteur
# Merci à Jean-Michel Silone du groupe Facebook WP-Secure https://www.facebook.com/groups/wp.securite/
<IfModule mod_rewrite.c>
RewriteCond %{QUERY_STRING} ^author=([0-9]*)
RewriteRule .* - [F]
</IfModule>

Merci à Jean-Michel du groupe Facebook WP-Secure pour l’astuce 🙂

Désactiver le hotlinking de vos images

Et oui, un nouvel anglicisme fait son apparition sur la Marmite. Rassurez-vous, je vous explique tout.

En fait, une fois que vous aurez ajouté des images sur votre site (par exemple dans un article), n’importe quelle personne peut copier l’adresse URL d’une de vos images et l’afficher sur son site.

On pourrait se dire que cela n’est pas si grave mais si pour une raison X ou Y un site très suivi reprend votre image et l’affiche sur une de ses pages, des requêtes seront effectuées au niveau de votre serveur.

Le hotlinking est en réalité un vol de bande passante. Si votre site est installé sur un petit serveur mutualisé, votre hébergeur risque de ne pas apprécier car les ressources sont limités.

Pour éviter le problème, insérez et personnalisez ce code dans votre fichier .htaccess :

# Désactiver le hotlinking de vos images
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?monsite.com [NC]
RewriteRule \.(jpg|jpeg|png|gif)$ http://fakeimg.pl/400x200/?text=Pas_touche_aux_images [NC,R,L]
Remplacez monsite.com par votre nom de domaine

Pour autoriser certains sites à afficher vos images, utilisez le code suivant :

# Désactiver le hotlinking de vos images
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?monsite.com [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?monsite2.com [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?monsite3.com [NC]
RewriteRule \.(jpg|jpeg|png|gif)$ http://fakeimg.pl/400x200/?text=Pas_touche_aux_images [NC,R,L]
Remplacez monsite.com, monsite2.com et monsite3.com par les domaines de votre choix

Vous pouvez aussi personnaliser l’image qui s’affichera à la place de l’image demandée. J’ai ajouté quelque chose de simple mais vous pouvez être plus taquin 😉

Bannir des adresses IP

Si vous avez remarqué de certaines IP tentaient de se connecter un peu trop souvent à l’administration de votre site (par exemple avec le plugin Login Lockdown), vous pouvez vous en débarrasser en banissant leur adresse IP.

Vous avez aussi la possibilité de récupérer les adresses IP des spammeurs de commentaires pour les bannir de votre site.

Cette solution n’est pas définitive car votre assaillant pourra changer d’adresse IP mais cela pourra fonctionner pour les personnes les moins douées.

# Bannir une adresse IP
<Limit GET POST>
order allow,deny
deny from xxx.xxx.xxx.xxx
allow from all
</Limit>
Remplacez xxx.xxx.xxx.xxx par l'adresse IP à bannir

Bloquer les visiteurs provenant de certains sites

Si vous vous rendez compte qu’un site non conforme à fait un lien pointant vers vous et que vous ne voulez pas que les visiteurs de ce site aient accès à votre site, utilisez ce code :

# Empêcher les visiteurs de ces sites d'accéder au votre
<IfModule mod_rewrite.c>
 RewriteEngine on
 RewriteCond %{HTTP_REFERER} monsite1.com [NC,OR]
 RewriteCond %{HTTP_REFERER} monsite2.com [NC,OR]
 RewriteRule .* - [F]
</ifModule>
Remplacez monsite1.com et monsite2.com par les sites de votre choix

Rediriger les visiteurs provenant d’un site vers un autre

Pour aller plus loin que l’astuce précédente, vous pouvez renvoyer les visiteurs provenant de certains sites vers un autre site.

Autant vous dire qu’il y a de quoi bien rigoler. Voici le code à employer :

# Rediriger les visiteurs venant site vers un autre
RewriteEngine on
RewriteCond %{HTTP_REFERER} sitesource\.com/
RewriteRule ^(.*)$ http://www.sitedestination.com [R=301,L]
Remplacez les sites source et destination par ceux de votre choix

Créer des redirections

Le fichier .htaccess permet de faire des redirections. Cela est bien pratique pour rediriger quelques pages mais si vous souhaiter créer beaucoup de redirections, je vous conseille le plugin WordPress Redirection.

Voici tout de même comment créer des redirections dans le fichier .htaccess :

# Redirection d'une page quelconque
Redirect 301 /anciennepage/ http://www.monsite.com/nouvellepage

# Redirection d'une nouvelle catégorie (avec renommage de category en categorie)
Redirect 301 /category/technologie/ http://www.monsite.com/categorie/techno/

Rediriger l’adresse sans www vers www

Quand on met en place un site, une des actions à accomplir en priorité est de rediriger le site sans les www vers la version doté des www (ou l’inverse).

Si vous faites le test la prochaine fois que vous créerez un site, vous constaterez que les deux adresses ne renvoient pas forcément vers votre site.

Dans certains cas l’hébergeur s’en charge automatiquement ou il faut l’activer via l’administration de l’hébergeur (c’est par exemple le cas avec Gandi).

Si vous devez procéder à cette redirection manuellement, utilisez le code suivant en remplaçant monsite.com par votre site :

# Redirection du site sans www vers www
RewriteEngine On
RewriteCond %{HTTP_HOST} ^monsite.com [NC]
RewriteRule ^(.*)$ http://www.monsite.com/$1 [L,R=301]
Remplacez monsite.com par votre nom de domaine

Rediriger l’adresse www vers sans www

À l’inverse, si vous ne voulez pas des www devant le nom de votre site (comme pour la Marmite), il est possible de faire une redirection vers la version sans les www.

Insérez le code suivant dans le fichier .htaccess :

# Rediriger vers la version sans www
RewriteEngine on
RewriteCond %{HTTP_HOST} ^www\.monsite\.com [NC]
RewriteRule ^(.*)$ http://monsite.com/$1 [L,R=301]
Remplacez monsite.com par votre nom de domaine

Attention : N’utilisez pas ce code avec le précédent sinon votre site souffrira d’une boucle de redirection (car la version sans www redirigera vers la version avec www qui redirigera vers la version sans www, etc.)

Rediriger vers HTTPS

Si vous avez mis en place un certificat SSL sur votre site pour le passer en HTTPS, vous devez être certain que tous vos visiteurs naviguent bien sur la version sécurisée de votre site.

Dans le cas contraire, des informations sensibles pourraient être récupérées par des pirates (des données personnelles ou bancaires par exemple).

Utilisez le code suivant pour passer tout votre site en HTTPS :

# Redirection vers HTTPS 
RewriteCond     %{SERVER_PORT} ^80$
RewriteRule     ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R]

Forcer le téléchargement de fichiers spécifiques

Lorsque l’on désire télécharger un fichier à partir d’un site, notre navigateur essaie parfois de l’ouvrir pour l’afficher.

Personnellement, je trouve cela pratique pour les fichiers PDF en revanche, c’est très désagréable pour d’autres types de fichiers.

Insérez le code suivant pour que vos visiteurs téléchargent directement les fichiers dotés de ces extensions (modifiez-les à votre guise) :

# Forcer le téléchargement pour ces types de fichiers
AddType application/octet-stream .doc .docx .xls .xlsx .csv .mp3 .mp4

Créer une page de maintenance personnalisée

Dans un précédent article, nous avons découvert le plugin WP Maintenance. Pourtant, il y a des cas où la page de maintenance ne pourra pas s’afficher.

En effet, si l’installation de WordPress a un problème, le plugin ne pourra pas fonctionner et donc la page de maintenance ne pourra pas s’afficher.

C’est fâcheux n’est-ce pas ?

Pour bénéficier d’une page de maintenance, vous pouvez utiliser le code suivant :

# Page de maintenance
RewriteEngine on
RewriteCond %{REQUEST_URI} !/maintenance.html$
RewriteCond %{REMOTE_ADDR} !^xxx\.xxx\.xxx\.xxx
RewriteRule $ /maintenance.html [R=302,L]

Pour que cela fonctionne, vous devez :

  • Créer un fichier maintenance.html avec du contenu indiquant que le site est en maintenance
  • Ajouter votre adresse IP dans la ligne 4 (en gardant bien les « \ ») pour vous permettre d’accéder au site (découvrez votre adresse IP sur ce site)

Quand la maintenance sera terminée, mettez des « # » devant chaque ligne pour les passer en commentaire.

Activer la mise en cache

Le fichier .htaccess permet de mettre en cache certains fichiers de votre site dans le navigateur de vos visiteurs pour que le chargement soit plus rapide.

En effet, le navigateur n’aura pas besoin de retélécharger les fichiers présents dans son cache.

Pour ce faire, insérez le code suivant :

# Mise en cache des fichiers dans le navigateur
<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 1 month"

ExpiresByType text/html "access plus 0 seconds"
ExpiresByType text/xml "access plus 0 seconds"
ExpiresByType application/xml "access plus 0 seconds"
ExpiresByType application/json "access plus 0 seconds"
ExpiresByType application/pdf "access plus 0 seconds"

ExpiresByType application/rss+xml "access plus 1 hour"
ExpiresByType application/atom+xml "access plus 1 hour"

ExpiresByType application/x-font-ttf "access plus 1 month"
ExpiresByType font/opentype "access plus 1 month"
ExpiresByType application/x-font-woff "access plus 1 month"
ExpiresByType application/x-font-woff2 "access plus 1 month"
ExpiresByType image/svg+xml "access plus 1 month"
ExpiresByType application/vnd.ms-fontobject "access plus 1 month"

ExpiresByType image/jpg "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/png "access plus 1 month"

ExpiresByType video/ogg "access plus 1 month"
ExpiresByType audio/ogg "access plus 1 month"
ExpiresByType video/mp4 "access plus 1 month"
ExpiresByType video/webm "access plus 1 month"

ExpiresByType text/css "access plus 6 month"
ExpiresByType application/javascript "access plus 6 month"

ExpiresByType application/x-shockwave-flash "access plus 1 week"
ExpiresByType image/x-icon "access plus 1 week"

</IfModule>

# En-têtes
Header unset ETag
FileETag None

<ifModule mod_headers.c>  
<filesMatch "\.(ico|jpe?g|png|gif|swf)$">  
    Header set Cache-Control "public"  
</filesMatch>  
<filesMatch "\.(css)$">  
    Header set Cache-Control "public"  
</filesMatch>  
<filesMatch "\.(js)$">  
    Header set Cache-Control "private"  
</filesMatch>  
<filesMatch "\.(x?html?|php)$">  
    Header set Cache-Control "private, must-revalidate"
</filesMatch>
</ifModule>

La mise en cache des fichiers sera effective pendant la durée spécifiée pour chaque type de fichier où jusqu’à ce que le visiteur vide son cache.

Activer la compression

En plus de tout ce que nous avons vu jusqu’à présent, il est possible de compresser certaines ressources avant qu’elles soient transféré du serveur au navigateur.

Et qui dit compression de fichier dit vitesse d’affichage plus rapide pour la page. Je vous recommande donc de mettre en place ce code pour donner un coup d’accélérateur à votre site :

# Compressions des fichiers statiques
<IfModule mod_deflate.c> 
    AddOutputFilterByType DEFLATE text/xhtml text/html text/plain text/xml text/javascript application/x-javascript text/css 
    BrowserMatch ^Mozilla/4 gzip-only-text/html 
    BrowserMatch ^Mozilla/4\.0[678] no-gzip 
    BrowserMatch \bMSIE !no-gzip !gzip-only-text/html 
    SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary 
    Header append Vary User-Agent env=!dont-vary 
</IfModule>  

AddOutputFilterByType DEFLATE text/html  
AddOutputFilterByType DEFLATE text/plain  
AddOutputFilterByType DEFLATE text/xml  
AddOutputFilterByType DEFLATE text/css  
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE font/opentype
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/json  

Désactiver l’accès à certains scripts

Pour fonctionner, WordPress utilise des scripts situés dans le répertoire wp-includes, cependant il n’y a aucune raison d’y accéder directement. Utilisez ce code pour en limiter l’accès :

# Bloquer l'utilisation de certains scripts
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]

Vous pourrez en savoir plus dans le codex.

Protection contre les injections de fichiers

Des pirates peuvent tenter d’envoyer des fichiers sur votre serveur pour prendre le contrôle de votre site. Pour leur mettre des batons dans les roues, vous pouvez inclure ce code dans votre fichier .htaccess :

# Protection contre les injections de fichiers
RewriteCond %{REQUEST_METHOD} GET
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=http:// [OR]
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=(\.\.//?)+ [OR]
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=/([a-z0-9_.]//?)+ [NC]
RewriteRule .* - [F]

Protection contre d’autres menaces

Sur Facebook, Richard m’a indiqué qu’il était possible de se prémunir du « clickjacking » et d’autres menaces en ajoutant quelques lignes dans le fichier .htaccess.

Pour info, le clickjacking est une technique qui permet de faire croire à un visiteur qu’il est sur votre site alors que ce n’est pas le cas grâce à des balises frame ou iframe.

Le code suivant permet donc de vous protéger contre le clickjacking, de lutter contre d’autres menaces comme le MIME Sniffing et de bloquer le contenu en cas d’attaque XSS.

# Protections diverses (XSS, clickjacking et MIME-Type sniffing)
<ifModule mod_headers.c>
Header set X-XSS-Protection "1; mode=block"
Header always append X-Frame-Options SAMEORIGIN
Header set X-Content-Type-Options: "nosniff”
</ifModule>

.htaccess dans wp-admin

wp-admin, c’est l’antre de votre site. L’endroit où vous vous rendez pour écrire des articles, configurer vos menus, paramétrer votre thème et bien d’autres choses encore.

Il va de soi qu’aucune personne non autorisée ne doit pénétrer dans ce sanctuaire. Sinon, attention les dégâts.

Voici ce qu’il est possible de faire pour durcir la sécurité grâce à un fichier .htaccess que vous aurez placé dans le dossier wp-admin de votre site.

Limiter l’accès à l’administration du site

Seules les personnes possédant les IP listés pourront accéder au dossier wp-admin. Plutôt pratique pour éviter que des étrangers se connectent à votre site (même s’ils ont le bon mot de passe).

<Limit GET POST PUT>
order deny,allow
deny from all
# IP d'Alex
allow from xxx.xxx.xxx.xxx
# IP de Nico
allow from xxx.xxx.xxx.xxx
# IP d'un autre point d'accès
allow from xxx.xxx.xxx.xxx
</Limit>

Ajouter une seconde authentification

Lorsque vous vous connectez à l’administration d’un site WordPress, vous utilisez un identifiant et un mot de passe. Eh bien il est possible d’en ajouter un second grâce au fichier .htaccess et à un autre fichier.

Tout d’abord, créez un fichier nommé .htpasswd dans le répertoire wp-admin et insérez-y un couple d’identifiant et mot de passe. Servez-vous de ce site pour vous aider :

Générateur .htpasswd

Entrez l’identifiant à utiliser dans le premier champ et votre mot de passe dans le second puis cliquez sur « Générer ».

Copiez ensuite la ligne qui s’affichera dans le fichier .htpasswd. Si vous avez besoin de créer plusieurs utilisateurs, recommencez l’opération et ajoutez le nouveau couple d’identifiant/mot de passe au sein d’une nouvelle ligne.

Par exemple, vous pouvez obtenir ce genre de fichier :

alex:ieS547B1UxY8M
nico:rSqEJf0SeTlRs
Contenu fictif d'un fichier .htpasswd

Ensuite, insérez le code suivant dans le fichier .htaccess :

# Seconde authentification pour l'administration

<Files admin-ajax.php>
Order allow,deny
Allow from all
Satisfy any 
</Files>

AuthName "Connexion à l'administration"
AuthType Basic
AuthUserFile "/chemin/complet/vers/le/fichier/.htpasswd"

Require valid-user

Le point sensible de cette manipulation est de bien entrer le chemin complet du fichier .htpasswd. Pour le trouver à coup sûr, créez un fichier info.php et insérez le code suivant :

<?php echo "Chemin à copier : " . realpath('.htaccess'); ?>
Placez le fichier info.php dans wp-admin

Rendez-vous sur votresite.com/wp-admin/info.php et vous obtiendrez le chemin réel du fichier .htpasswd à placer dans le fichier .htaccess. Supprimez le fichier info.php une fois que vous aurez obtenu le bon chemin.

Mise à jour : Si vous insérez ce code tel quel, les requêtes AJAX ne fonctionneront plus. Rendez-vous sur SecuPress pour découvrir comment régler le problème.

Si vous avez bien compris tout ce que je viens de citer, vous devriez avoir une double authentification en place pour accéder à l’administration de WordPress ! Bravo 🙂

Allez, on passe à la suite.

.htaccess dans wp-includes

Bloquer l’accès direct aux fichiers PHP

Créez un fichier .htaccess dans wp-includes et collez-y le code suivant pour éviter que des fichiers PHP soient chargés directement :

# Bloque les accès directs aux fichiers PHP (Merci à Sucuri)
<Files wp-tinymce.php>
allow from all
</Files>
<FilesMatch "\.(?i:php)$">
  <IfModule !mod_authz_core.c>
    Order allow,deny
    Deny from all
  </IfModule>
  <IfModule mod_authz_core.c>
    Require all denied
  </IfModule>
</FilesMatch>
<Files wp-tinymce.php>
  Allow from all
</Files>
<Files ms-files.php>
  Allow from all
</Files>

Le code ci-dessus est fourni par le plugin Sucuri. En complément, je vous conseille de souscrire à leur service pour dormir sur vos deux oreilles au niveau de la sécurité.

.htaccess dans wp-content

Bloquer l’accès direct aux fichiers PHP

Pour le dossier wp-content le code est similaire, il y a juste les exceptions en moins :

# Bloque les accès directs aux fichiers PHP (Merci à Sucuri)
<FilesMatch "\.(?i:php)$">
  <IfModule !mod_authz_core.c>
    Order allow,deny
    Deny from all
  </IfModule>
  <IfModule mod_authz_core.c>
    Require all denied
  </IfModule>
</FilesMatch>

.htaccess dans wp-content/uploads

Bloquer l’accès direct aux fichiers PHP

Toujours avec ce code, protégez le dossier où sont stockés les médias pour éviter que des fichiers PHP soient exécutés par quelqu’un de l’extérieur (un méchant pirate par exemple).

# Bloque les accès directs aux fichiers PHP (Merci à Sucuri)
<FilesMatch "\.(?i:php)$">
  <IfModule !mod_authz_core.c>
    Order allow,deny
    Deny from all
  </IfModule>
  <IfModule mod_authz_core.c>
    Require all denied
  </IfModule>
</FilesMatch>

Conclusion et ressources pour aller plus loin

Bien que pas mal de choses aient été abordées dans cet article, il est possible d’aller plus loin dans le paramétrage de votre fichier .htaccess.

On peut citer le Codex de WordPress, la documentation d’Apache (le logiciel qui fait tourner votre serveur) ou encore le blog Perishable Press (ils ont même écrit un bouquin là dessus). Le blog SEOMix de Daniel Roch présente aussi un article intéressant à ce sujet.

Je tiens à vous rappeler de procéder à vos modifications avec une extrême attention. Des erreurs ou des incompatibilités peuvent se produire en fonction de l’hébergeur de votre site.

Gardez toujours une sauvegarde du fichier .htaccess d’origine pour effectuer une restauration en cas de problème (je vous aurai prévenu !).

Eh bien, ce fut un sacré article n’est-ce pas ?

Merci de l’avoir lu en intégralité 🙂

Pour résumer tout ce qui a été abordé dans cet article, je vous propose de télécharger la totalité du fichier .htaccess principal ainsi que cet article au format PDF pour qu’il vous serve de référence à l’avenir.

Télécharger le pack .htaccess de la Marmite

Si vous avez l’habitude d’utiliser les fichiers .htaccess pour vos sites, partagez les morceaux de code que vous avez l’habitude d’utiliser en commentaire 😉

Si vous avez apprécié cet article, inscrivez-vous à la newsletter

Recevez gratuitement les prochains articles et accédez à des ressources exclusives. Plus de 10000 personnes l'ont fait, pourquoi pas vous ?

C'est parti, je m'inscris !

157 commentaires Ajoutez le vôtre

  1. Salut Alex,

    Un petit code tout simple qui permet d’éviter l’ajout de fichiers HTML et/ou de fichiers PHP. A ajouter dans un dossier sensible et qui ne possède pas lesdits fichiers, comme Uploads par exemple.

    Deny from all

    Deny from all

    Et sinon ma protection contre les injections de fichiers fait 40 lignes là où la tienne en fait 5 (que j’ai aussi), je ne comprends pas tout à l’intérieur mais la tienne peut sans doute être améliorée du coup, je suppose. 🙂

    Répondre
    • Bonjour Micka,
      Peux-tu partager ton code via Gist pour que ce ne soit pas filtré dans les commentaires ?

      Merci à toi
      Alex

    • Ah oui effectivement, c’est le genre de code que je voulais inclure à la base mais j’ai opté pour le code généré par Sucuri 😉

    • Hello,

      finalement le code partagé via gist ne fait plus 40 lignes ?

      Tu peux repartager le bon?

  2. Effectivement, c’ est bien le premier article aussi complet que je lis sur le sujet.
    Mais j’ ai une question au sujet du paragraphe « mise en cache »: qu’ en est-il pour les utilisateurs de wp-rocket? le code reste-t-il valable ou doit-il être amendé?

    Répondre
    • Bonjour Eric,

      Les utilisateurs de WP Rocket peuvent effectivement éviter d’inclure ces morceaux de code 🙂
      Merci pour le retour sur l’article !

    • Hello Eric,

      WP Rocket modifie déjà le fichier .htaccess dans un sens assez proche du code proposé par Alex, concernant la mise en cache tout du moins 🙂

      Merci pour l’article Alex !

  3. Ça, c’est du beau boulot ! Bravo Alex 🙂

    Répondre
    • Merci Aurélien pour ton retour et ton partage sur les réseaux sociaux 🙂

  4. Merci, cela fait un moment que je cherche un tuto aussi complet que cela sur le sujet!

    Toujours facile à lire et simple d’utilisation autant pour un professionnel que pour une personne moins expérimentée 🙂

    Merci et bonne continuation.

    Répondre
    • Bonjour Toni,

      Merci pour ton commentaire, je suis content de voir que les articles de la Marmite sont toujours bien accueillis !

      A bientôt
      Alex

  5. Bravo Alex !
    Super article que je vais faire circuler !
    Une question: quel plugin ou code utilises tu pour afficher la page de capture quand on clic sur  » cliquez ici pour télécharger le pack .htaccess de la Marmite. »? Peux tu expliquer la config du workflow avec ton autorepondeur stp ?
    Merci d’avance !
    Amicalement
    Florence

    Répondre
    • Bonjour Florence,

      Merci pour le partage 🙂
      On utilise OptinMonster pour les formulaires de capture d’email. Il faut d’ailleurs que je fasse un article sur le sujet.

      A bientôt
      Alex

  6. Bonjour,

    merci, merci, merci !

    L’article que j’espérais trouver depuis deux ans !

    :o)<

    Répondre
    • Mieux vaut tard que jamais ^^

  7. Wahou Alex on dirait que tu lis dans mes pensées ! Je suis en bataille avec htaccess depuis une semaine ! Ton article va grandement m’aider !

    Répondre
    • Impeccable ! Fait en bon usage Aude 😉

  8. Bravo Alex , un super article , et bien utile
    Merci continue on apprécie

    Répondre
    • Vous pouvez compter sur moi Guy !

  9. Salut Alex,

    C’est bien le premier article aussi complet et clair que je vois sur le .htaccess ! Merci pour ce travail, c’est toujours pratique d’avoir un bon mémo à portée de main 😉

    Répondre
    • Merci Brad, ravi que ça te plaise 🙂

  10. Bonjour Alex,

    Encore un super article et toujours ce besoin de nous en donner un peu plus.
    Je savais que ce fichier était important, mais je ne voyais pas ce qu’il fallait y mettre, principalement au niveau de la sécurité.
    Avec RST et les articles de wpmarmite, on devient presque un professionnel de wordpress.
    Merci infiniment pour toutes ces leçons, dignes d’un formateur hors pair.
    A bientôt.

    Répondre
    • Merci beaucoup ! Le but de la Marmite est d’aider ses lecteurs à tirer le meilleur de WordPress. Je travaille chaque jour à aider davantage de personnes 🙂

  11. Merci pour ce bel article très complet.

    Répondre
    • Avec plaisir Isabelle 🙂

  12. Excellent article ! Et j’en ai beaucoup lu…

    Répondre
    • Merci 🙂

  13. Salut Alex.

    Merci pour cet article assez riche. Je fais actuellement des recherches sur internet pour la sécurisation de mon site wordpress (qui est pour l’instant en local).

    Dans mon fichier .htaccess à la racine du site, j’ai 2 lignes supplémentaires que tu ne mentionnes pas dans le code présent par défaut dans le fichier .htaccess, code figurant au début de cet article.

    Cela ressemble à une balise ouvrante et à une balise fermante. Quel peut être leur rôle ?

    Voici comment mon fichier se présente :

    # BEGIN WordPress

    ligne de code…
    ligne de code…
    ligne de code…
    ligne de code…

    # END WordPress

    Répondre
    • Bonjour Hippolyte,

      Comme indiqué dans l’article, les lignes précédées de # sont des commentaires.
      Les mots-clés BEGIN et END servent de délimitation. Dans l’exemple cité, cela sert à délimiter le code créé par WordPress. Certains plugins sont susceptibles d’ajouter leurs propres codes, il ne faut donc pas éditer les codes ajoutés par WordPress ou par des plugins.

      Bonne continuation
      Alex

  14. C’est vraiment un super article et super complet

    j’ai néanmoins une petite question…

    est ce que je peux mettre autant de morceaux de code que je le souhaite ou suis je limité par le fichier par lui même (poids, taille, nombre de ligne) ?

    encore merci pour ton travail

    Répondre
    • Bonjour et merci pour votre message 🙂

      Vous pouvez ajouter pas mal de morceaux de code dans votre fichier .htaccess. Apres, si votre fichier fait 500 lignes, il y aura certainement des ralentissements. A tester donc.

      Bonne continuation
      Alex

  15. Salut Alex,
    J’en ai marre de me répéter mais…
    Bravo !!! Excellent !!! Impeccable !!!
    Même si pour la plupart des fervents « WordPressiens » connaissent ces astuces, il est intéressant de les proposer aux internautes qui utilise leur site sans s’imaginer de la sécurité que peut apporter ce sacré fichier .htaccess 😉
    Continue comme ça
    Jérôme

    Répondre
    • Bonjour Jérôme,

      Merci pour ton retour ! Effectivement, il est bon de récapituler les choses afin que les débutants puissent bénéficier de ressources de qualité.

      A bientôt
      Alex

  16. Salut à tous.

    Le code qui permet d’empêcher le téléchargement des images, empêchera t-il aussi celui des PDF, cela ne m’arrange pas. Dans ce cas est-il possible d’autoriser seulement le téléchargement des PDF ?

    Répondre
    • Bonjour Lidie,

      Pour empêcher le téléchargement des PDF, ajoutez l’extension « pdf » à la dernière ligne et cela devrait fonctionner.
      En laissant le code tel quel, le téléchargement des PDF sera possible.

      Bonne continuation
      Alex

  17. Ouf ! Bel article, merci 😀

    Répondre
    • Eh oui, il y a de la lecture ^^

  18. Merci Alex pour ce guide complet sur le fameux fichier .htaccess. J’ai bien aimé l’astuce du .htpasswd dans le répertoire wp-admin, si simple et tellement efficace, encore fallait-il y penser !

    Répondre
    • Avec plaisir Séb !
      À bientôt sur la Marmite 😉

  19. Merci Alex

    J’avais fait une doc en mon temps là dessus, mais nettement moins riche, et du coup j’ai appris pleins de choses grâce à toi, merci beaucoup, c’est top !

    Répondre
    • Ravi de t’avoir aidé Marc 🙂

  20. Hello,

    Je me posait la question de savoir si l’auth basic dans le repertoire wp-admin ne bloquait pas les requêtes vers admin-ajax.php et admin-post.php, qui sont des scripts PHP destinés à être utilisés par des utilisateurs lambda ? Ca ne pose pas de problèmes ?

    Répondre
    • Salut Willy,

      Merci pour ta question. Effectivement, il y a un problème sur ce point. J’ai mis à jour le code en me basant sur cet article.

      J’en profite pour te remercier pour ton plugin Past’a Code. Il est vraiment top pour afficher des morceaux de code, il va falloir que je le présente dans un article 😉

      ++

  21. Bonjour,

    je me permets une question qui est d’actualité pour mon site, si tu estimes que je suis hors sujet ou que cela n’a rien à faire dans les commentaires je comprendrais que tu le censures.

    Depuis 4 jours j’ai des centaines d’ip différentes venant de l’etranger qui harcèlent mon site jour et nuit.

    Au début j’ai commencé à bloquer les ips et les plages d’ip mais cela alourdit mon htaccess, et ‘ il ‘ revient au bout de quelques heures avec d’autres plages d’ip, j’aimerais bloquer l’accès au navigateur qui est quasi systématiquement utilisé : opéra 9, que puis-je mettre dans mon htaccess ?

    Merci par avance.

    Répondre
    • Bonjour tout le monde,

      pour info voici la réponse à la question que j’ai posée, voici le code pour bloquer cette version du navigateur :
      RewriteEngine On
      RewriteCond %{HTTP_USER_AGENT} OPR/9 [NC]
      RewriteRule .* – [F,L]

  22. Salut Alex

    Dans l’article tu donnes un bout de code qui permet de masquer les infos du server. Ce même bout de code permet-il de cacher la version du site ?

    Ma question peut sembler bizarre. Mais je la pose parce que certains blogs affirment que cacher la version de son thème constitue une mesure de sécurité contre les pirates; alors que d’autres soutiennent qu’il est inutile de le faire car de toutes les façons il sera très facile de déterminer la version.

    Vu que tu t’y connais, quel attitude conseilles-tu ?

    Cordialement.

    Répondre
  23. Bravo pour cet excellent article que je m’empresse de partager 🙂

    Répondre
    • Merci beaucoup Arnaud 🙂

  24. Salut Alex,
    Je n’étais pas encore à la recherche sur le sujet mais à la vue des autres commentaires ton article va me permettre de gagner du temps.

    Merci Beaucoup.

    Répondre
    • Il n’y a pas de quoi Jean 😉

  25. Alors là, vraiment merci pour cet article, ne serait-ce que pour la protection du Wp-includes que je ne connaissais pas et qui est le 1er step à faire je pense niveau sécurité.
    Par contre, je ne sais pas pourquoi mais en rajoutant le code pour la protection du wp-config, je me retrouve avec une erreur 500 au niveau de l’admin WP (je suis chez OVH). J’ai supprimé le code dans mon fichier, mais rien n’y fait. J’ai du donc faire une restauration pour retrouver l’accès au Back office. Une idée?!

    Répondre
    • Salut Julien,

      C’est juste le code pour le wp-config.php qui a fait planter le site ? Étrange.
      Je viens de voir qu’il n’y a pas de « f » majuscule à file, ça vient peut-être de là mais ça m’étonnerait.
      Peux-tu faire le test ?

  26. Salut Alex

    Merci tout d’abords pour ces précieux conseils.

    Néanmoins, j’ais une petite préoccupation. Elle concerne le fichier .htaccess à la racine du site et les autres que nous créons.

    Vu que ces fichiers modifiés se trouvent dans les répertoires du thème parent, n’y a t-il pas un risque de perte des modifications lors de la mise à jour du thème ?

    Merci d’avance.

    Répondre
  27. Salut Alex,

    Je viens compéter ton article car j’ai fait face à un problème que j’ai résolu avec mon fichier .htaccess. Il s’agit de l’affichage des accents directement dans une boite d’authentification. J’ai testé la solution que tu présentes dans ton billet, à savoir « AddDefaultCharset UTF-8 », mais ne fonctionnant pas, j’ai cherché une autre solution, trouvée sur http://www.admin-linux.fr/?p=7750
    Pour le coup, la solution est de passer l’encodage de ce fichier en ISO-8859-1.

    – En console, rentrer dans le dossier du projet avec la commande « cd ».
    – Un « file .htaccess » retourne l’encodage et le type de fichier. Pour le moment, ça retourne : ‘.htaccess: UTF-8 Unicode text’
    – Ensuite, « iconv -f UTF-8 -t ISO-8859-1 .htaccess > .htaccess.iso » transforme l’encodage du fichier, ainsi que son nom. C’est la syntaxe d’iconv qui oblige à donner un fichier destinataire. Il faudra donc ensuite le renommer en .htaccess.
    – Si le fichier originel en UTF-8 doit être gardé, faire « mv .htaccess .htaccess.utf8 », sinon un « rm .htaccess » suffit
    – Puis renommer le fichier encodé en ISO grâce à « mv .htaccess.iso .htaccess »
    – Un dernier « file .htaccess » confirme que l’encodage du fichier est modifié, puisqu’il retourne : ‘.htaccess: ISO-8859 text’

    Et c’est terminé. Les accents dans les boites de dialogue s’affichent correctement.

    Répondre
    • Ah super info Clément ! J’ai aussi eu ce problème mais j’avoue ne pas avoir cherché à creuser pour le corriger. C’est maintenant chose faite grâce à ton commentaire.

      Merci 🙂

  28. Bonjour Alex,
    SUPER ARTICLE !!!!

    J’ai juste eu un petit souci avec le code #Compression des fichiers statiques, le site plantait.
    Je ne suis pas du tout experte mais instinctivement j’ai mis les lignes AddOutputFilterByType… avant la fermeture de la balise et là mon site fonctionne normalement. Ai-je bien fait ?

    En tout cas MERCI, c’est bien la première fois que je trouve quelque chose d’aussi complet, très bon boulot !

    Répondre
    • Super Delphine !
      Merci beaucoup pour votre retour 🙂

      Concernant le bug, il y a peut-être une incompatibilité avec votre hébergeur. Vous pouvez tester si la compression est bien activée grâce à ce site.

  29. Merci Alex pour le super boulot, comme d’hab…

    Répondre
  30. Super article, complet tout ce qu’il me fallait, mais j’ai deux petits soucis
    Quand je met le code dans fichier htacces pour le répertoire wp-content, les images du plugin Universal Star rating n’apparaissent plus dans l’admin et le site.

    Et si je met le code pour désactiver le hotlinking sur les images, elles n’apparaissent plus sur le site, à la place j’ai le texte pas touche aux images, or je veux afficher mes images mais empêcher le hotlinking.

    Merci pour un éventuel coup de main.

    Répondre
    • Bonjour Jeff,
      A mon sens, il faudrait ajouter une exception pour ces images. Après, difficile à dire sans être dessus…
      Sinon il faudra se passer de ce code :/

  31. Je tiens à dire un gros bravo et merci pour cet article. Pour moi il est exceptionnel car j’avais toujours peur de toucher à ce fichier et grâce à cet article j’ai plus de confiance et je peux enfin faire quelques modifications utiles.

    Un GROS GROS merci Alex et ce genre de travail me confirme encore pourquoi tu es l’un de mes blogs préférés dans le domaine. Bonne journée.

    Répondre
    • Merci beaucoup Florian, je suis ravi d’avoir pu t’aider à surmonter tes peurs avec cet article 🙂

  32. Merci au cuistot 😉 Alex pour cet article hyper intéressant.
    J’en sais bcp plus sur ce fameux fichier .htaccess grâce à ton article et vais m’amuser à tester et installer plusieurs choses que tu nous conseille, en espérant que tout se passe bien.
    Avec la possibilité de revenir au fichier initial donc pas d’inquiétude 😉
    Belle journée.
    Marie

    Répondre
    • Merci pour ton commentaire Marie 🙂
      Bonne continuation avec ton site !

  33. Bonjour Alex,

    Merci beaucoup pour cet article qui m’éclaire énormément.
    Cependant j’ai une petite question, demain je fait une mise en ligne d’un site que j’ai travailler en local. Et en regardant à la racine du site, pas de fichier .htaccess ! J’imagine que cela va poser problème.. Dois-je créer le fichier moi-même ? Et sinon, sais-tu pourquoi n’est-il pas présent ?

    Merci d’avance !

    Répondre
    • Bonjour Alice,

      Si vous êtes sous Windows, il est normal que le fichier .htaccess ne soit pas présent (les fichiers commençant par un point ne sont pas autorisés). Une fois les fichiers de votre site envoyés sur ton serveur, tu pourras le créer (si tu te rends sur la page Réglages > Permaliens, cela devrait le créer automatiquement).

      Bonne continuation
      Alex

  34. Bonjour Alex,

    Je suis nulle en ht.access, ton article m’a permis de comprendre
    certaines choses.
    J’ai une question à laquelle je n’ai pas trouvé de réponse, comment
    faire, car mon thème ne me le permet pas seulement pour la date
    de l’article, de supprimer l’affichage de la date des commentaires,
    comme sur ton blog.
    Merci d’avance pour ta réponse
    Marie-Do

    Répondre
    • Bonjour Marie-Do,
      Merci pour ton message 🙂
      Pour ton problème de date, cela n’a rien à voir avec le fichier .htaccess. Tu as 2 solutions : tu peux la masquer en css avec un display:none sur la balise HTML de la date ou alors, supprimer l’affichage de la date dans ton thème. Ce n’est pas très détaillé mais c’est difficile d’en dire plus par commentaire.

      Bonne continuation
      Alex

  35. Sacré tutoriel Alex, chapeau et merci, je me pose une question, avoir 1000 lignes dans son fichier htaccess n’a aucune répercussion au niveau du chargement du site ?

    Répondre
    • Salut Michael,

      Effectivement 1000 lignes risquent d’avoir un certain impact sur ton site. Il faut tester. Après, ajouter des lignes peut permettre de gagner plus de temps qu’elles n’en font perdre 🙂

      Comme je l’ai dit, il faut tester.

  36. Bonjour et merci pour cet article très complet ! En effet, un des plus clairs 😉
    J’ai suivi vos conseils. J’ai toutefois un souci ce matin sur le site et depuis que j’ai mis en place tous ces .htaccess. En effet, certaines pages de mon site ne se chargent pas du premier coup. Il faut que je rafraichisse la page pour qu’elles s’affichent. Cela vous est-il déjà arrivé ? Je ne suis pas très « technique », mais j’ai comme l’impression que la restriction est trop forte pour l’un des répertoires. Merci pour vos avis

    Répondre
    • Bonjour Christine,

      Merci pour votre message 🙂
      Il faut que vous voyez quel code pose problème (il ne faut pas tout mettre d’un coup).
      Tenez-moi au courant.
      Alex

  37. Bonjour,
    Plusieurs codes fonctionnent sauf celui qui m’intéressait énormément : sur la protection du wp-includes => internal serveur erreur
    Une idée

    merci et bravo pour l’article !

    Répondre
    • Arf dommage ^^
      Cela vient peut-être de votre hébergeur. Avez-vous tenté de le contacter pour en savoir plus ?

      Tenez-moi au courant.
      Alex

  38. Super article très utile

    Je viens de me faire pirater un site que j’ai réinstallé et j’ai mis en place la plupart des paramètres du fichier .htaccess pour le sécuriser et l’améliorer

    Merci encore pour toute l’aide apportée avec les différentes recettes. On trouve ici de bon repas équilibrés

    Continuez !!!

    Répondre
    • Merci beaucoup Bruno 🙂
      A très bientôt

  39. Bonjour Alex ! Merci pour cette recette, moi qui suis un amateur de WordPress, je dois dire que j’ai de quoi cuisiner et être en bonne santé avec ton blog 😉

    J’ai une question : quand je crée un fichier (via Filezilla) dans mon wp-admin que je nomme .htaccess, mon éditeur de texte me le renomme .htaccess 2, car et si j’ai le malheur de le renommer en .htaccess, il me remplace mon .htaccess à la racine du site… J’ai donc fais un test pour voir si ce fichier « 2 » est pris en compte mais en testant sur ta partie « administration du site – wp-admin », je n’ai pas l’impression que le code soit pris en compte :/

    Aurais-tu une astuce? (mon éditeur est TextEdit sur Mac)

    Merci pour ton aide et toutes ces précieuses informations !

    Répondre
    • Hummm, cela vient peut-être de ton éditeur mais je ne peut pas être catégorique.
      Au pire, crée un fichier htaccess.txt et renomme-le une fois les informations ajoutées.

      A+

  40. Bonjour Alex
    J’aurais besoin d’un petit coup de pouce. Je viens d’installer le cms wordpress et je voudrais protéger le site par un mot de passe pour qu’il ne soit pas indexé par les moteurs durant son développement. J’aimerais savoir quel code appliquer dans le htaccess de wordpress seo et à quel endroit du code en place le mettre.
    Pour ma part je suis totalement novice dans le monde du web et il me semble important ici de saluer la qualité de votre site. Tous vos articles sont explicites, vont droit au but et permet réellement de progresser dans la maitrise de wordpress.
    Bonne continuation.

    Répondre
    • Bonjour Emile,

      Reportez-vous à la section « Ajouter une seconde authentification » pour arriver à mettre en place ce que vous désirez.

      Bonne continuation

  41. Bonjour,

    Merci pour cet article très utile et très riche.
    J’ai lu récemment un article précisant que les commandes devaient être écrites avant le contenu des balises
    # BEGIN WordPress […] # END WordPress, car WordPress peut éditer n’importe quel code compris entre ces dernière. Qu’en pensez-vous puisque dans vos exemples, les codes sont ajoutés après ?
    Cet article figure dans la revue « Webdesin Hors série n° 36 : WordPress, maîtrisez de nouvelles compétences pour de meilleurs blogs ». L’article p. 42-45 porte le titre « Sécuriser votre site WordPress face aux hackers » et aborde le fichier htaccess p. 44-45. Pourrriez-vous me dire ce que vous pensez de la remarque concernant la position des codes avant ou après ?

    Répondre
    • Bonjour Dominique,

      Merci pour votre commentaire. Concernant votre question, je n’ai jamais vraiment prêté attention à l’emplacement des balises BEGIN et END WordPress et je n’ai jamais eu de soucis. Il y a peut-être des cas précis où des problèmes se posent mais je n’en ai pas connaissance.

      Au plaisir

  42. Merci !

    Répondre
  43. Bonjour,

    Merci pour ce tuto très utile et bien documenté. J’ai deux questions à propos du hotlinking.
    1. Cette commande est elle valable pour les pdf en ajoutant par exemple pdf dans la liste comme : (jpg|jpeg|png|gif|pdf) ? Je pose cette question, car il existe hélas de multiples sites qui affichent nos pdf pour leurs propres comptes dans le but de vendre de la pub.
    2. Cette interdiction va t-elle empêcher Google d’afficher mes images dans son moteur de recherche ? Si oui, il me semble que cela aura une incidence sur le référencement. Bon on ne peut pas tout avoir c’est vrai.

    Merci de nous donner la bonne recette.

    Répondre
  44. Merci un très bel article très complet…

    Répondre
  45. Bonjour Alex,
    Super article ! J’ai pu paramétrer mon site sans aucun problème.
    J’ai cependant une question qui concerne le cache:
    L’utilisation d’un plugin de cache permet de paramétrer à peu près les mêmes choses et offre un bouton pour nettoyer le cache en un clic.
    Comment fait-on donc pour nettoyer le cache de mon site manuellement ?
    Merci !

    Répondre
    • Bonjour Maxime,

      Un plugin de cache ne gère que ce qui concerne le cache, pas la sécurité.
      Ton plugin devrait avoir une fonction pour vider ton cache.

      Bonne continuation et merci pour ton retour sur l’article !

    • Bonjour Alex, merci pour ta réponse. Mais j’ai dû mal m’exprimer dans mon précédent commentaire.
      Ma question était de savoir comment faire pour vider le cache d’un site WordPress manuellement ? Sans avoir besoin de recourir à un plugin.
      Merci.

  46. L’article le plus complet à ce sujet ! Des années que je passe par un plugin (iThemes Security) pour ca et je viens de le faire avec tes codes, tout fonctionne et ca a réduit le poids du fichier htaccess de 50% !

    Juste une question, la ligne que tu dis comme importante :
    Options +FollowSymLinks
    Elle me fait une erreur 500 (je suis sur OVH), ca laisse une ouverture importante sans ?

    Répondre
    • Merci pour ton retour Antonin, content de voir que les astuces de cet article ont pu t’aider 🙂

      Pour le Options +FollowSymLinks, retire-le si cela fait planter ton serveur.
      L’article ne peut pas correspondre à toutes les configurations des hébergeurs.

      A+

  47. Bonjour Alex,

    Merci pour ce super article, j’ai testé ton code pour le passage de mon site en https, en faisant un simple copier-coller sur mon htaccess et oups erreur serveur… N’étant pas un initié, j’ai sans doute fait une erreur, dois-je modifier les 2 lignes que tu indiques ? Si oui de quelle façon ?

    Merci bcp.

    Répondre
    • Salut Thomas,

      Certaines règles sont contradictoires dans le fichier donc il est normal que cela ne fonctionne pas. Utilise juste les règles dont tu as besoin 😉

  48. Pour la maintenance j’ai un dossier « maintenance » avec dedans un joli index.html que je déplace en racine le temps de faire mes affaires… et que je remet à sa place une fois fini.
    Sinon super récap pour le Htaccess, ça va me servir très souvent… 🙂

    Répondre
    • Ca fonctionne aussi 🙂

  49. Bonjour,
    Merci pour le tuto bien utile. Quelques questions pratiques après une telle mise en place :
    1) des options du htaccess sont-elles bloquantes lors de mises à jour de plugins un ou de wordpress ? Si oui lesquelles ?
    2) quelle procédure simple nous invitez-vous à réaliser lorsque une mise à jour est à faire ?
    Merci

    Répondre
    • Bonjour Juan,

      Pour répondre rapidement :
      1) Peut-être
      2) Supprimer les règles une par une pour voir ce qui cause problème puis la corriger ou la retirer si vous n’y arrivez pas

      Bonne continuation

  50. Bonjour,

    merci pour ce super article.

    Mon souci est que index.php/accueil est présent avant le nom de chaque page dans les urls de mon site wordpress nouvellement créée. j’ai des permaliens en option simple et je suis sur un serveur windeows dédié…

    je me demande si une option de htaccess permettrait d’enlever index.php.accueil/ de chaque url ?

    Répondre
    • Bonjour,

      Comme ça je dirais que cela devrait pouvoir se régler au niveau de Réglages > Permaliens mais je ne connais pas bien les configurations Windows (d’ailleurs, je ne suis même pas certain qu’il y ait des fichiers .htaccess sur les serveurs sous Windows).

  51. Bonjour Alex et la communauté des cuistots 🙂 Si j’installe WP super Cache dois-je supprimer tes lignes de code concernant le cache ? Si je laisse laisse les deux, cela peut-il créer un conflit ? WP super cache fait-il mieux que ces lignes de code ? D’avance merci pour vos réponses ! Belle journée

    Répondre
    • Bonjour André,
      Je ne connais pas WP Super Cache donc je ne peux pas trop te répondre. Je te conseille de tester sur un site de développement et de voir ce que ça donne.

  52. Bonjour Alex,
    La partie rediriger vers HTTPS fonctionne bien mais est-il possible de faire l’inverse ? Pour un site accessible prioritairement en HTTP, si qq1 tente le HTTPS, le rediriger vers HTTP.
    J’ai trouvé ceci :
    RewriteEngine on
    RewriteCond %{HTTPS} on
    RewriteRule .* http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

    Mais ça ne fonctionne pas. 🙁

    Répondre
    • Salut Jérôme,

      Essaie avec ce code :

      # Redirection vers HTTPS
      RewriteCond %{SERVER_PORT} ^443$
      RewriteRule ^(.*)$ http://%{SERVER_NAME}%{REQUEST_URI} [L,R]

    • ça ne change rien.
      C’est la première fois que je suis confronté à un client qui teste son site en https alors que ça n’avait jamais été évoqué.

    • Du coup je ne vois pas trop Jérôme, désolé de ne pas pouvoir vous aider davantage :/

    • Merci quand même pour la réflexion.
      Bonne continuation.

  53. Merci beaucoup pour cet article.
    Je teste o2switch, et pour mon premier site chez eux, ces modifications fonctionnent sans erreur. Je crois que je vais finir par tout migrer chez eux 🙂
    J’avais notamment besoin de forcer la redirection vers https, voilà qui est fait.
    L’augmentation de la taille limite php a fonctionné aussi en ne touchant que le fichier htaccess.

    Répondre
    • Content de voir qu’O2Switch te plait Samson 🙂

    • Merci Alex. J’ai pleins de galères chez OVH, sur l’hébergement comme sur le service mail. Et o2switch sont très sympa, à l’image de WP Rocket, et ils sont à 1h de chez moi, je consomme local en hébergement web aussi 🙂

  54. Grand merci pour ce tuto d’une grande clarté !

    Répondre
    • Merci Emmanuel 🙂

  55. Moi qui n’y connais rien de rien, j’ai suivi chaque étape à la lettre, merci ! Mais du coup, ça n’a pas réglé mon problème principal malheureusement…. J’ai un script malveillant qui s’insère quotidiennement dans mon header.php Je suis obligée de lancer un scan avec wordfence 2 fois par jour pour le supprimer au plus vite sinon c’est la blacklist Google assurée. C’est extrêmement pénible ! Je ne sais pas d’où pourrait venir le problème… Tout est à jour, j’ai changé tous les mots de passe plusieurs fois, en plus des modifications expliquées dans cet article, j’ai le plugin wordfence (firewall actif) et le plugin WP-security. J’ai édité le nom des tables… Bref, pour une débutante comme moi c’est un vrai casse-tête. Une idée pour m’aider peut-être ? 🙁 A très bientôt !

    Répondre
    • Merci pour ton retour Laurie 🙂
      Pour ton problème, je te conseille de faire appel à un professionnel pour nettoyer tout ça. Il y a des entreprises comme Sucuri qui sont spécialisées là dedans.

    • Bonjour,
      tu dois avoir un fichier Backdoor sur ton espace qui régénère ces fichiers.
      Regardes dans l’administration de WordPress si le nombre d’utilisateurs affiché correspond bien au nombre d’utilisateurs listés.
      Et en dernier recours, recharge une version neuve de WP, des extensions et du thème.
      Supprime toutes les extensions et thèmes que tu n’utilises pas, en particulier « hello Dolly ».
      Courage courage…

  56. Hello la Marmite !
    Une question que pensez-vous de ce code pour :

    #Empêchez l’exécution de scripts php dangereux
    Parfois, il suffit d’un thème ou d’un plug-in vérolé, et sans le savoir celui-ci va planquer un petit fichier dans un sous-dossier de « wp-content/upload ». La solution pour empêcher leur exécution est de créer un fichier .htaccess spécialement pour le dossier « upload » et d’y écrire les lignes suivantes (en remplaçant les IP d’exemples par celle du serveur de votre site ainsi que la votre au cas où) :

    Deny from all
    allow from 255.255.255.255
    allow from 121.121.121.121

    Proposé par : https://www.aetherconcept.fr/securisez-votre-site-wordpress-en-11-points/

    Est-ce utile ou pas ? Quelqu’un a testé ? Merci pour vos réponses

    Répondre
    • Bonjour André,

      En fin d’article vous trouverez un morceau de code qui permettra d’empêcher l’exécution de fichiers PHP à partir du répertoire uploads. Votre solution me semble plus radicale mais équivalente 🙂

  57. Merci pour cet article, je viens de blinder mon .htaccess

    Répondre
    • Il n’y a pas de quoi 😉

  58. Bonjour, je cherche une astuce pour empêcher l’accès à mes répertoires et j’ai donc appliqué « Désactiver l’affichage des répertoires » en mettant le bout de code dans le htaccess à la racine de mon FTP (j’ai également essayé avec celui du répertoire « www ») mais ça ne change rien je peux encore afficher les fichiers de « uploads » par exemple. J’ai essayé de me déconnecter en me disant que c’était par ce que j’étais l’admin mais même de cette manière le répertoire s’affiche. Une idée du problème svp ? Je suis chez wordpress avec hébergement chez ovh si des fois ça change quelque chose… Merci !

    Répondre
    • Bonjour Laura,
      Il est normal que l’on puisse afficher un fichier (par exemple une image) si l’on en connait le chemin. En revanche, si vous tapez votresite.com/wp-content/uploads/ et que vous voyez la liste des fichiers, c’est qu’il y a probablement une erreur au niveau du code qui a été inséré dans le fichier .htaccess

  59. Bonjour Alex;
    merci pour toutes ces instructions.
    Depuis que j’ai « sécurisé » mon blog, je n’arrive plus à éditer les fichiers php depuis le tableau de bord de wordpress. Je suppose que c’est normal mais j’ai besoin de passer la main à quelqu’un pour quelques modifs donc je voudrais supprimer ce qui empêche d’utiliser wpide. Une idée ?

    Merci 🙂

    Répondre
    • Bonjour Béné,

      Il vaut mieux que tu fournisses un accès FTP à ton collègue car en cas d’erreur de modification le site sera planté.
      Bonne continuation

  60. Bonjour,
    Excellent article comme tous ceux du site d’ailleurs 🙂
    Par contre j’ai eu un problème avec le .htaccess du wp-include.
    Une fois en place, l’éditeur visuel de mes pages (tinymce) est devenu inactif.
    En lançant un inspecteur de fonction j’ai remarqué l’erreur (tinymce not defined).
    La suppression du fichier .htaccess dans le répertoire wp-include a résolu le problème.
    Le problème se produit chez plusieurs hébergeur (OVH, WHC…)
    Des retours sur ce problème ?

    Répondre
    • Salut Manu,

      Cela est peut-être lié à l’hébergeur. Car de mon côté ça fonctionne bien.
      Attention donc…

  61. Merci pour cet article et surtout les détails qui expliquent bien chaque code avec son effet ou sa conséquence.
    Bonne continuation à vous.

    Répondre
    • Avec plaisir Philippe 🙂

  62. Bonjour,
    Merci pour cet article qui m’a permis de blinder mon site et d’améliorer largement ses performances !
    Seul petit problème : j’avais installé mainwp pour la maintenance et depuis que j’ai changé le fichier .htaccess , cela ne fonctionne plus; mon mainwp child n’est plus connecté au site de maintenance. Je suppose qu’il faut que j’essaie d’enlever les codes un par un pour voir ce qui bloque ?
    En tout cas merci beaucoup !

    Répondre
    • Bonjour Mathilde,

      Humm, essayez de retirer les codes un à un pour voir celui qui pose problème. C’est peut-être celui qui doit bloquer les attaques indésirables. A tester.

  63. Excellent ! Très bon article qui va aider les débutants tels que moi à appréhender ce genre de fonctionnalités. 🙂

    J’ai tenté de réaliser la redirection de la version www de mon blog vers la version sans www, mai sans succès malheureusement. Le code n’a aucune incidence dans mon cas. Y a t-il un autre prérequis ?

    Répondre
    • Salut Corentin,

      Il doit y avoir un souci quelque part car ça fonctionne bien de mon côté :/
      Ravi que le blog te plaise en tout cas !

  64. MERCI , j’ai testé mon site qui n’etait pas du tout securisé et grace a vous maintenant il l’ai 😀

    Merci

    Répondre
    • Avec plaisir Reynald !

  65. Merci beaucoup pour ce super article !
    J’ouvre mon site marchand la semaine prochaine et ça fait 3 jours qu’OVH me dit de faire des manipulations au niveau de mon fichier .htaccess et que rien ne fonctionne… Grâce à vous, tout s’est résolu : la redirection automatique vers le https fonctionne. Je suis maintenant certaine que les visiteurs navigueront bien sur la version sécurisée de mon site !!
    Encore merci 🙂

    Répondre
    • Merci Marion, il n’y a pas de quoi 🙂

  66. Merci pour cet article très riche.

    Répondre
  67. Ah oui, un vrai beau tuto (qui ne me bloque pas mes sites pour une fois).
    Merci

    Petite question : Tout ce qui est ajoutable le htaccess à la racine doit-il être ajouté également dans les 3 autres (ceux des dossiers wp-admin, wp-content…) ?

    Répondre
    • Bonjour Raphaël, non cela n’a pas le même but. Tout ce qui es à la racine concerne tout le répertoire ( et les répertoires enfants). Ce qui se trouve dans le wp-admin, wp-content ne concerne que ces répertoires.

    • Merci pour cette réponse. C’est bien ce que je pensais mais je préférais être sûr.

  68. Salut Alex,

    Wow, quel Article !

    Je suis simplement venu pomper le .htaccess de base pour fixer un problème. Mais ton article à l’air surpuissant.

    Dans les ToDoRead ! Merci

    Répondre
  69. Bonjour,
    J’ai déjà utilisé quelques-un de ces codes sur un autre fichier htaccess sur un autre site WP. Sur le nouveau, le code disparaît automatiquement après disons, quelques heures.
    Il ne reste que le début du code :
    # BEGIN WordPress
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ – [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    # END WordPress
    Bizarre non ? Est-ce déjà arrivé à l’un ou l’une d’entre vous ?
    Cordialement.

    Répondre
    • Bonjour Serge, à mon avis vous devez ajouter les codes entre les balises de début et de fin. Cependant, il se peut également qu’un plugin de sécurité ou bien votre hébergeur réinitialise votre fichier après modification.

  70. Bonjour Nicolas,
    J’ai encore essayé ce matin, le code est resté, puis je reviens voir
    htaccess et tout a disparu.
    Je n »ai pas de plugin de sécurité, je n’en ai pas besoin car je fais
    des enquêtes policières avec mes « Nouvelles Policières » (LOL).
    Je vais essayer de voir avec Ovh, mais ils ne s’occupent pas de
    Wordpress, je ne sais donc pas s’ils vont se pencher sur ce problème.
    Cordialement

    Répondre
    • Désolé de ne pas pouvoir vous aider d’avantage Serge. Je vous invite à vous rapprocher d’un freelance, cela pourrait être la solution la plus efficace.

  71. Merci beaucoup d’avoir pris le temps de répondre.
    Cordialement.

    Répondre
    • Bonjour,
      J’ai résolu le problème du ficher htacces en faisant une restauration sur mon hébergement. Les scripts ajoutés ne disparaissent plus après cette manipulation.
      Par contre, le script « protéger le fichier wp-config » bloque le site.
      Cordialement.

  72. Bonjour,
    Je viens de mettre votre HTACCESS…Ma foi, les pages intérieures fonctionnent (avec le réglage http://trouverlebienetre.​fr/exemple-article/) mais quand je reviens vers la page d’accueil j’ai une erreur !
    J’ai essayé un autre fichier (fonctionnel sur un autre site) j’ai toujours le même problème..
    Une piste ?
    Merci d’avance !

    Répondre
    • Bonjour SB, je ne peux pas vraiment vous aider, il faudrait y regarder de plus près. N’hésitez pas à faire un appel à un freelance si le problème n’est pas résolu.

  73. Bonjour,
    le code pour Rediriger les visiteurs venant site vers un autre, n’a pas fonctionner chez moi, j’ai dû mettre celui là
    http://pastebin.com/S1BFvPjL
    Juste pour rediriger les visiteurs de mon NDD .fr au NDD. com, même NDD, juste le préfixe change.
    Merci

    Répondre
  74. Bonjour,
    J’utilise le plugin WP Fastest Cache et ce matin, je vois que les outils de webmaster de Google, voit les dossiers /wp-content/cache/all
    Puis-je bloqué ça?
    Merci

    Répondre
    • Bonjour Logganeo, je n’ai pas bien compris votre question

  75. Bonjour Alex et la marmite ! 🙂
    Pour les utilisateurs de wordfence : si vous limitez l’accès à l’administration du site à un ip en particulier (via un htaccess) cela va bloquer les scans de wordfence.
    Pour résoudre ce problème, rajouter ces lignes dans le htaccess de wp-admin (en modifiant les xx par votre ip évidement)
    Je me suis arraché les cheveux avant de trouver cette solution !!!! 😉

    order deny,allow
    deny from all
    # MON IP A MOI
    allow from xx.xx.xxx.xx

    Order allow,deny
    Allow from all
    Satisfy any

    Order allow,deny
    Allow from all
    Satisfy any

    Order allow,deny
    Allow from all
    Satisfy any

    Répondre
    • Oups… cela ne prend pas les caractères spéciaux … donc il manque des lignes.
      Je colle ici les lignes sans les caractères et si alex veux bien les réécrire proprement je peux lui envoyer par mail…

      Limit GET POST PUT
      order deny,allow
      deny from all
      MON IP A MOI
      allow from 78.240.119.184
      Limit
      Files admin-ajax.php
      Order allow,deny
      Allow from all
      Satisfy any
      Files
      Files admin-post.php
      Order allow,deny
      Allow from all
      Satisfy any
      Files
      Files « \.(css|gif|png|js)
      Order allow,deny
      Allow from all
      Satisfy any
      Files

  76. Merci Alex pour ce super article, j’étais loin de m’imaginer tout ce qu’on pouvait gérer via .htaccess.
    Tu ne parles pas de la possibilité de repousser la taille des médias envoyés sous WordPress.
    Pour se faire j’ai insérer ce code dans mon .htaccess:
    php_value upload_max_filesize 200M
    php_value post_max_size 200M
    ça marche en local, mais quand est-il sur un serveur mutualisé ?

    Répondre
    • Bonjour Michel,

      Merci pour le partage.
      Je n’ai pas fait le test dont vous parlez mais peut être que d’autres visiteurs pour nous aider à ce sujet.

  77. Bonjour Nicolas,

    Je suppose qu’il faut préalablement s’assurer auprès de l »hébergeur de disposer de l’espace suffisant pour faire tourner ses médias. Il y a des sliders WP très gourmands en ressources.

    Répondre
  78. Pour lutter, contre les attaques DDOS qui viennent surcharger ton serveur :
    – la double authentification de l’admin dont tu as parlé
    – L’ajout de la ligne suivante dans le .htaccess principal
    # protection du fichier xmlrpc
    RewriteRule ^xmlrpc\.php$ « http\:\/\/0\.0\.0\.0\/ » [R=301,L]

    source mon hébergeur : Gandi

    Répondre
  79. Article impec entre autres astuces mon site cartonne et vitesse de navigation accélérée également ^^

    Sauf un petit hic avec les codes :
    – « limiter l’accès à l’administration » : Le site est inaccessible si l’adresse IP n’est pas renseignée.
    – « Ajouter un 2e code d’authentification sur l’administration du site »; Les visiteurs doivent également saisir un id + mdp.

    Peut-être me suis-je trompée de dossier « wp-admin »… Je regarderais sa de plus prêt…

    Merci encore!!

    Répondre

Laisser un commentaire

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

La Marmite ne peut malheureusement pas fournir de support. Merci d'en tenir compte dans votre commentaire 😉

Si vous ne lui en voulez pas, donnez-lui un j'aime sur Facebook :



195 Shares
Share79
Tweet43
Share73