DEV Community: WP Admin Lab

Sécuriser une API REST WordPress : authentification, rate limiting et CORS en 2026

WP Admin Lab — Tue, 14 Jul 2026 18:11:47 +0000

Cet article a été publié à l'origine sur WP Admin Lab, le journal du web technique en français.

L'API REST WordPress expose vos données et vos fonctionnalités à quiconque connaît les bons endpoints. Dans un contexte où les attaques automatisées se multiplient, sécuriser cette couche n'est plus une option : c'est une nécessité absolue. Ce guide complet couvre l'authentification robuste, le rate limiting, la politique CORS et l'audit des endpoints pour protéger efficacement votre site en 2026.

Comprendre l'exposition par défaut de l'API REST WordPress

WordPress active son API REST sur la route /wp-json/ dès l'installation. Sans configuration supplémentaire, des dizaines d'endpoints sont accessibles publiquement : liste des utilisateurs (/wp/v2/users), des articles, des catégories, des médias… Ces informations semblent anodines mais elles constituent une surface d'attaque réelle pour les bots qui cherchent à énumérer les comptes, deviner des mots de passe ou tester des exploits ciblés.

Les logs de serveur révèlent souvent des centaines de requêtes quotidiennes sur /wp-json/wp/v2/users, réalisées par des scanners automatiques. Ces scans récupèrent les slugs des administrateurs, ce qui réduit considérablement le travail d'une attaque par force brute. La première étape de sécurisation consiste donc à identifier précisément quels endpoints sont exposés et à qui ils doivent réellement être accessibles.

L'inventaire de vos endpoints est une tâche incontournable. Utilisez WP-CLI avec la commande wp rest-api endpoint list ou un outil comme Postman pour cartographier l'ensemble des routes enregistrées. Notez pour chaque endpoint son niveau d'authentification requis (permission_callback), les méthodes HTTP acceptées (GET, POST, PUT, DELETE) et la nature des données retournées. Cet audit initial vous donnera une vision claire de ce qui doit être restreint en priorité.

Authentification par Application Passwords : simple et efficace

WordPress 5.6 a introduit les Application Passwords, une fonctionnalité native qui permet de générer des jetons d'authentification spécifiques à une application tierce. Chaque jeton est indépendant du mot de passe principal, peut être révoqué à tout moment et est associé à un utilisateur précis. Pour les intégrations headless, les scripts de migration ou les outils CI/CD qui appellent l'API REST, c'est la solution la plus simple à mettre en œuvre sans dépendance externe.

L'utilisation est straightforward : dans le profil d'un utilisateur WordPress, section « Mots de passe d'application », créez un jeton en lui donnant un nom explicite (ex. « Deploy script staging »). WordPress génère un jeton au format XXXXX XXXXX XXXXX XXXXX XXXXX XXXXX. Couplez-le au nom d'utilisateur dans un header HTTP Authorization de type Basic encodé en Base64. Toutes les requêtes authentifiées avec ce jeton agissent avec les permissions de l'utilisateur associé.

Pour les environnements de production, associez les Application Passwords à un compte utilisateur dédié avec des rôles restreints plutôt qu'à un administrateur. Créez par exemple un rôle « API Publisher » qui ne peut que créer et modifier des articles, sans accès aux plugins ni aux paramètres du site. En cas de compromission du jeton, l'impact reste limité. Activez également les notifications par e-mail lors de la création de nouveaux jetons pour détecter toute activité suspecte.

JWT : authentification sans état pour les applications front-end

Le JSON Web Token (JWT) est devenu un standard pour sécuriser les APIs dans les architectures découplées. Contrairement aux sessions WordPress classiques, le JWT est un jeton autonome signé cryptographiquement qui contient les informations d'identité de l'utilisateur. Le plugin JWT Authentication for WP-API est la solution la plus utilisée dans l'écosystème WordPress, mais il existe des alternatives comme WP REST API Authentication ou Simple JWT Login.

