Paramètres de sécurité avancés avec le fichier wp-config.php de WordPress

Les paramètres de sécurité avancés que vous pouvez appliquer avec le fichier wp-config.php de WordPress sont des configurations destinées à protéger l'accès à la base de données, renforcer les clés de session, désactiver l'édition de fichiers, gérer de manière sécurisée les sorties de débogage, imposer l'utilisation de SSL et limiter les chemins d'accès aux répertoires critiques. En résumé, wp-config.php est l'un des centres de sécurité de votre site WordPress ; avec les bonnes configurations, il réduit la surface d'attaque, diminue le risque d'accès non autorisé et limite les dégâts en cas d'incident de sécurité.

La plupart des propriétaires de site qui installent WordPress considèrent simplement le fichier wp-config.php comme un fichier technique dans lequel ils saisissent le nom de la base de données, le nom d'utilisateur et le mot de passe. Cependant, ce fichier est une partie critique de l'architecture de sécurité d'un site web en ligne. En particulier pour les sites de commerce électronique, les systèmes d'adhésion, les sites d'entreprise et les blogs à fort trafic, un fichier wp-config.php correctement configuré offre une solide défense contre les attaques de bots simples, la manipulation de fichiers via le panneau, les fuites de messages d'erreur et les tentatives de vol de session.

Dans ce guide, nous aborderons étape par étape les réglages de sécurité avancés pouvant être appliqués au fichier wp-config.php de WordPress pour le blog de Hostragons. Nous expliquerons simplement mais avec précision technique l’objectif de chaque paramètre, dans quelles situations nous conseillons de les utiliser et ce à quoi il faut faire attention avant l'application. Si vous n'avez pas encore une infrastructure d'hébergement fiable et à jour, le choix d'un hébergement WordPress de confiance est également important, en plus du durcissement du wp-config.php. À ce stade, les pages forfaits d'hébergement WordPress et solutions d'hébergement web sécurisées peuvent être pertinentes.

Qu'est-ce que le fichier wp-config.php et pourquoi est-il critique pour la sécurité ?

wp-config.php est le fichier de configuration situé dans le répertoire racine de WordPress, qui contient les paramètres de fonctionnement fondamentaux du site. WordPress se connecte à la base de données via ce fichier, lit les clés de sécurité, détermine le comportement de débogage, gère les opérations du système de fichiers et exécute certains paramètres avancés. Par conséquent, le contenu de ce fichier est beaucoup plus sensible qu'un simple fichier de thème.

Ce fichier contient généralement les informations critiques suivantes :

• Nom de la base de données, nom d'utilisateur, mot de passe et informations sur le serveur
• Clés de sécurité pour la session, connues sous le nom d’Authentication Unique Keys et Salts
• Préfixe de la table de la base de données
• Paramètres de débogage et de journalisation
• Constantes contrôlant le comportement de l'édition de fichiers, des mises à jour et de SSL
• Paramètres de fonctionnement tels que la limite de mémoire WordPress et le répertoire des fichiers temporaires

Si un attaquant accède au contenu de wp-config.php, il peut s'emparer des informations de connexion à la base de données. Dans ce cas, non seulement le panneau WordPress est à risque, mais aussi les comptes utilisateurs de la base de données, les enregistrements de commandes, les formulaires, les contenus et les données clients sensibles. C'est pourquoi protéger le fichier wp-config.php est l'une des étapes fondamentales de la sécurité de WordPress.

Avant de commencer : Plan de sauvegarde, test et accès

Une simple erreur de frappe dans le fichier wp-config.php peut entraîner un écran blanc sur votre site, une perte de connexion à la base de données ou une restriction d'accès au panneau d'administration. Pour cette raison, appliquez un plan de sécurité en trois étapes avant d'apporter des modifications.

1. Faites une sauvegarde complète

Commencez par sauvegarder le fichier et la base de données. Il ne suffit pas de télécharger le fichier wp-config.php sur votre ordinateur ; étant donné qu'un changement peut affecter la connexion à la base de données, une sauvegarde de la base de données est également cruciale. Si votre panneau de contrôle dispose d'une fonction de sauvegarde automatique, vérifiez la date de la dernière sauvegarde. Si nécessaire, créez une sauvegarde manuelle. Vous pouvez avancer avec le contenu de guide de sauvegarde de site web.

2. Appliquez les modifications une par une

