# Monter en compétence un développeur junior sur les réflexes de sécurité WordPress au quotidien > La sécurité s'apprend rarement en une formation unique. Voici une progression concrète, testée sur l'encadrement d'une recrue, des bases jusqu'aux capacités personnalisées. - Auteur : WordPress Développement - Publié le : 2023-04-21 - Mis à jour le : 2023-04-21 - Catégorie : Sécurité - URL : https://www.wpmoderne.fr/securite/monter-competence-junior-securite-wordpress/ ## L’essentiel - Commencer par l'échappement systématique des sorties - Passer aux capacités et rôles avant les sujets avancés - Faire relire du vrai code plutôt que des exercices artificiels D'après la documentation officielle sur les capacités WordPress, disponible sur developer.wordpress.org, le système de rôles et permissions distingue une trentaine de capacités par défaut, un nombre suffisant pour dérouter un développeur qui découvre l'écosystème. Encadrer une recrue junior sur les réflexes de sécurité ne consiste pas à lui faire lire cette liste en une session, mais à construire une progression où chaque notion s'appuie sur du code réellement écrit, relu, et corrigé. Sur l'encadrement d'un développeur junior arrivé sur un projet de refonte pour une PME du secteur du bâtiment, la progression suivante a été testée sur six semaines, en alternant code réel sur le projet et revues ciblées. Elle n'a rien d'universel, mais elle a permis d'éviter l'écueil classique d'une formation théorique déconnectée du travail quotidien. ## Semaine 1-2 : l'échappement systématique des sorties Le premier réflexe à ancrer, avant tout autre sujet, concerne l'échappement des données à l'affichage : `esc_html()`, `esc_attr()`, `esc_url()`. La méthode qui a fonctionné consistait à faire relire au junior du code déjà existant sur le projet, en lui demandant d'identifier chaque endroit où une donnée dynamique s'affiche sans échappement, plutôt que de partir d'exercices artificiels déconnectés du code réel. Un exercice concret : reprendre un template de fiche produit et faire lister, ligne par ligne, quelle fonction d'échappement s'applique à quel contexte (URL, attribut HTML, texte brut). Cette étape seule a permis de corriger trois oublis réels sur le projet, ce qui a immédiatement donné du sens à l'exercice. ## Semaine 3 : capacités et vérifications de permission Une fois l'échappement acquis comme réflexe, la notion de `current_user_can()` et de vérification systématique avant toute action sensible (suppression, modification de contenu d'un autre auteur, accès à un réglage) devient la deuxième brique. Le junior a travaillé sur l'ajout d'une fonctionnalité d'export de données clients, avec pour consigne explicite de justifier, pour chaque route ajoutée, la capacité vérifiée et pourquoi. > L'essentiel à retenir : Commencer par l'échappement systématique des sorties ; Passer aux capacités et rôles avant les sujets avancés ; Faire relire du vrai code plutôt que des exercices artificiels Cette étape a aussi permis d'aborder un piège fréquent chez les débutants : vérifier `is_admin()` en pensant contrôler un accès, alors que cette fonction indique seulement si la requête a lieu côté administration, sans rien dire des droits de l'utilisateur connecté. ## Semaine 4 : nonces et CSRF Le sujet des nonces arrive naturellement après les capacités, puisque les deux se combinent systématiquement sur une action sensible. La consigne donnée : pour chaque formulaire d'administration ajouté au projet, vérifier la présence de `wp_nonce_field()` à la génération et de `wp_verify_nonce()` au traitement, et expliquer ce qui se passerait concrètement si l'un des deux manquait. - Formulaire de suppression d'un enregistrement : nonce + capacité vérifiés ensemble - Action déclenchée par un lien admin : nonce ajouté à l'URL via `wp_nonce_url()` - Requête AJAX authentifiée : nonce transmis via `wp_localize_script()` puis vérifié côté serveur ## Semaine 5 : requêtes SQL et wpdb::prepare Le sujet des injections SQL arrive volontairement après les nonces plutôt qu'en premier : sur ce projet particulier, aucune requête SQL directe n'était nécessaire avant cette étape, l'essentiel des accès aux données passant par `WP_Query`. Introduire `$wpdb->prepare()` au moment où une requête personnalisée devient réellement nécessaire — ici, pour une recherche multi-critères sur les commandes — donne plus de sens que de l'enseigner de façon abstraite. ### Un exercice de relecture ciblé ``` // Version à corriger soumise au junior $resultats = $wpdb->get_results( "SELECT * FROM {$wpdb->prefix}commandes WHERE statut = '$statut'" ); ``` La correction attendue, avec `$wpdb->prepare()` et des marqueurs, a servi de base à une discussion sur pourquoi la concaténation directe reste dangereuse même quand la valeur semble provenir d'une source « interne » comme un menu déroulant. ## Semaine 6 : capacités personnalisées et rôles sur mesure La dernière étape, plus avancée, aborde la création d'une capacité personnalisée via `add_cap()` pour un rôle métier spécifique — dans ce cas, un rôle « gestionnaire de devis » distinct des rôles par défaut. Cette étape suppose les précédentes acquises : elle combine capacités, vérifications de permission et compréhension du modèle de rôles, et n'a de sens que si le junior maîtrise déjà les bases. > Un développeur junior qui comprend pourquoi une vérification est nécessaire la reproduit sans qu'on le lui rappelle ; un développeur qui l'applique par consigne l'oublie à la première fonctionnalité pressée. ## Pour aller plus loin Cette progression reste indicative et dépend fortement du projet sur lequel la recrue est encadrée : un projet e-commerce mettra l'accent plus tôt sur les webhooks et les paiements, un projet éditorial insistera davantage sur le filtrage du contenu riche. L'invariant qui a fonctionné sur plusieurs encadrements reste le même : faire relire et corriger du code réel, projet par projet, plutôt que dérouler un programme théorique identique quel que soit le contexte.