Une fois installé et configuré avec une clé secrète dans wp-config.php (JWT_AUTH_SECRET_KEY et JWT_AUTH_CORS_ENABLE), le plugin expose un endpoint /wp-json/jwt-auth/v1/token qui retourne un jeton après vérification des identifiants. Ce jeton, transmis dans le header Authorization: Bearer , est validé à chaque requête sans accès à la base de données, ce qui améliore les performances par rapport aux cookies de session.

La durée de vie du jeton est un paramètre critique : trop courte, elle dégrade l'expérience utilisateur (déconnexions fréquentes) ; trop longue, elle augmente la fenêtre d'exploitation en cas de fuite. Une expiration de 24 heures couplée à un mécanisme de refresh token constitue un bon équilibre. Implémentez également une liste de révocation côté serveur pour les jetons compromis et assurez-vous que votre clé secrète JWT fait au moins 256 bits d'entropie.

Rate limiting : protéger l'API contre les abus et le brute force

Sans rate limiting, votre API REST est vulnérable aux attaques par force brute sur les endpoints d'authentification, aux scans massifs de données et aux attaques DDoS applicatives. Le rate limiting consiste à limiter le nombre de requêtes autorisées par IP et par période de temps. Plusieurs approches coexistent : au niveau du serveur web (nginx, Apache), via un plugin WordPress dédié, ou en combinant les deux pour une protection multicouche.

Nginx offre les directives limit_req_zone et limit_req pour implémenter un rate limiting élaboré. Vous pouvez définir des zones distinctes pour l'endpoint d'authentification JWT (très restrictif : 5 requêtes par minute par IP) et pour les endpoints de lecture publics (plus permissif : 60 requêtes par minute). Apache propose le module mod_ratelimit et le module mod_evasive pour des protections similaires. Ces configurations s'appliquent avant même que PHP ne soit invoqué, réduisant la charge serveur.

Côté WordPress, le plugin WP REST API Rate Limit ou la bibliothèque wp-redis-rate-limit permettent d'implémenter des limites plus granulaires, basées sur l'utilisateur authentifié plutôt que sur l'IP seule. Cette approche est utile pour distinguer les bots des utilisateurs légitimes derrière un proxy ou un réseau d'entreprise. Complétez le rate limiting avec des réponses HTTP 429 (Too Many Requests) incluant un header Retry-After pour aider les clients légitimes à gérer les throttling proprement.

Configuration CORS sécurisée pour les requêtes cross-origin

CORS (Cross-Origin Resource Sharing) détermine quels domaines externes peuvent accéder à votre API REST depuis un navigateur. Une configuration trop permissive (Access-Control-Allow-Origin: *) expose votre API à des attaques CSRF et permet à n'importe quel site malveillant de lire des données depuis un navigateur où l'utilisateur est authentifié. En 2026, avec la multiplication des applications headless et des frontends découplés, maîtriser CORS est indispensable.

La bonne pratique est de définir une whitelist explicite des origines autorisées. Dans WordPress, utilisez le hook rest_pre_serve_request ou ajoutez les headers directement dans votre fichier .htaccess ou la configuration nginx. Listez uniquement vos domaines de production et de staging. Pour les requêtes preflight (OPTIONS), retournez les headers Access-Control-Allow-Methods et Access-Control-Allow-Headers appropriés. N'incluez Access-Control-Allow-Credentials: true que si vous utilisez des cookies d'authentification.

Pour les APIs qui servent plusieurs clients légitimes avec des origines différentes, implémentez une validation dynamique de l'origine : si l'origine de la requête figure dans votre liste blanche, répondez avec Access-Control-Allow-Origin fixé à cette origine spécifique (pas *). Combinez cela avec un token CSRF pour les opérations d'écriture. Testez votre configuration CORS avec l'outil CORS Tester de Chrome DevTools ou des services en ligne pour valider que vos restrictions fonctionnent comme attendu.

