Optimiser son fichier .htaccess permet de gagner en rapidité en compression de fichier et bien d’autres encore !!! C’est la base de tout ! WordPress n’échappe pas à la règle. Dans ce bref article, je vous propose de l’adapter au mieux !
Table des matières :
- 1 Objets :
- 2 Préparation :
- 3 Protocole de Test
- 4 Protéger le fichier htaccess :
- 5 Protéger le fichier wp-config.php :
- 6 Redirection vers HTTPS :
- 7 Désactiver l’affichage du contenu des répertoires :
- 8 Masquer les informations du serveur :
- 9 Activation du suivi des liens symboliques :
- 10 Choix du fuseau horaire :
- 11 Désactiver le hotlinking de vos images :
- 12 Protections diverses (XSS, clickjacking et MIME-Type sniffing) :
- 13 Browser Caching :
- 14 KILL THEM ETAGS :
- 15 Cache-Control Headers :
- 16 Disable caching for scripts and other dynamic files :
- 17 Compressions des fichiers statiques :
- 18 MOD_DEFLATE COMPRESSION :
- 19 Compression GZIP :
- 20 Pour les navigateurs incompatibles :
- 21 Ne pas mettre en cache si ces fichiers le sont déjà :
- 22 Les proxies doivent donner le bon contenu :
- 23 Protection contre les injections de fichiers
- 24 Désactiver l’accès à certains scripts :
- 25 Éviter que l’on découvre l’identifiant d’un auteur :
- 26 Définir l’encodage des caractères par défaut :
- 27 Limiter le spam des commentaires :
- 28 L’impact sur Mon Rank GTEMETRIX ?
- 29 Liste d’article sur le sujet :
Objets :
Le fichier .htaccess est généralement à la racine d’un site web, il permet de “communiquer” avec le serveur, et est utile aux aspects suivants:
- Protège l’accès à une page / un dossier ou répertoire / un site
- Gère la réécriture des URL
- Définit de éventuelles redirections
- Définit les pages d’erreurs personnalisées
- Limite l’accès à certains utilisateurs
- Interdit le listing des répertoires
- Donne des consignes au navigateurs (mise en cache, compression, etc.)
Préparation :
Avant toute chose, faire une copie du fichier, le modifier depuis son poste. En cas de problème, conserver une copie renommé à la racine du site.
Réaliser étapes par étapes étapes les manipulations et surtout tester à chaque fois.
Pour ce test, j’utilise Notepad ++ et Filezilla.
Connecté en Filezilla à votre serveur, se placer dans Affichage > Afficher les fichiers cachés
Se placer à la racine de son site et rapatrier son fichier .htaccess que l’on va éditer step by step.
Protocole de Test
Personnaliser le code d’un fichier .htaccess
est assez simple (surtout avec les morceaux de code que propose la suite de cet article 😉 ) mais comme expliquez plus tôt, à réaliser étapes par étapes.
Avant toute modification, faire une sauvegarde du contenu initial de votre fichier .htaccess
. Pour ce faire, vous pouvez :
- Dupliquer le fichier
.htaccess
de votre serveur en un fichier.htaccess-old
- Copier le contenu du fichier dans un fichier texte sur votre ordinateur dans Notepad ++
En cas de problème, renommer facilement le contenu d’origine en retirant le -old.
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
- Poussez le code via Filezzila
- Actualisez votre site pour voir si tout va bien
L’actualisation du 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 :
Protéger le fichier htaccess :
Permet de protéger le fichier .htacess
Ce qui fonctionne bien aussi c’est de mettre le fichier en droit : 444
# Protéger le fichier htaccess <Files ~ "^.*.([Hh][Tt][AaPp])"> order allow,deny deny from all satisfy all </Files>
Protéger le fichier wp-config.php :
Tout aussi important que le fichier .htacess, protéger le fichier wp-config.php. Ce fichier contient toutes les informations de connexion à votre site et votre base de données, un vrai trésor pour les hackers. Pour sécuriser ce fichier, il suffit d’ajouter le code suivant dans votre fichier .htaccess.
# Protéger le fichier wp-config.php <files wp-config.php> order allow,deny deny from all </files>
Redirection vers HTTPS :
Pourquoi ? Google a récemment reconnu que le HTTPS était un facteur de référencement (un « ranking factor »).
# Redirection vers HTTPS RewriteCond %{SERVER_PORT} ^80$ RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R]
Mais il ne faut pas trop surestimer l’impact SEO du HTTPS. Si le HTTPS est un facteur de référencement, c’est un facteur très faible.
Désactiver l’affichage du contenu des répertoires :
Certains dossiers ne contiennent pas d’index, dès lors, peux apparaitre ainsi la liste des fichiers contenus du dossier, une porte d’entrée, une faille potentielle pour les hackers. Pour éviter cette éventualité, il faut donc protéger les répertoires.
# Désactiver l'affichage du contenu des répertoires Options All -Indexes
Masquer les informations du serveur :
La première chose à faire lors de la mise en production d’un serveur Apache est de faire en sorte qu’il n’affiche pas l’ensemble de ses informations de versions afin d’éviter à tout attaquant potentiel de connaitre trop d’informations sur sa machine cible.
# Masquer les informations du serveur ServerSignature Off
Activation du suivi des liens symboliques :
A ma connaissance, la fonction Options FollowSymLinks, sert avec des rewriting en 301 pour remédier aux problèmes des erreurs d’exploration par exp: RewriteRule forumquinexisteplus/(.*) monurlrediret [L,R=301].
# Activation du suivi des liens symboliques Options +FollowSymLinks
Choix du fuseau horaire :
Le fuseau Horaire, quel variable importante !
# Choix du fuseau horaire SetEnv TZ Europe/Paris
Désactiver le hotlinking de vos images :
Le hotlinking est une pratique courante qui consiste, le plus souvent, à afficher une image en utilisant l’adresse URL en provenance d’un autre site où elle est publiée. En fait, au lieu de stocker l’image sur son serveur, le hotlinkeur crée un lien direct vers le serveur d’origine. Totalement illégale et pourtant ca m’est déjà arrivée !
# Désactiver le hotlinking de vos images RewriteCond %{HTTP_REFERER} !^$ RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?blog.zenmail.biz [NC]
Protections diverses (XSS, clickjacking et MIME-Type sniffing) :
Ce type d’attaque se produit lorsqu’un site malveillant piège un utilisateur pour qu’il clique sur un élément caché d’un autre site que le site malveillant a chargé dans un cadre caché ou dans un iframe.
# 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>
Browser Caching :
Que signifie donc ce code mystérieux ? On définit en fait une “date d’expiration” en fonction du type de fichier, d’où le “ExpiresByType”. Regardez chaque ligne de droite à gauche.
# Browser Caching <IfModule mod_expires.c> ExpiresActive On ExpiresDefault "access plus 7200 seconds" ExpiresByType image/jpg "access plus 1 month" ExpiresByType image/jpeg "access plus 1 month" ExpiresByType image/png "access plus 1 month" ExpiresByType image/gif "access plus 1 month" AddType image/x-icon .ico ExpiresByType image/ico "access plus 1 month" ExpiresByType image/icon "access plus 1 month" ExpiresByType image/x-icon "access plus 1 month" ExpiresByType text/css "access plus 1 month" ExpiresByType text/javascript "access plus 1 month" ExpiresByType text/html "access plus 7200 seconds" ExpiresByType application/xhtml+xml "access plus 7200 seconds" ExpiresByType application/javascript A2592000 ExpiresByType application/x-javascript "access plus 1 month" ExpiresByType application/x-shockwave-flash "access plus 1 month" </IfModule>
On dit au navigateur : “A partir du moment où le lecteur accède à la page pour la première fois (“access”) et pendant telle durée (1 month = 1 mois ; 1 year = un an par exemple), tu mémorises tel type de fichier (par exemple, une image au format png ; une vidéo au format mp4).
KILL THEM ETAGS :
Le ETag fait partie du protocole HTTP, c’est un mécanismes qui influe sur le cache, permettant à la base, d’être plus efficace. A l’aide de requête, il renseigne les mises à jour faites sur le site, ici, il sera désactivé (car ce renseignement sera donnée d’une autre façon au serveur, inutile donc de le faire doublement), diminution du nombre de requête, optimisation de la bande passante.
# KILL THEM ETAGS Header unset ETag FileETag none
Cache-Control Headers :
L’en-tête (header) HTTP Cache-Control
est un en-tête standard utilisé pour définir la politique de cache des contenus, aussi bien dans les requêtes que les réponses. Les règles (ou directives) de gestion du cache ne s’appliquent que dans un sens, donc une règle dans une requête ne signifie aucunement que la même règle sera présente dans la réponse.
# BEGIN Cache-Control Headers <IfModule mod_headers.c> <FilesMatch ".(ico|jpe?g|png|gif|swf|css|gz)$"> Header set Cache-Control "max-age=2592000, public" </FilesMatch> <FilesMatch ".(js)$"> Header set Cache-Control "max-age=2592000, private" </FilesMatch> <filesMatch ".(html|htm)$"> Header set Cache-Control "max-age=7200, public" </filesMatch>
Disable caching for scripts and other dynamic files :
Nous allons ici désactiver le cache pour tout ce qui est dynamique, script etc …
# Disable caching for scripts and other dynamic files <FilesMatch ".(pl|php|cgi|spl|scgi|fcgi)$"> Header unset Cache-Control </FilesMatch> </IfModule>
Compressions des fichiers statiques :
# Compressions des fichiers statiques IfModule mod_deflate.c
MOD_DEFLATE COMPRESSION :
Il incombe aux navigateurs d’envoyer un en-tête HTTP indiquant les types de pages compressées supportées . Si cet en-tête ne figure pas dans ceux reçus par le serveur, il lui suffit de ne pas activer la compression,. Le serveur répond alors de la même manière, grâce à Content-Encoding
, et en faisant suivre par le contenu compressé de la page.
Deux formats coexistent :
- Deflate, algorithme qui couple LZ77 et le codage de Huffman (zlib)
- Gzip, évolution de Deflate, un peu plus performant, mieux supporté, plus répandu
# MOD_DEFLATE COMPRESSION SetOutputFilter DEFLATE AddOutputFilterByType DEFLATE text/html text/css text/plain text/xml application/x-javascript application/x-httpd-php
Compression GZIP :
Le “Mod_Gzip” est un peu plus performant (fonctionne avec apache 1.x – pas compatible en mod_deflate)
# Compression Gzip <ifmodule mod_gzip.c> mod_gzip_on Yes mod_gzip_dechunk Yes mod_gzip_keep_workfiles No mod_gzip_can_negotiate Yes mod_gzip_add_header_count Yes mod_gzip_send_vary Yes mod_gzip_command_version ‘/mod_gzip_status’ mod_gzip_min_http 1000 mod_gzip_minimum_file_size 300 mod_gzip_maximum_file_size 512000 mod_gzip_maximum_inmem_size 60000 mod_gzip_handle_methods GET POST mod_gzip_temp_dir /tmp mod_gzip_item_include file .html$ mod_gzip_item_include file .php$ mod_gzip_item_include file .pl$ mod_gzip_item_include file .rb$ mod_gzip_item_include file .py$ mod_gzip_item_include file .cgi$ mod_gzip_item_include file .css$ mod_gzip_item_include file .js$ mod_gzip_item_include mime ^application/javascript$ mod_gzip_item_include mime ^application/x-javascript$ mod_gzip_item_include mime ^text/.* mod_gzip_item_include mime ^httpd/unix-directory$ mod_gzip_item_include handler ^cgi-script$ mod_gzip_item_include handler ^server-status$ mod_gzip_item_include handler ^server-info$ mod_gzip_item_include handler ^application/x-httpd-php mod_gzip_item_exclude mime ^image/.* </ifmodule>
# Pour les navigateurs incompatibles BrowserMatch ^Mozilla/4 gzip-only-text/html BrowserMatch ^Mozilla/4.0[678] no-gzip BrowserMatch bMSIE !no-gzip !gzip-only-text/html BrowserMatch bMSI[E] !no-gzip !gzip-only-text/html
Important de prendre en compte tous les types de navigateurs !
Ne pas mettre en cache si ces fichiers le sont déjà :
Très explicite, il s’agit de ne pas mettre en cache les fichiers qui le sont déja.
# Ne pas mettre en cache si ces fichiers le sont déjà SetEnvIfNoCase Request_URI .(?:gif|jpe?g|png)$ no-gzip
Les proxies doivent donner le bon contenu :
# Les proxies doivent donner le bon contenu 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
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, afin de leur mettre des bâtons 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]
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 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]
É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.
# Éviter que l’on découvre l’identifiant d’un auteur RewriteCond %{QUERY_STRING} ^author=([0-9]*) RewriteRule .* - [F]
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
Limiter le spam des commentaires :
# É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>
Vous le savez autant que moi si vous avez un blog, le spam de commentaires est une vraie plaie, pour pallier à ce défaut combinez ce bout de code à Askimet, et vous résoudrez un grand nombre de vos problêmes.
Merci à :
- http://www.easy-hebergement.fr/foire-aux-questions/optimisez-votre-site-cache-et-compression
- https://openclassrooms.com/courses/le-htaccess-et-ses-fonctionnalites
- https://lehollandaisvolant.net/tuto/pagespd/
- http://www.deepintheweb.com/optimiser-un-fichier-htaccess/
- https://wpmarmite.com/htaccess-wordpress/#protection-injections
L’impact sur Mon Rank GTEMETRIX ?
Je vous ai dit que Rome ne se construisait pas en un jour ? Il faut beaucoup d’ajustement pour améliorer tous les paramètres. Avec quelques paramètres, j’ai réussi à avoir un score PageSpeed de 60 %, sinon le reste n’a que peux varié.
Liste d’article sur le sujet :
- Optimiser son fichier .htacess
- Optimiser le nombre et la qualité de ses Plugins.
- Plugin de Cache + optimisation JS
- Cloudflare
[…] Optimiser son fichier .htacess […]
1banking
gay chat ru=oulette https://bjsgaychatroom.info/
gay trans man dating https://gaypridee.com/