<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>.htaccess - Matteo Cisilino</title>
	<atom:link href="https://www.cisilino.com/fr/tag/htaccess-fr/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.cisilino.com/fr/</link>
	<description>Guide su WordPress, server e sicurezza</description>
	<lastBuildDate>Fri, 30 Oct 2026 16:06:57 +0000</lastBuildDate>
	<language>fr-FR</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.1.4</generator>
	<item>
		<title>Durcissement / IDS : les règles pour .htaccess</title>
		<link>https://www.cisilino.com/fr/2026/10/30/durcissement-ids-regles-htaccess/</link>
					<comments>https://www.cisilino.com/fr/2026/10/30/durcissement-ids-regles-htaccess/#respond</comments>
		
		<dc:creator><![CDATA[matteocisilino]]></dc:creator>
		<pubDate>Fri, 30 Oct 2026 16:05:39 +0000</pubDate>
				<category><![CDATA[Manuel CSDN]]></category>
		<category><![CDATA[.htaccess]]></category>
		<category><![CDATA[Cisilino Site Defense Network]]></category>
		<category><![CDATA[manuel CSDN]]></category>
		<category><![CDATA[XML-RPC]]></category>
		<guid isPermaLink="false">https://www.cisilino.com/?p=1065</guid>

					<description><![CDATA[<p>L'onglet Durcissement / IDS du plugin CSDN, règle par règle : ce qu'il bloque, ce qu'il peut casser et pourquoi les chemins personnalisés doivent être écrits avec soin.</p>
<p>The post <a href="https://www.cisilino.com/fr/2026/10/30/durcissement-ids-regles-htaccess/">Durcissement / IDS : les règles pour .htaccess</a> first appeared on <a href="https://www.cisilino.com/fr/">Matteo Cisilino</a>.</p>]]></description>
										<content:encoded><![CDATA[<p>Le <strong>durcissement WordPress</strong> du plugin CSDN tient tout entier dans un onglet : « Durcissement / IDS ». Ce sont cinq interrupteurs et un champ de texte. Ils servent à fermer des portes que presque aucun site n&rsquo;utilise vraiment. Ils sont tous désactivés, et tu les actives un à la fois.</p>
<figure class="wp-block-image size-large"><img fetchpriority="high" decoding="async" src="https://www.cisilino.com/wp-content/uploads/2026/10/manuale-csdn-hardening-ids.webp" alt="Schéma de WordPress avec l'onglet Durcissement / IDS du plugin CSDN : durcissement wordpress" width="1200" height="630"/></figure>
<h2>Où trouver le durcissement WordPress</h2>
<p>Ouvre <strong>Réglages &gt; Cisilino Site Defense Network</strong> (point 1 de l&rsquo;image). Puis clique sur l&rsquo;onglet <strong>Durcissement / IDS</strong> (point 2). Dans l&rsquo;onglet tu trouves trois sections, dans cet ordre :</p>
<ul>
<li>point 3 : sous le titre « Durcissement / contrôle d&rsquo;accès (IDS) », la ligne « Règles .htaccess ».</li>
<li>point 4 : « WordPress ».</li>
<li>point 5 : « Chemins personnalisés à bloquer ».</li>
</ul>
<p>En haut, l&rsquo;onglet dit : « Règles facultatives appliquées au niveau du serveur (.htaccess) ou de WordPress. Toutes désactivées par défaut : active-les seulement si tu sais qu&rsquo;elles n&rsquo;entrent pas en conflit avec les thèmes/plugins du site. » En bas, il y a un seul bouton : « Enregistrer les règles de durcissement ».</p>
<h2>À quoi ça sert</h2>
<p>Les règles réduisent la surface d&rsquo;attaque. Trois interrupteurs écrivent dans le fichier <code>.htaccess</code>, comme le champ des chemins personnalisés. Deux interrupteurs sont des filtres de WordPress. Ce n&rsquo;est pas un pare-feu et cela n&rsquo;analyse pas les requêtes : ici « IDS » veut dire des règles d&rsquo;accès aux fichiers et aux dossiers.</p>
<h2>Les règles .htaccess (point 3)</h2>
<h3>Bloquer l&rsquo;exécution PHP dans wp-content/uploads</h3>
<p>Le libellé complet est « Bloquer l&rsquo;exécution PHP dans wp-content/uploads (protection contre les shells téléversés comme « image ») ». Le plugin répond 403 à toute requête d&rsquo;un fichier avec extension <code>php</code>, <code>php3</code>, <code>php4</code>, <code>php5</code>, <code>php7</code>, <code>php8</code>, <code>php9</code>, <code>phtml</code>, <code>phps</code>, <code>phar</code> ou <code>pht</code> dont l&rsquo;adresse contient <code>/wp-content/uploads/</code>. Les majuscules n&rsquo;ont pas d&rsquo;importance.</p>
<p>Cela fonctionne seulement avec Apache 2.4 (il faut le module mod_authz_core : sans lui, la règle ne fait rien et ne le signale pas). Sur nginx, le fichier <code>.htaccess</code> est ignoré et aucune règle de cet onglet n&rsquo;a d&rsquo;effet, filtres de WordPress mis à part. Cela couvre le dossier uploads standard, pas un dossier personnalisé. Cela peut casser des plugins qui servent vraiment des fichiers PHP depuis ce dossier. Pour savoir si ça marche sur ton site, utilise le test du chapitre <a href="https://www.cisilino.com/fr/?p=980">Onglet Test</a>.</p>
<h3>Désactiver la liste des fichiers dans les dossiers sans index</h3>
<p>Cela écrit une seule ligne : <code>Options -Indexes</code>. En ouvrant un dossier sans page index, tu verras une erreur 403 au lieu de la liste des fichiers. Si tu utilises un dossier comme liste publique de téléchargements, cette liste disparaît.</p>
<h3>Bloquer l&rsquo;accès direct à wp-config.php, .htaccess, readme.html, debug.log</h3>
<p>Le plugin écrit une règle pour chaque nom et répond 403. Le contrôle porte sur le nom du fichier, pas sur le chemin. Cela vaut donc pour chaque fichier portant ce nom, dans n&rsquo;importe quel dossier du site, même à l&rsquo;intérieur d&rsquo;autres plugins. Un plugin qui publie son propre <code>readme.html</code> ou <code>debug.log</code> sera bloqué.</p>
<h2>Les règles de WordPress (point 4)</h2>
<p>Ces deux règles du durcissement WordPress sont des filtres PHP. Elles ne touchent pas à <code>.htaccess</code>.</p>
<h3>Désactiver XML-RPC</h3>
<p>Le libellé est « Désactiver XML-RPC (bruteforce/pingback, presque jamais nécessaire sur les sites modernes) ». Le fichier <code>xmlrpc.php</code> reste à sa place, mais WordPress refuse les méthodes XML-RPC qui nécessitent une connexion. <strong>Attention :</strong> cela arrête l&rsquo;application mobile de WordPress, une partie des fonctions de Jetpack et la publication depuis des clients externes. La méthode <code>pingback.ping</code> ne nécessite pas de connexion et le filtre ne l&rsquo;arrête pas : ne compte pas sur cette règle pour fermer les pingbacks. Les trackbacks n&rsquo;utilisent pas XML-RPC et ne sont pas concernés. La connexion du plugin au panneau n&rsquo;utilise pas XML-RPC, elle n&rsquo;est donc pas touchée.</p>
<h3>Bloquer l&rsquo;énumération des utilisateurs via ?author=N</h3>
<p>Si la requête contient le paramètre <code>author</code> avec une valeur (différente de vide et de <code>0</code>), le site public affiche « Introuvable. » avec une réponse 404. <strong>Attention :</strong> cette règle ne protège pas l&rsquo;API REST. La liste des utilisateurs dans <code>/wp-json/wp/v2/users</code> reste accessible. Certains thèmes et plugins utilisent <code>?author=</code> pour filtrer les archives, et seront bloqués.</p>
<h2>Chemins personnalisés à bloquer (point 5)</h2>
<p>Le champ de texte est pour qui veut fermer un dossier précis, par exemple <code>/wp-content/uploads/ancienne-sauvegarde/</code>. Écris un chemin par ligne. Les lignes vides sont ignorées.</p>
<p>Chaque ligne est un <strong>texte littéral</strong>. Les majuscules comptent et la partie après le <code>?</code> de l&rsquo;adresse n&rsquo;est pas comparée. L&rsquo;aide sous le champ parle de « motifs », mais ici il n&rsquo;en existe pas. Il n&rsquo;existe pas de jokers : <code>*</code>, <code>^</code> et <code>$</code> valent comme de simples caractères. Le plugin bloque avec 403 chaque adresse qui <strong>contient</strong> cette chaîne, à n&rsquo;importe quel endroit. C&rsquo;est pourquoi le chemin <code>/wp-content/uploads/ancienne-sauvegarde/</code> bloque aussi <code>/blog/wp-content/uploads/ancienne-sauvegarde/x</code>.</p>
<p>Ce champ n&rsquo;a pas d&rsquo;interrupteur. La règle est active dès que le champ n&rsquo;est pas vide et que tu enregistres.</p>
<p><strong>Attention :</strong> si tu écris <code>/</code> ou <code>wp</code>, tu bloques tout le site, y compris la zone d&rsquo;administration. Pour revenir en arrière, tu devrais corriger <code>.htaccess</code> par FTP. Même une chaîne comme <code>/uploads/</code> bloque toutes les images. Évite le caractère <code>%</code> dans les chemins.</p>
<h2>Valeurs par défaut</h2>
<p>Cinq interrupteurs désactivés et un champ vide. Les réglages sont dans l&rsquo;option <code>csdn_hardening</code>.</p>
<h2>Comment procéder</h2>
<p>Vas-y calmement : le durcissement WordPress se fait une règle à la fois.</p>
<ol>
<li>Fais une copie de <code>.htaccess</code> avant de commencer.</li>
<li>Coche une seule règle.</li>
<li>Clique sur « Enregistrer les règles de durcissement ».</li>
<li>Vérifie que le site s&rsquo;ouvre et que l&rsquo;administration fonctionne.</li>
<li>Passe à la règle suivante.</li>
</ol>
<p>Après l&rsquo;enregistrement, tu es ramené à l&rsquo;onglet Général, pas à celui où tu as enregistré. En haut, tu trouves l&rsquo;avertissement. En cas de succès, il dit « Règles de durcissement enregistrées et appliquées. ». En cas d&rsquo;erreur, il dit « Réglages enregistrés, mais l&rsquo;écriture dans .htaccess a échoué (permissions ?). Les règles ne sont pas actives. ». Avec l&rsquo;erreur, les deux filtres de WordPress restent quand même actifs.</p>
<p><strong>Attention :</strong> le plugin ne crée aucune sauvegarde de <code>.htaccess</code>. Il ne contrôle même pas la syntaxe avant d&rsquo;écrire. Une règle incompatible avec ton serveur peut provoquer une erreur 500 sur tout le site. Sur un réseau multisite, le fichier est celui du réseau : l&rsquo;erreur touche tous les sites.</p>
<h2>Ce qui se passe en coulisses</h2>
<p>Le plugin écrit entre deux marqueurs : <code># BEGIN Cisilino Site Defense Network - Hardening</code> et le <code># END</code> correspondant. Le reste du fichier n&rsquo;est pas touché. Un second bloc, séparé, contient les IP bloquées. Si tu désactives le plugin, les deux blocs sont vidés. Si tu éteins tout et enregistres, le bloc de durcissement reste vide.</p>
<h2>Si quelque chose ne va pas</h2>
<p>Si après le durcissement WordPress le site affiche une erreur 500, ouvre <code>.htaccess</code> par FTP. Supprime les lignes entre les deux marqueurs de durcissement. Puis réessaie avec moins de règles. Si l&rsquo;écriture dans le fichier échoue, vérifie les permissions de <code>.htaccess</code>.</p>
<p>Pour une vue plus large sur les bonnes pratiques, lis le guide officiel sur le <a href="https://developer.wordpress.org/advanced-administration/security/hardening/" target="_blank" rel="noopener">durcissement de WordPress</a> : il explique d&rsquo;autres mesures qui se situent hors du plugin.</p>
<p>Chapitre précédent : <a href="https://www.cisilino.com/fr/?p=977">Onglet IP bloquées : lire la liste noire</a>. Chapitre suivant : <a href="https://www.cisilino.com/fr/?p=979">Surveillance des téléversements et contrôle d&rsquo;intégrité</a>. Pour le sommaire complet, retourne à l&rsquo;<a href="https://www.cisilino.com/fr/?p=972">introduction du manuel</a>.</p><p>The post <a href="https://www.cisilino.com/fr/2026/10/30/durcissement-ids-regles-htaccess/">Durcissement / IDS : les règles pour .htaccess</a> first appeared on <a href="https://www.cisilino.com/fr/">Matteo Cisilino</a>.</p>]]></content:encoded>
					
					<wfw:commentRss>https://www.cisilino.com/fr/2026/10/30/durcissement-ids-regles-htaccess/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
	</channel>
</rss>