Désactiver les endpoints inutiles et restreindre l'accès

Chaque endpoint inutilisé est une surface d'attaque potentielle. Si votre site n'utilise pas l'API REST pour un usage externe, la bonne pratique est de désactiver complètement l'accès aux utilisateurs non authentifiés. Ajoutez un filtre sur rest_authentication_errors pour retourner une WP_Error si l'utilisateur n'est pas connecté. Cette mesure bloque l'accès aux données publiques via l'API tout en préservant les fonctionnalités internes de l'administration.

Pour une désactivation sélective, utilisez le filtre rest_endpoints pour retirer des routes spécifiques. Par exemple, l'endpoint /wp/v2/users expose les slugs et emails partiels de tous vos auteurs : si vous n'avez pas besoin de cet endpoint, supprimez-le. De même, les endpoints oEmbed, les routes de recherche globale et les endpoints des blocs Gutenberg peuvent être désactivés s'ils ne sont pas utilisés par votre application. Documentez chaque désactivation pour faciliter le débogage futur.

Les plugins de sécurité comme Wordfence, iThemes Security ou Shield Security offrent des interfaces graphiques pour gérer ces restrictions sans code. Ils permettent également de bloquer l'accès à l'API REST par rôle utilisateur, par pays (géo-blocage) ou par liste noire d'IP. Pour les sites à haute sécurité, combinez ces restrictions avec un pare-feu applicatif web (WAF) comme Cloudflare ou Sucuri qui filtre les requêtes malveillantes avant qu'elles n'atteignent votre serveur WordPress.

Audit et surveillance continue des accès à l'API

La sécurité n'est pas un état statique : les menaces évoluent et votre configuration doit être régulièrement auditée. Activez la journalisation des accès à l'API REST en enregistrant au minimum l'IP source, le endpoint appelé, le code de réponse HTTP, le temps de traitement et l'identifiant de l'utilisateur authentifié (s'il y a lieu). Ces logs sont essentiels pour détecter des anomalies comme une IP qui multiplie les requêtes 401 ou un endpoint inhabituel soudainement très sollicité.

Des outils comme WP Activity Log ou Stream enregistrent les actions de l'API REST dans la base de données WordPress et permettent de filtrer rapidement par type d'action, par utilisateur ou par plage de dates. Pour une surveillance plus robuste, centralisez vos logs dans un SIEM (Security Information and Event Management) comme Graylog, Elastic Stack ou un service cloud. Définissez des alertes automatiques pour les patterns suspects : plus de 100 requêtes 401 en 5 minutes depuis la même IP, accès à un endpoint normalement inactif, etc.

Planifiez un audit de sécurité de l'API REST au moins deux fois par an. Cet audit doit couvrir : vérification des Application Passwords actifs et révocation des jetons obsolètes, test des endpoints avec un outil comme OWASP ZAP ou Burp Suite, revue des règles de rate limiting, validation de la configuration CORS, et mise à jour des plugins d'authentification. Inscrivez-vous aux flux de vulnérabilités WordPress (WPScan DB, Patchstack) pour être alerté rapidement en cas de CVE affectant vos plugins de sécurité API.

Exemple de configuration nginx pour sécuriser /wp-json/

Voici une configuration nginx pragmatique qui combine rate limiting, restriction des méthodes HTTP et headers de sécurité pour l'API REST WordPress. Cette approche multicouche réduit drastiquement la surface d'attaque sans impacter les usages légitimes. Adaptez les valeurs des zones de rate limiting en fonction de votre trafic réel et de vos besoins en matière de performance.

Les headers de sécurité HTTP jouent également un rôle important : X-Content-Type-Options, X-Frame-Options et Strict-Transport-Security doivent être présents sur toutes les réponses de l'API. Le header Content-Security-Policy est moins pertinent pour une API JSON (il concerne surtout les ressources HTML), mais ajoutez au minimum default-src 'none' pour indiquer que cette route ne sert aucune ressource chargeable par un navigateur.