Au lieu d'ajouter 8 ou 10 paramètres de sécurité en même temps, testez le site, le panneau d’administration et les formulaires critiques après chaque changement. Par exemple, commencez par désactiver l'édition de fichiers, puis vérifiez le site. Ensuite, configurez les paramètres de débogage. Cette méthode vous permet d'identifier rapidement quelle ligne a causé le problème en cas d'erreur.

3. Assurez-vous que vous avez accès à FTP ou au gestionnaire de fichiers

Si wp-config.php est enregistré incorrectement, vous pourriez ne pas pouvoir accéder au panneau WordPress. Assurez-vous donc que le gestionnaire de fichiers cPanel, SFTP ou l'accès sécurisé par transfert de fichiers fonctionne. L'utilisation de SFTP est plus sécurisée que FTP car la connexion est chiffrée. Un guide sur qu'est-ce que SFTP et comment l'utiliser pourrait être utile pour un accès sécurisé.

Résumé des paramètres de sécurité wp-config.php

Le tableau suivant résume de manière pratique les paramètres de sécurité fondamentaux et avancés décrits dans ce guide. Avant de mettre en œuvre sur un site en production, évaluez chaque ligne en fonction de vos besoins.

Renforcez les clés de sécurité et les valeurs Salt

La sécurité des sessions WordPress est soutenue par les clés AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, et leurs valeurs Salt dans wp-config.php. Ces clés rendent les cookies utilisateurs et les processus d'authentification des sessions plus sécurisés. Si ces clés sont faibles, par défaut, ou n'ont pas été changées depuis longtemps, la sécurité des sessions peut être compromise.

Il est recommandé de générer de nouvelles clés aléatoires via le générateur de clés secret officiel de WordPress. Ces clés sont généralement des valeurs aléatoires de plus de 64 caractères contenant des symboles, et leur devinette est pratiquement impossible. Il vous suffit de remplacer les anciennes clés dans wp-config.php par les nouvelles valeurs.

L'effet de ce changement est clair : toutes les sessions utilisateurs actives seront terminées et les utilisateurs devront se reconnecter. Si vous soupçonnez qu'un compte administrateur a été compromis, le renouvellement des valeurs Salt est une démarche d’urgence rapide. Il est également judicieux de renouveler ces clés tous les six mois ou en cas de suspicion de violation de sécurité.

Désactivez l'édition de fichiers via le panneau

Le panneau d'administration de WordPress dispose d'un éditeur qui permet de modifier les fichiers de thèmes et d'extensions. Bien que cette fonctionnalité puisse sembler pratique en phase de développement, elle pose de sérieux risques sur les sites en production. Si un attaquant a accès à un compte administrateur, il peut insérer du code PHP malveillant via l'éditeur de fichiers du panneau.

Vous pouvez désactiver l'édition de fichiers en ajoutant cette constante au fichier wp-config.php : define('DISALLOW_FILE_EDIT', true);

Ce réglage désactive l’éditeur de fichiers de thèmes et d'extensions dans le panneau WordPress. Nous recommandons de l'activer par défaut pour les blogs en publication, les sites d'entreprise et les magasins WooCommerce. Si des modifications de fichiers sont nécessaires, celles-ci doivent être effectuées via SFTP, Git ou des processus de déploiement sécurisés.

Comme option avancée, la constante DISALLOW_FILE_MODS peut également être utilisée pour restreindre le téléchargement et la mise à jour de fichiers. Cependant, cet réglage peut également empêcher les mises à jour des extensions et des thèmes, il doit donc être utilisé uniquement sur des systèmes très sensibles où aucune modification ne doit être faite en dehors des fenêtres de maintenance.

Adaptez les réglages de débogage au site en production

Dans un environnement de développement WordPress, activer la valeur WP_DEBUG est utile ; cela vous aide à voir les erreurs, à détecter les extensions incompatibles et à diagnostiquer les problèmes de thème. Cependant, sur un site en production, les messages d'erreur affichés à l'écran peuvent contenir des informations pouvant être exploitées par des attaquants, telles que le chemin du serveur, le nom de l’extension, l’emplacement du fichier, des indices sur des requêtes de base de données et la version de PHP.

Dans un environnement en production, l'approche sécurisée est la suivante : ne pas afficher les erreurs aux visiteurs, et les enregistrer dans un fichier journal si nécessaire. Pour cela, WP_DEBUG doit être faux ; si le débogage est nécessaire en phase de développement, WP_DEBUG_LOG doit être vrai et WP_DEBUG_DISPLAY doit être faux. Par exemple : define('WP_DEBUG', false); define('WP_DEBUG_DISPLAY', false);

