WordPress : quels CHMOD en toute sécurité ?
Déjà, le titre du post est pipé : il n’y a pas de site « sûr » à 100% !
Ce n’est pas une raison pour ne pas tenter de rendre la vie dure aux petits hackers du dimanche. Surveiller les permissions des fichiers sur son serveur est déjà un bon début, les sites WordPress dont les dossiers d’upload sont tous en 777 sont plus fréquent qu’on ne le croit…
Si vous vous posez la question c’est que vous avez une idée de ce que sont les permissions CHMOD des fichiers sur un serveur. Ce n’est pas le sujet de ce billet.
Pour WordPress, voici les normes à surveiller :
- Le fichier le plus sensible est wp-config.php (qui est soit sur la racine du site WordPress, soit sur un niveau supérieur du serveur, ce qui est mieux). Pour celui-là, 640 est parfait, vous pouvez même mettre 440 ou 400 si vous êtes parano !… Personne ne doit y accéder hors l’administrateur du site.
- Vient ensuite le fichier .htaccess : en dehors d’une modification des URL-rewritings (auxquels vous accédez par le menu « Réglage » > « Permaliens » du back-office de WordPress), il n’a en général pas besoin d’être accessible en écriture. Un CHMOD 644 est suffisant.
- Un seul fichier nécéssite un accès en lecture écriture totale (CHMOD 666), c’est le fichier sitemap.xml qui recense, pour les moteurs de recherches, les visiteurs de votre site.
- Un dossier va toujours nécessiter de permettre un accès en exécutions (755), c’est le dossier wp-content/ dans lequel sont stockés les fichiers images et autres médias, le thème, les plugins, etc. Attention, il s’agit du dossier (et des sous-dossier, comme « download » par exemple), jamais des fichiers qu’il contient.
Tous les autres fichiers du site seront en 644, à l’exception du fichier robots.txt (755)
De toute façon en cas de « fermetures » excessives », pas de soucis WordPress vous le rappellera en temps voulu.
Pour répondre à Kevin B.
Si je comprend bien, une bonne politique de droits CHMOD ne devrait PAS permettre la mise à jour de WordPress, du thème, des plugins.
Seul le dépôt des fichiers, pour les rédacteurs, si il existe des rédacteurs, devrait être autorisé, sinon, refuser également l’écriture dans le dossier contenant les medias.
Idem pour le propriétaire et groupe du site, si je comprend bien, on pourrait utiliser root:www-data sur l’ensemble des fichiers du site.
www-data permet à apache de faire tourner le site.
root est le propriétaire, seul autorisé à modifier les fichiers.
Aucune mise à jour n’est donc possible.
Pour faire la mise à jour, il faudra par exemple, la faire avec wordpress cli, en root.
Ou encore, redonner le propriétaire et le groupe pour www-data:www-data
( et changer alors, ( impérativement ? ) les différents CHMOD en les remettant par défaut 644 pour les fichiers et 755 pour les dossiers. )
Quoi qu’il en soit, être en 755 et 644 partout, avec un propriétaire www-data:www-data est une configuration standard adaptée au plein usage du site, et, à son développement. Pour la production, ce ne serait pas idéal, la politique de sécurité pouvant être améliorée, pour interdire toutes les modifications pouvant subvenir sans l’intervention directe de l’administrateur.
Merci pour ces explications très claires !
Merci beaucoup pour les explications, j’étais embêté avec ces problèmes de droits :/
CHMOD 755. Sur ce dossier upload teste en 777 (avec les sous-dossiers) mais ce n’est pas idéal en terme de sécurité…
Bonjour je rencontre un problème lié à la lecture du dossier wp-content/uploads par OVH.
Quelqu’un pourrai m’aider
Merci d’avance
Bonjour,
Merci pour cette article.
Petite question, pourquoi laisser des accès lecture ou execution à « Other ? »
Pour ma part, voici la liste des permissions appliquées à mon site :
chown monuser:www-data ./ -R
find ./ -type f -exec chmod 640 {} \;
find ./ -type d -exec chmod 750 {} \;
chmod 660 .htaccess
chmod 640 wp-config.php
chmod 660 sitemap.xml
chmod 750 robots.txt
find ./wp-content -type f -exec chmod 640 {} \;
find ./wp-content -type d -exec chmod 770 {} \;
J’ai un gros doute sur l’ensemble des sous-répertoires et fichiers dans wp-content. J’ai vu plusieurs sites qui conseillaient de ne pas mettre de droits en écriture à apache pour les themes et les plugins, mais dans ce cas comment wordpress se débrouille-t-il pour les updates de plugin ?
Autre question, quelles permissions mettez-vous au traductions (languages)
Merci
merci pour ces infos, ultra pratiques, surtout après ce qui c’est passé ces trois derniers mois, avec les attaques nombreuses et les virus sur revslider, pourtant intégré dans de très nombreux thèmes, même payants;)
Merci pour le récap, mais le wp-content en 755 est très souvent insuffisant, surtout pour les thèmes wordpress qui maintenant ont pas mal de plugins intégrés… mais sinon, merci pour ce récap bien pratique à transmettre à nos étudiants;)