N'oubliez pas de tester votre configuration nginx avec nginx -t avant de recharger le service. Utilisez des outils comme curl avec des options verbose (-v) pour vérifier que les headers sont bien envoyés et que les limites de rate s'appliquent correctement. En production, activez le module ngx_http_limit_req_module dans votre build nginx et assurez-vous que les zones de mémoire partagée sont suffisamment dimensionnées pour absorber les pics de trafic sans erreur 503.

# /etc/nginx/sites-available/wpadminlab

limit_req_zone $binary_remote_addr zone=api_auth:10m rate=5r/m;

limit_req_zone $binary_remote_addr zone=api_read:10m rate=60r/m;

server {

    listen 443 ssl http2;

    server_name wpadminlab.com;

# Rate limit sur l'endpoint JWT
location = /wp-json/jwt-auth/v1/token {
    limit_req zone=api_auth burst=2 nodelay;
    limit_req_status 429;
    add_header Retry-After 60;
    try_files $uri $uri/ /index.php?$args;
}

# Rate limit sur l'API REST generale
location /wp-json/ {
    limit_req zone=api_read burst=20 nodelay;
    # Bloquer les methodes HTTP inutiles
    if ($request_method !~ ^(GET|POST|PUT|DELETE|PATCH|OPTIONS)$ ) {
        return 405;
    }
    # Headers de securite
    add_header X-Content-Type-Options "nosniff";
    add_header X-Frame-Options "DENY";
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
    try_files $uri $uri/ /index.php?$args;
}



}

A decouvrir aussi

Sur le meme sujet

Sauvegardes WordPress automatiques sans plugin payant : guide technique 2026

WP Admin Lab — Tue, 14 Jul 2026 18:11:46 +0000

Cet article a été publié à l'origine sur WP Admin Lab, le journal du web technique en français.

La sauvegarde WordPress est le filet de sécurité contre lequel tous les autres investissements en sécurité viennent s'appuyer. Un site compromis par un malware, une mise à jour qui casse la compatibilité, une erreur humaine de suppression accidentelle, sans sauvegarde récente, ces incidents deviennent des catastrophes. Les plugins de sauvegarde payants (UpdraftPlus Premium, BackupBuddy, Jetpack Backup) offrent du confort, mais une stratégie de sauvegarde robuste s'implémente entièrement avec des outils gratuits en 2026. Ce guide vous montre comment.

Les deux composantes à sauvegarder : fichiers et base de données

Une sauvegarde WordPress complète comprend deux éléments distincts. Les fichiers : le répertoire wp-content (thèmes, plugins, uploads, vos médias et personnalisations) et wp-config.php (configuration critique incluant les credentials de base de données). Les fichiers core WordPress (wp-admin/, wp-includes/) n'ont pas besoin d'être sauvegardés, ils sont identiques sur tous les sites de même version et peuvent être réinstallés en quelques secondes.

La base de données MySQL contient tout votre contenu : articles, pages, commentaires, réglages WordPress, données WooCommerce, utilisateurs, métadonnées. C'est la composante la plus critique, perdre la base de données signifie perdre tous vos articles publiés. En termes de fréquence, sauvegardez la base de données plus souvent que les fichiers : quotidiennement pour la base, hebdomadairement pour les fichiers (qui changent moins fréquemment).

La règle 3-2-1 est le standard de l'industrie : 3 copies de vos données, sur 2 supports différents, dont 1 hors site. Pour WordPress : 1 copie locale sur votre serveur (accessible rapidement), 1 copie sur un service cloud différent de votre hébergeur (Google Drive, Amazon S3, Backblaze B2), 1 copie archivée avec une rétention longue (30 jours minimum). Si votre hébergeur subit un incident, vos copies cloud restent intactes, c'est le cas qui justifie le hors-site.

WP-CLI : sauvegarder depuis la ligne de commande