Si vous devez enquêter sur une erreur, activez temporairement l'enregistrement, résolvez le problème et fermez-le à nouveau. Assurez-vous également que le fichier journal n'est pas accessible depuis un répertoire public, car le fichier debug.log peut parfois être créé à proximité de la racine du site et être lisible depuis l'extérieur sur des serveurs mal configurés. Une configuration d'hébergement correcte est donc cruciale pour réduire ces risques. comment gérer les logs de WordPress et hébergement WordPress sécurisé sont des contenus de suivi naturels à ce sujet.

Imposez l'utilisation de SSL et sécurisez le panneau d'administration

Le certificat SSL chiffre le trafic entre l'utilisateur et le serveur. Étant donné que l'accès au panneau WordPress se fait avec un nom d'utilisateur et un mot de passe, le trafic administratif doit obligatoirement se faire via HTTPS. Cela est d'autant plus important pour les équipes qui accèdent au panneau d'administration depuis des réseaux publics, des domiciles ou des connexions mobiles.

Dans wp-config.php, vous pouvez rendre l'utilisation de SSL obligatoire dans le panneau d'administration avec la constante : define('FORCE_SSL_ADMIN', true);

Pour que ce réglage fonctionne, un certificat SSL valide doit être présent sur votre nom de domaine. Si vous n'utilisez pas encore SSL, complétez d'abord l'installation du certificat. SSL est essentiel non seulement pour la sécurité, mais aussi pour la confiance des utilisateurs et le SEO. Pour voir les options SSL via Hostragons, vous pouvez consulter la page produits de certificats SSL et pour la gestion des noms de domaine, la page vérification de domaine et enregistrement de domaine.

Si vous rencontrez une erreur de redirection infinie après avoir imposé SSL, généralement, cela indique que les configurations de proxy, CDN ou de balanceur de charge ne sont pas interprétées correctement. Dans un tel cas, les en-têtes HTTPS côté serveur et les réglages de l'adresse du site WordPress doivent être contrôlés.

Gérez les informations de la base de données et le préfixe des tables de manière plus sécurisée

Les valeurs DB_NAME, DB_USER, DB_PASSWORD et DB_HOST dans le fichier wp-config.php permettent à WordPress de se connecter à la base de données. Ces informations doivent être robustes et disposer de privilèges limités. L'une des erreurs les plus courantes consiste à donner des droits excessifs à l'utilisateur de la base de données.

Pour un site WordPress en production, il est recommandé que l'utilisateur de la base de données n'ait que les permissions nécessaires. En général, les permissions telles que SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER et INDEX sont suffisantes. Utiliser des utilisateurs avec des droits étendus ayant accès à toutes les bases de données au niveau de la gestion du serveur dans la configuration de WordPress est risqué.

La bonne approche concernant le préfixe de table

Le préfixe de table par défaut de WordPress est wp_. Pour les nouvelles installations, le faire à partir d'une valeur différente et aléatoire rendra le travail des outils d'attaque automatique plus difficile. Par exemple, choisir un préfixe court mais difficile à deviner comme hr7x_ à la place de wp_. Cependant, changer le préfixe de table sur un site existant ne se limite pas à modifier la valeur de table_prefix dans wp-config.php ; les noms de table de la base de données et certains enregistrements usermeta doivent également être mis à jour.

Pour cette raison, si vous envisagez de changer le préfixe de table sur un site en production, commencez par faire une sauvegarde complète, testez le processus de préférence dans un environnement de staging et déployez ensuite en production. Pour les nouvelles installations, il est plus sûr et moins risqué d'utiliser dès le départ un préfixe différent.

Option de déplacer le fichier wp-config.php en dehors du répertoire racine

WordPress peut lire le fichier wp-config.php dans un niveau supérieur du répertoire racine dans certaines configurations de serveur. Par exemple, si les fichiers WordPress se trouvent dans public_html, le fichier wp-config.php peut être déplacé dans un répertoire supérieur en dehors de public_html. Cette méthode réduit le risque d'accès direct à travers le web.

Cependant, cette pratique peut ne pas fonctionner de la même manière dans tous les environnements d'hébergement. Dans les hébergements partagés, il pourrait ne pas être possible de déplacer le fichier en raison des permissions du répertoire, de la structure du panneau de contrôle ou des politiques de sécurité. En outre, ceux qui s’occupent de la maintenance doivent connaître l’emplacement du fichier ; sinon, le processus de débogage pourrait être prolongé.

