Come visto nei capitoli precedenti e nella guida a WordPress, il CMS fornisce numerose costanti che l'amministratore del sito può definire nel file wp-config.php. Ogni costante abilita una specifica funzionalità, e molte di queste funzionalità accrescono la sicurezza dell'istallazione.
Tra le prime misure di sicurezza, è sempre opportuno impostare le otto chiavi di autenticazione e "salatura" elencate nello stesso file wp-config.php, subito al di sotto dei dati di connessione al database.
Queste chiavi sono costituite da una qualunque stringa di testo. WordPress offre anche un servizio di generazione automatica delle chiavi che ne garantisce una maggiore sicurezza.
Una prima buona pratica è quella di disabilitare l'editor di file del pannello di amministrazione:
define('DISALLOW_FILE_EDIT', true);Se impostata su true questa costante disabilita l'editor che consente di modificare i file che compongono temi e plugin. Se lasciato attivo l'editor potrebbe offrire una via di accesso all'istallazione e costituire una pericolosa vulnerabilità.
Altra misura di sicurezza è l'utilizzo dei protocolli crittografici. Se nel pacchetto acquistato dall'host rientra anche il servizio SSL nel file wp-config.php possono essere definite le seguenti costanti:
define('FORCE_SSL_LOGIN', true);
define('FORCE_SSL_ADMIN', true);Queste costanti forzano rispettivamente l'utilizzo di SSL al login dell'utente e all'accesso al pannello di amministrazione.
Nello stesso modo, se l'host fornisce servizi di FTPS o di SSH FTP, si può forzare WordPress ad utilizzare i due protocolli nel caricamento dei file sul server:
define('FTP_SSL', true);
define('FS_METHOD', 'ssh2');Quando il sito è in produzione, è sempre opportuno evitare di fornire le informazioni relative ad eventuali errori di codice e compatibilità visibili nella modalità debug. In produzione, l'amministratore dovrà disabilitare la modalità debug:
define('WP_DEBUG', false);Se dovesse, però, essere necessario mantenere attiva la modalità debug, WordPress permette di memorizzare i messaggi di errore e di notifica nel file debug.log, presente nella cartella /wp-content, nascondendoli tuttavia alla vista nel front-end del sito. La soluzione è offerta dalle seguenti costanti:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Nel prossimo capitolo saranno analizzate soluzioni tecniche più avanzate, in cui si farà ricorso al file .htaccess dei sistemi Apache.