WP-CLI (WordPress Command Line Interface) est l'outil le plus puissant pour les sauvegardes WordPress en ligne de commande. Disponible sur la plupart des hébergements cPanel, il permet d'exporter la base de données, de vérifier l'intégrité des fichiers et de restaurer un site entier sans passer par l'interface WordPress. Vérifiez sa disponibilité avec wp -info dans le terminal SSH de votre hébergeur.

Commande de sauvegarde de la base de données : wp db export backup-$(date +%Y%m%d).sql -add-drop-table -path=/home/wami5543/public_html. Cette commande crée un fichier SQL horodaté avec toutes les instructions DROP TABLE pour une restauration propre. Pour compresser : gzip backup-$(date +%Y%m%d).sql. Pour une sauvegarde complète des fichiers : tar -czf wp-files-$(date +%Y%m%d).tar.gz /home/wami5543/public_html/wp-content/. Ces deux commandes constituent le cœur de votre script de sauvegarde.

Script de sauvegarde complet à adapter à votre configuration :

« `bash

!/bin/bash

BKP_DIR= »/home/wami5543/backups »

DATE=$(date +%Y%m%d-%H%M)

mkdir -p $BKP_DIR

Base de données

wp db export $BKP_DIR/db-$DATE.sql -path=/home/wami5543/public_html

gzip $BKP_DIR/db-$DATE.sql

Fichiers wp-content

tar -czf $BKP_DIR/files-$DATE.tar.gz /home/wami5543/public_html/wp-content

Nettoyage des sauvegardes de plus de 30 jours

find $BKP_DIR -name '*.gz' -mtime +30 -delete

echo « Backup $DATE terminé »

« `

Automatiser avec les crons cPanel

Une sauvegarde manuelle que personne n'exécute régulièrement ne sert à rien. L'automatisation via les tâches cron cPanel garantit l'exécution sans intervention humaine. Dans votre panneau cPanel, cherchez 'Tâches cron' ou 'Cron Jobs'. Ajoutez une tâche avec l'expression cron 0 3 * * * (tous les jours à 3h du matin) et la commande : /usr/bin/wp db export /home/wami5543/backups/db-$(date +%Y%m%d).sql -path=/home/wami5543/public_html && gzip /home/wami5543/backups/db-$(date +%Y%m%d).sql.

Pour les fichiers wp-content, une fréquence hebdomadaire suffit : expression cron 0 4 * * 0 (dimanche à 4h) avec la commande tar correspondante. Si votre hébergeur limite le temps d'exécution des crons ou la taille des fichiers générés, découpez la sauvegarde des fichiers : uploads/ une semaine, themes/ + plugins/ l'autre semaine. Pour un site avec des Go de médias uploadés, la sauvegarde complète peut dépasser les timeouts.

Activez les notifications email des crons cPanel : si la tâche produit une sortie (y compris des erreurs), cPanel vous l'envoie par email. Pendant les deux premières semaines, vérifiez ces emails pour confirmer que vos sauvegardes s'exécutent sans erreur. Vérifiez également physiquement la présence des fichiers de sauvegarde dans votre répertoire backups/, un cron qui échoue silencieusement vous donnera une fausse impression de sécurité.

Rclone : synchroniser automatiquement vers le cloud

Stocker vos sauvegardes uniquement sur le même serveur que votre site ne protège pas contre une perte totale de l'hébergeur. Rclone est un outil open-source qui synchronise vos fichiers locaux vers plus de 40 destinations cloud : Google Drive, Amazon S3, Backblaze B2, OneDrive, Dropbox, et même un second serveur SFTP. Il s'installe sur la plupart des hébergements Linux avec curl https://rclone.org/install.sh | sudo bash (ou sans sudo selon vos permissions).