Avant de mettre en œuvre cette méthode, vérifiez la structure des fichiers de votre fournisseur d'hébergement. Si vous utilisez un hébergement WordPress géré, demandez à l’équipe de support la structure de répertoire recommandée. Dans l’infrastructure de Hostragons, le contenu guide du panneau de contrôle d'hébergement peut être utile pour une gestion correcte des répertoires et des permissions.

Renforcez les permissions de fichiers et les droits d'écriture

La sécurité de wp-config.php est concernée non seulement par les constantes qu'il contient, mais aussi par les permissions au niveau du système d'exploitation du fichier. La recommandation générale est que le fichier wp-config.php ne soit pas accessible en écriture par tout le monde. Dans la plupart des environnements d'hébergement basés sur Linux, il peut être configuré avec des permissions plus restrictives comme 400, 440 ou 600. Quelle valeur fonctionnera dépend de l'utilisateur du serveur et du modèle d'exécution de PHP.

L'approche pratique est que le fichier doit être maintenu avec le minimum de permissions sans perturber le bon fonctionnement du site. Des réglages comme 777, qui octroient des permissions d'écriture à tous, ne doivent absolument pas être utilisés. 644 fonctionne par défaut dans certains environnements, mais dans des installations plus sensibles, 600 ou 440 peuvent être préférés. Après avoir effectué les changements, il est essentiel de tester le démarrage du site, l'accès au panneau et les mises à jour d'extensions.

Il est également important d'empêcher l'accès au fichier wp-config.php au niveau du serveur web. Dans les infrastructures d'hébergement modernes, les fichiers PHP ne sont pas exposés directement en tant que ressources ; cependant, sur des serveurs mal configurés, un risque peut se présenter. Par conséquent, une infrastructure d'hébergement fiable est aussi importante que les permissions de fichiers.

Gérez les mises à jour automatiques de manière axée sur la sécurité

WordPress reçoit régulièrement des mises à jour de sécurité pour le noyau, les extensions et les thèmes. Vous pouvez gérer le comportement des mises à jour automatiques dans une certaine mesure via wp-config.php. Pour des raisons de sécurité, il est généralement recommandé de permettre les mises à jour automatiques des petites versions. Car ces mises à jour sont souvent orientées vers la sécurité et la correction de bogues.

Par exemple, garder les mises à jour mineures ouvertes pour le noyau WordPress permet de réduire le délai de réponse face à des vulnérabilités connues. Cependant, les mises à jour majeures peuvent nécessiter des tests pour la compatibilité des thèmes et des extensions. Pour cette raison, dans les sites d'entreprise, la méthode la plus saine consiste à garder les correctifs de sécurité ouverts, et à tester les mises à jour majeures dans un environnement de staging avant de les mettre en production.

Vous pouvez utiliser trois règles fondamentales dans votre stratégie de mise à jour : d'abord la sauvegarde, ensuite les tests, enfin la mise en production. Cet ordre simple établit un bon équilibre entre sécurité et continuité.

Contrôlez la limite de mémoire PHP et la consommation des ressources

Dans le fichier wp-config.php, vous pouvez définir les valeurs WP_MEMORY_LIMIT et WP_MAX_MEMORY_LIMIT pour indiquer la quantité de mémoire que WordPress peut utiliser. Bien que ces réglages ne semblent pas être directement des paramètres de sécurité, ils sont importants dans les attaques par consommation de ressources, pour les extensions boguées et pour les opérations administratives intensives.

Par exemple, pour un petit blog, 128M est souvent suffisant, tandis que pour des sites WooCommerce ou multilingues, 256M peut être nécessaire. Cependant, augmenter la limite de mémoire de manière excessive peut entraîner une consommation de ressources plus élevée d'une extension boguée et dégrader les performances du serveur. La valeur correcte doit être évaluée en fonction du trafic du site, du nombre d'extensions et des ressources du forfait d'hébergement.

Si vous recevez souvent des erreurs de mémoire, ne vous contentez pas d'augmenter la limite, mais recherchez la source du problème. Des extensions lourdes, des requêtes non optimisées, une ancienne version de PHP ou un forfait d'hébergement insuffisant peuvent être à l'origine du problème. La performance et la sécurité doivent être considérées ensemble. À ce sujet, les contenus optimisation des performances WordPress et forfaits d'hébergement haute performance offrent des opportunités de liaison naturelles.

