Désactiver ou verrouiller la REST API et le XML RPC de WordPress
Si l’API Rest vous empêche de dormir sur vos deux oreilles, vous pouvez la verrouiller afin que seuls les utilisateurs connectés ou les administrateurs puissent y avoir accès. Aujourd’hui je vous déconseille de vouloir la désactiver complètement et je vous explique pourquoi.
Mise à jour février 2018 : Dans une ancienne version de cet article je vous expliquais comment désactiver complètement l’API (à cause de failles détectées dans la version 4.7). Mais vous n’avez plus d’inquiétudes à avoir, aujourd’hui l’API Rest est stable et sécurisée.
Avant de continuer, sachez que l’API Rest est de plus en plus utilisée par les extensions et le coeur de WordPress. Il devient donc dangereux de vouloir la désactiver. A l’arrivée de Gutenberg, le nouvel éditeur de WordPress, en mai 2018 vous risquez de tout casser.
Empecher les utilisateurs non connectés d’accéder à l’api :
Je vous conseille donc de la laisser activée, mais de la verrouiller pour que seuls les utilisateurs connectés ou les admin y aient accès, voici le code à appliquer dans functions.php
[pastacode lang=”php” manual=”%3C%3Fphp%20%0Aadd_filter(‘rest_authentication_errors’%2C%20’secure_api’)%3B%0A%0Apublic%20function%20secure_api(%20%24result%20)%20%7B%0A%20%20%20%20if%20(%20!%20empty(%20%24result%20)%20)%20%7B%0A%20%20%20%20%20%20%20%20return%20%24result%3B%0A%20%20%20%20%7D%0A%20%20%20%20if%20(%20!%20is_user_logged_in()%20)%20%7B%0A%20%20%20%20%20%20%20%20return%20new%20WP_Error(%20’rest_not_logged_in’%2C%20’You%20are%20not%20currently%20logged%20in.’%2C%20array(%20’status’%20%3D%3E%20401%20)%20)%3B%0A%20%20%20%20%7D%0A%20%20%20%20return%20%24result%3B%0A%20%20%7D” message=”” highlight=”” provider=”manual”/]
Et si jamais vous voulez vraiment limiter l’accès à l’API au minimum à vos rédacteurs, il suffit d’utiliser la fonction current_user_can(‘edit_posts’) à la place de is_user_logged_in().
Cette méthode est “officielle” puisqu’elle provient de la documentation WordPress: https://developer.wordpress.org/rest-api/using-the-rest-api/frequently-asked-questions/
DESACTIVER Le XML RPC
Le XML RPC est un ancien protocole WordPress très peu utilisé et qui peut facilement présenter des failles de sécurité. Pour le désactiver il suffit d’ajouter ces lignes, toujours dans functions.php :
[pastacode lang=”php” manual=”%3C%3Fphp%20%0A%0A%09add_filter(%20’xmlrpc_enabled’%2C%20’__return_false’%20)%3B%0A%09remove_action(%20’wp_head’%2C%20’rsd_link’%20)%3B” message=”” highlight=”” provider=”manual”/]
17 Commentaires
Donc si j’ai tout compris il vaut mieux désactiver en attendant une future mise à jour de WordPress qui réglera le problème ?
Le problème est résolu en 4.7.2, je propose juste ces codes pour éviter de futurs potentiels problèmes en cas de nouvelle faille à l’avenir
Vu qu’ils sont en train de se servir de plus en plus de l’API dans l’admin de WordPress, la désactivé complètement ne va t’il pas poser des problèmes ?
Oui faudra suivre en effet l’évolution de l’intégration de l’api dans l’admin WordPress. D’ici là j’ai un autre code qui garde l’API ouverte mais qui oblige l’utilisateur a être connecté pour y accéder (tu retrouves ce code dans le plugin https://wordpress.org/plugins/disable-json-api/)
Il existe un plugin pour ceux qui veulent seulement désactiver XML-RPC et qui ne sont pas à l’aise de modifier leur fichier functions.php
https://fr-ca.wordpress.org/plugins/disable-xml-rpc/
Personnellement, ayant détecté une attaque en cours sur le fichier xmlrpc.php, qui est la porte de l’api du même nom (que je n’utilise pas), j’ai tout simplement supprimé le fichier (en attendant la prochaine mise à jour).
simple, sans risque et sans ajouter du code (plugin ou autre).
ATTENTION, solution temporaire : la mise à jour suivante le réinstallera
Il vaut mieux utiliser le filter indiqué dans l’article que de supprimer des fichiers du coeur de WP ;)
Merci pour ce code, je l’ai insérer à l’aide d’un MU Plugin, cela ne posera pas de problème futur ?
C’est d’autant plus facile pour le déployer sur d’autres sites.
ca ne devrait pas poser de souci en effet, mais restons tout de même vigilants !
Un grand merci pour cet article déjà. Je viens aussi de parcourir ton article sur l’API REST, c’est très instructif :)
Dans ta “solution 2”, tu proposes une solution pour désactiver l’API REST et une autre pour désactiver le XML RPC.
Ensuite, tu nous parles d’une solution alternative qui laisse l’API ouverte mais réservée seulement aux utilisateurs connectés.
Si je veux opter pour la solution alternative, au niveau du code, est-ce qu’au final je dois avoir ceci :
remove_action( ‘init’, ‘rest_api_init’ );
remove_action( ‘parse_request’, ‘rest_api_loaded’ );
(…)
add_filter( ‘rest_enabled’, ‘__return_false’ );
add_filter( ‘rest_jsonp_enabled’, ‘__return_false’ );
function secure_API( $access ) {
(…)
}
add_filter( ‘rest_authentication_errors’, ‘secure_API’ );
OU uniquement ceci :
function secure_API( $access ) {
(…)
}
add_filter( ‘rest_authentication_errors’, ‘secure_API’ );
Merci d’avance pour ta réponse :)
Salut !
Normalement juste la dernière partie !
Bonjour, quand je cherche a me connecter sur mon site voici la page qui s’ouvre avec le texte suivant:
Parse error: syntax error, unexpected T_FUNCTION in /home/winedivik/www/wp-content/plugins/disable-json-api/classes/disable-rest-api.php on line 86
Quand je fais des recherches sur cette ligne je tombe sur votre site, voici pourquoi je met ce commentaire.
si quelqu’un pouvait m’expliquer.?
En plus il faut que je renouvelle mon hébergement et je ne sais pas si ça vaut le coup.
Merci/ Cdt.
Je te conseille de désactiver l’extension disable json api, elle ne doit plus être à jour. Laisse l’API activée pour le moment, elle va devenir de plus en plus nécessaire pour WordPress donc il est déconseillé de continuer à vouloir la couper.
Bonjour,
Que penses-tu de l’extension Disable REST API ?
Merci.
Elle fait le boulot en effet aussi ! Aujourd’hui cependant je pense qu’il ne faut plus bloquer l’API : de plus en plus de choses en ont besoin pour tourner dans WordPress, cela risque de créer des incompatibilités à l’avenir
Merci pour ta réponse.
J’ai bien compris l’intérêt de ne pas la couper… mais est-ce que le code que tu indiques (copié ci-dessous) pour la laisser ouverte mais seulement aux connecté·e·s est suffisant en matière de sécurité ?
rest_authorization_required_code() ) );
}
return $access;
}
add_filter( ‘rest_authentication_errors’, ‘secure_API’ );
Merci d’avance pour ta réponse.
La version publique de l’API faut la voir comme un flux RSS : ça n’affiche que les contenus également sur le site donc aucun souci de sécurité. Il ne faut vraiment pas d’ne faire de ce côté là .