Configuration Rclone vers Google Drive : rclone config, choisissez 'n' (new remote), nommez-le 'gdrive', sélectionnez 'Google Drive', suivez le processus OAuth2. Une fois configuré, synchronisez votre dossier backups/ vers Google Drive avec : rclone copy /home/wami5543/backups gdrive:WordPress-Backups -min-age 1h. L'option -min-age 1h évite d'uploader des fichiers de sauvegarde en cours d'écriture. Ajoutez cette commande à votre cron, 30 minutes après le script de sauvegarde.

Pour Backblaze B2 (stockage objet à 0,006 $/Go/mois, le moins cher du marché), créez un bucket B2, générez des credentials API, et configurez Rclone de la même façon. Avec la facturation à l'usage, sauvegarder 10 Go de fichiers WordPress coûte moins de 0,07 $/mois. Configurez une règle de lifecycle sur votre bucket B2 pour supprimer automatiquement les fichiers de plus de 60 jours, sans cette règle, votre stockage cloud grossit indéfiniment.

UpdraftPlus gratuit : la solution plugin pour les non-techniciens

Si les scripts shell et les crons ne vous conviennent pas, UpdraftPlus en version gratuite reste la meilleure option plugin sans coût. Il supporte la sauvegarde automatique des fichiers et de la base de données vers Google Drive, Dropbox, Amazon S3, et email, sans limitation dans la version gratuite. Configurez une sauvegarde quotidienne de la base (légère) et hebdomadaire des fichiers (lourde).

La configuration critique dans UpdraftPlus : allez dans Settings > UpdraftPlus Backups > Settings. Fréquence des fichiers : une fois par semaine. Fréquence de la base de données : quotidienne. Nombre de sauvegardes à conserver : 4 (fichiers) et 7 (base de données). Stockage distant : Google Drive (connectez votre compte Google via OAuth). Activez les notifications email en cas d'échec. En 5 minutes, vous avez une stratégie de sauvegarde fonctionnelle et entièrement automatisée.

La limite principale d'UpdraftPlus gratuit : les sauvegardes incrémentielles (qui ne sauvegardent que les modifications depuis la dernière sauvegarde) sont réservées à la version premium. Pour les gros sites avec plusieurs Go de médias, une sauvegarde complète hebdomadaire peut être longue et solliciter les ressources serveur pendant l'exécution. Planifiez-la à 3h du matin pour minimiser l'impact sur vos visiteurs.

Tester la restauration : l'étape que 90 % des webmasters oublient

Une sauvegarde non testée est une sauvegarde de valeur inconnue. Il arrive que des fichiers de sauvegarde soient corrompus, incomplets ou incompatibles avec la version WordPress courante. La seule façon de s'en assurer est de tester la restauration au moins une fois par trimestre. Créez un sous-domaine de test (staging.votre-site.com) et restaurez votre dernière sauvegarde dessus via WP-CLI ou UpdraftPlus.

Le processus de restauration manuelle avec WP-CLI : créez une base de données MySQL vide dans cPanel, importez le dump SQL compressé (gzip -d backup.sql.gz && wp db import backup.sql -path=/staging/), décompressez les fichiers wp-content dans le répertoire staging, mettez à jour wp-config.php avec les nouveaux credentials de base de données, et lancez wp search-replace 'votre-site.com' 'staging.votre-site.com' -path=/staging/ pour adapter les URLs. Si votre site s'affiche correctement sur le staging, votre sauvegarde est valide.

Documentez votre procédure de restauration et sa durée. Savoir qu'une restauration prend 20 minutes (et non 3 heures) change votre calcul de risque. Partagez cette documentation avec toute personne ayant accès au site, en cas d'incident, la panique rend les gens moins efficaces, mais une procédure documentée transforme une crise en procédure. La sauvegarde sans plan de restauration n'est que la moitié du travail.

Sauvegardes staging : protéger vos environnements de développement

Si vous utilisez un environnement staging pour tester les mises à jour avant de les déployer en production (ce que vous devriez faire), cet environnement doit également être sauvegardé, mais avec une stratégie allégée. Une sauvegarde hebdomadaire manuelle du staging suffit généralement, car c'est un environnement qu'on peut reconstruire depuis la production. L'essentiel est de ne jamais perdre de travail de développement ou de personnalisation qui n'a pas encore été déployé.