Gardez le répertoire temporaire et les comportements d'upload sécurisés

Dans certains environnements d'hébergement, WordPress conserve ses fichiers temporaires dans les répertoires système par défaut. C'est normal, mais des répertoires partagés mal configurés peuvent poser des risques de sécurité. Vous pouvez définir le répertoire des fichiers temporaires de WordPress via wp-config.php avec la commande WP_TEMP_DIR.

Si vous utilisez cette méthode, assurez-vous que le répertoire est inaccessibile au public, contrôlé en termes d'écriture, et uniquement accessible par l'utilisateur du site concerné. Les répertoires temporaires sont particulièrement actifs lors des processus de téléchargement de fichiers, de traitement des médias et de mise à jour des extensions. Un répertoire temporaire mal configuré peut entraîner des erreurs de téléchargement ou des risques de fuite de fichiers.

Sécurité des cookies et des sites multiples

Dans les projets utilisant WordPress multisite, que ce soit par sous-domaine ou par structure de sous-répertoire, les valeurs de cookie et d'URL du site deviennent plus sensibles. Une définition incorrecte de l'espace de cookie peut conduire à ce que les sessions soient valides sur des sous-domaines inattendus, ou à des boucles de connexion. Pour des raisons de sécurité, il convient de limiter l'étendue des cookies à la portée minimale nécessaire pour chaque architecture de site.

Par exemple, pour des structures telles que admin.example.com, shop.example.com et blog.example.com, il est essentiel de définir avec précision si les cookies seront valides pour tous les sous-domaines ou seulement pour un domaine spécifique. Une portée de cookie trop large augmente la chance qu'une vulnérabilité sur un sous-domaine affecte les sessions sur d'autres domaines.

Si vous utilisez un réseau multisite, examinez les constantes multisite dans le fichier wp-config.php, les réglages de mappage de domaine et la configuration SSL ensemble. Dans de tels projets, la planification du domaine et de SSL est également importante. Les liens gestion de plusieurs domaines et certificat SSL wildcard peuvent être pertinents dans ce contexte.

Liste de contrôle de sécurité applicable pour wp-config.php

Vous pouvez périodiquement vérifier la liste suivante sur votre site WordPress en production. Il est particulièrement recommandé de passer en revue cette liste après des installations de nouvelles extensions, des changements de thème, des migrations de serveur et des tentatives de connexion suspectes.

• Le fichier wp-config.php a-t-il une sauvegarde à jour conservée en sécurité ?
• Les clés de sécurité et les valeurs Salt sont-elles uniques et aléatoires ?
• DISALLOW_FILE_EDIT est-il actif ?
• WP_DEBUG est-il désactivé ou en mode journalisation sécurisé sur le site en production ?
• Le panneau d'administration fonctionne-t-il via HTTPS de manière obligatoire ?
• L'utilisateur de la base de données n'a pas de droits inutiles ?
• Le préfixe de table est-il différent de wp_ dans les nouvelles installations ?
• Les permissions de fichiers n'incluent-elles pas des valeurs dangereuses comme 777 ?
• Les mises à jour automatiques de sécurité sont-elles ouvertes de manière contrôlée ?
• Le compte d'hébergement dispose-t-il de SFTP, de sauvegarde et de SSL configurés correctement ?

Erreurs courantes et moyens d'évitement

La plus courante des erreurs constatées dans wp-config.php est d'ajouter des morceaux de code trouvés sur Internet sans comprendre leur utilité. Chaque site WordPress n'a pas la même architecture de serveur, de thème, d'extensions et de trafic. Par conséquent, un réglage qui fonctionne sans problème sur un site peut causer des problèmes de session ou des erreurs de mise à jour sur un autre site.

Une deuxième erreur fréquente est de laisser la sortie de débogage ouverte sur le site en production. Cela nuit à l'expérience utilisateur et entraîne des fuites d'informations techniques. La troisième erreur consiste à laisser une sauvegarde du fichier wp-config.php dans le répertoire racine du web sous les noms wp-config-backup.php, wp-config-old.php, etc. Ces fichiers peuvent être téléchargés en texte clair sur un serveur mal configuré. Les sauvegardes doivent être conservées dans une zone inaccessible au web.

La quatrième erreur consiste à définir les permissions de fichiers à 777 pour résoudre un problème et ne pas les ramener ensuite à leur état précédent. Bien qu'elle semble résoudre le problème à court terme, cela présente un risque considérable pour la sécurité. La cinquième erreur est d'activer FORCE_SSL_ADMIN sans avoir installé SSL ; cela peut entraîner des problèmes d'accès au panneau d'administration.