Pour les agences gérant plusieurs sites clients, standardisez votre procédure de sauvegarde avec un script partagé que vous adaptez par client. Chaque site a son propre répertoire de backups, sa propre destination cloud (un dossier par client dans un bucket S3 partagé), et ses propres fréquences selon la criticité. Documentez cette procédure dans votre CRM ou espace de travail d'équipe : quand un client appelle pour une restauration, n'importe quel membre de l'équipe doit être capable d'exécuter la procédure sans dépendre du développeur principal.

La facturation des sauvegardes : pour les clients en contrat de maintenance, incluez explicitement les sauvegardes dans le périmètre (fréquence, durée de rétention, destination) et faites-les signer. En cas d'incident, vous aurez une trace contractuelle des engagements pris. Pour les clients sans contrat de maintenance, proposez un forfait 'Sauvegarde + Monitoring' séparé, c'est une valeur ajoutée perçue forte et un revenu récurrent prévisible pour votre activité.

Monitoring de l'intégrité des fichiers : détecter les modifications suspectes

Les sauvegardes protègent contre la perte de données. Le monitoring d'intégrité des fichiers détecte les modifications non autorisées, signature d'une compromission malware. Wordfence (version gratuite) scanne régulièrement les fichiers core WordPress et les compare à la version officielle de référence : toute différence est signalée. Pour les fichiers de thème et de plugin, il compare les checksums avec les versions du répertoire WordPress.org.

Configurez des alertes email sur toute modification dans wp-config.php, .htaccess, et les fichiers de thème actif. Ces fichiers sont rarement modifiés légitimement par des automatismes, toute modification inattendue est un signal d'alerte. WP Activity Log (plugin gratuit) loggue chaque modification de fichier avec l'utilisateur, l'IP et l'heure. Croisez ces logs avec vos sauvegardes pour identifier exactement quand et comment une compromission a eu lieu.

Combinez sauvegardes + monitoring d'intégrité + WAF pour une défense en profondeur. Le WAF bloque les tentatives d'exploitation ; le monitoring détecte si une modification a quand même eu lieu malgré le WAF (zero-day, voie d'attaque non filtrée) ; la sauvegarde permet de restaurer proprement. Sans les trois, vous êtes soit aveugle, soit incapable de vous remettre d'un incident. Avec les trois et un budget quasi nul (outils gratuits), vous avez un niveau de protection professionnel.

DEV Community: WP Admin Lab

Sécuriser une API REST WordPress : authentification, rate limiting et CORS en 2026

Comprendre l'exposition par défaut de l'API REST WordPress

Authentification par Application Passwords : simple et efficace

JWT : authentification sans état pour les applications front-end

Rate limiting : protéger l'API contre les abus et le brute force

Configuration CORS sécurisée pour les requêtes cross-origin

Désactiver les endpoints inutiles et restreindre l'accès

Audit et surveillance continue des accès à l'API

Exemple de configuration nginx pour sécuriser /wp-json/

Sur le même sujet

A decouvrir aussi

Sur le meme sujet

Sauvegardes WordPress automatiques sans plugin payant : guide technique 2026

Les deux composantes à sauvegarder : fichiers et base de données

WP-CLI : sauvegarder depuis la ligne de commande

!/bin/bash

Base de données

Fichiers wp-content

Nettoyage des sauvegardes de plus de 30 jours

Automatiser avec les crons cPanel

Rclone : synchroniser automatiquement vers le cloud

UpdraftPlus gratuit : la solution plugin pour les non-techniciens

Tester la restauration : l'étape que 90 % des webmasters oublient

Sauvegardes staging : protéger vos environnements de développement

Monitoring de l'intégrité des fichiers : détecter les modifications suspectes

Sur le même sujet

Sur le meme sujet