Comment installer une couche de sécurité professionnelle pour WordPress ?

Le durcissement de wp-config.php est une étape importante, mais à lui seul, il ne garantit pas une sécurité totale. Une approche de sécurité professionnelle doit être multicouche. Une isolation d'hébergement solide, une version de PHP à jour, un pare-feu pour application web, un SSL fiable, des sauvegardes régulières, un compte administrateur limité, une authentification à deux facteurs et le suivi des logs doivent être envisagés ensemble.

Par exemple, lorsqu'un attaquant essaie d'exploiter une vulnérabilité d’extension, la couche WAF peut bloquer la demande. Si un mot de passe utilisateur est compromis, l'authentification à deux facteurs s'active. Si une modification de fichier se produit, un retour rapide aux sauvegardes peut être effectué. wp-config.php est un point de configuration et de limitation critique dans cette chaîne.

Si vous créez votre site WordPress à partir de zéro, avancez dès le départ de manière sécurisée : planifiez un nom de domaine et SSL solides, sélectionnez un hébergement sécurisé, changez le préfixe de table par défaut, générez des clés Salt uniques, désactivez l'édition de fichiers du panneau et activez des sauvegardes régulières. Ces étapes fondamentales éviteront de nombreux problèmes à l’avenir.

Conclusion : Petits réglages, grand impact sur la sécurité

Les paramètres de sécurité avancés que vous pouvez appliquer avec le fichier wp-config.php de WordPress offrent des mesures pratiques et efficaces pour réduire la surface d'attaque de votre site. Renouveler les clés Salt, désactiver l'édition des fichiers, masquer la sortie de débogage, imposer SSL, limiter les droits à la base de données et renforcer les permissions des fichiers sont des étapes bénéfiques pour la plupart des sites WordPress.

Lorsque vous appliquez ces réglages, ne vous précipitez pas : faites des sauvegardes, modifiez un à un et testez chaque étape. Une configuration sécurisée, combinée à une infrastructure d'hébergement appropriée et à un entretien régulier, rendra votre site WordPress beaucoup plus résistant. Si vous envisagez une infrastructure plus sécurisée et durable, vous pouvez explorer les solutions de hébergement WordPress, certificats SSL et enregistrement de domaine de Hostragons pour déterminer votre point de départ idéal.

Questions fréquentes

Est-il sûr de modifier le fichier wp-config.php ?

Oui, cela est sûr lorsque vous avez d'abord effectué des sauvegardes appropriées et que vous appliquez les modifications de manière contrôlée. Cependant, une seule erreur de frappe peut affecter l'accès au site. C'est pourquoi assurez-vous d'abord de faire une sauvegarde du fichier et de la base de données, puis appliquez les réglages un à un à des fins de test.

Que se passe-t-il si je change les clés Salt dans le fichier wp-config.php ?

Toutes les sessions utilisateurs actives seront terminées et les utilisateurs devront se reconnecter. Cette opération ne supprime pas les contenus et ne corrompt pas la base de données. C'est une mesure rapide recommandée, surtout après une tentative de connexion suspecte, un risque pour le compte administrateur ou une violation de sécurité.

Faut-il laisser WP_DEBUG actif sur un site WordPress en production ?

Non. Si WP_DEBUG est laissé actif sur un site en production, les messages d'erreur peuvent divulguer des informations techniques aux visiteurs. L’approche sécurisée consiste à ne pas afficher les erreurs à l'écran et à n'utiliser une journalisation contrôlée qu'en cas de besoins ponctuels.

DISALLOW_FILE_EDIT empêche-t-il les mises à jour d’extensions et de thèmes ?

Non, DISALLOW_FILE_EDIT ne désactive que l'éditeur de fichiers du panneau. Les mises à jour d'extensions et de thèmes continuent normalement. Pour également désactiver les mises à jour, différentes configurations plus restrictives doivent être mises en place.

Quelle devrait être la permission du fichier wp-config.php ?

Bien que cela varie selon la configuration du serveur, l'objectif est de maintenir le fichier avec le minimum de permissions qui ne perturbe pas le fonctionnement. L'utilisation de 777 est absolument proscrite. Dans la plupart des environnements, 600, 440 ou 644 peuvent fonctionner ; il est important de tester le site et le panneau après le changement.