🔒 Empêcher certains outils d'accéder au HTML d'une page
Oui, on peut mettre en place en PHP ou avec .htaccess un système qui refuse certaines requêtes HTTP avant que la page HTML ne soit envoyée.
⚠️ Il faut toutefois distinguer deux choses :
- on ne peut pas empêcher un navigateur qui reçoit le HTML de l'examiner ;
- on peut empêcher certains clients HTTP d'obtenir la page.
1. Avec .htaccess — solution simple
On peut examiner le User-Agent envoyé par le client.
Par exemple :
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} beautifier [NC]
RewriteRule ^ - [F,L]
Si le client envoie un User-Agent contenant beautifier, Apache renvoie :
HTTP 403 Forbidden
Le fonctionnement est alors :
Navigateur Chrome
↓
requête HTTP
↓
.htaccess
↓
User-Agent = Chrome
↓
AUTORISÉ
↓
PHP / HTML
Alors que :
HTML Beautifier
↓
requête HTTP
↓
.htaccess
↓
User-Agent = HTML Beautifier
↓
REFUSÉ
↓
HTTP 403
2. Bloquer plusieurs clients connus
On peut également écrire :
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (beautifier|curl|wget|python|scrapy|httpclient) [NC]
RewriteRule ^ - [F,L]
Cela bloque les requêtes dont le User-Agent contient l'un de ces termes.
3. Faire le contrôle en PHP
Le même principe peut être réalisé directement dans index.php :
<?php
$userAgent = $_SERVER['HTTP_USER_AGENT'] ?? '';
if (preg_match('/beautifier|curl|wget|python|scrapy|httpclient/i', $userAgent)) {
http_response_code(403);
exit('Access denied');
}
Le PHP récupère le User-Agent avec :
$_SERVER['HTTP_USER_AGENT']
et peut décider de refuser ou d'autoriser la requête.
4. ⚠️ Limite importante du User-Agent
Cette protection est facile à contourner.
Par exemple, HTML Beautifier pourrait envoyer :
User-Agent: Mozilla/5.0
au lieu de :
User-Agent: HTML Beautifier
Le serveur ne pourrait alors plus distinguer ce client d'un navigateur classique avec ce seul critère.
Le User-Agent ne constitue donc pas une véritable protection contre le scraping.
5. 🔐 Une protection plus sérieuse
Pour se rapprocher du comportement d'un véritable système anti-bot, on peut combiner plusieurs informations :
Adresse IP
+
User-Agent
+
Cookies
+
Session
+
Referer
+
fréquence des requêtes
+
nombre de pages demandées
+
éventuellement un token
Le serveur peut alors établir une règle du type :
requête
↓
vérifier IP
↓
vérifier User-Agent
↓
vérifier cookie/session
↓
vérifier fréquence des requêtes
↓
┌───────────────────┐
│ comportement │
│ normal ? │
└───────────────────┘
↓ ↓
OUI NON
↓ ↓
envoyer HTML HTTP 403
6. Ce que cela protège réellement
Cette technique ne cache pas le HTML envoyé au navigateur.
Si Chrome reçoit :
<h1>Ma page</h1>
l'utilisateur pourra toujours examiner ce HTML avec les outils de développement du navigateur.
En revanche, le serveur peut empêcher un client donné de recevoir la page :
Client HTTP
↓
requête
↓
serveur
↓
contrôle anti-bot
↓
refus 403
Dans ce cas, le client n'obtient tout simplement pas le contenu.
7. Pour un CMS PHP
Pour un CMS comme celui que j'utilise avec des pages Markdown, l'architecture peut être :
/pages/
accueil.md
mairie.md
citations.md
↓
index.php
↓
contrôle anti-bot
↓
Parsedown
↓
HTML final
↓
navigateur
Le visiteur ne reçoit donc jamais directement :
accueil.md
mairie.md
citations.md
ni le code PHP qui effectue le traitement.
Il reçoit uniquement le résultat HTML généré par PHP.
8. La distinction essentielle
Il faut donc distinguer :
| Objectif | Possible ? |
|---|---|
| Empêcher Chrome de voir le HTML qu'il reçoit | ❌ Non |
Empêcher Ctrl+U de fonctionner |
❌ Pas réellement |
| Désactiver F12 | ❌ Pas réellement |
| Bloquer le clic droit | ❌ Protection très faible |
Bloquer un User-Agent particulier |
✅ Oui |
| Refuser certaines adresses IP | ✅ Oui |
| Limiter les requêtes répétitives | ✅ Oui |
| Exiger une session/cookie | ✅ Oui |
| Refuser certains clients avant d'envoyer le HTML | ✅ Oui |
| Cacher le PHP au visiteur | ✅ Oui, normalement le PHP reste côté serveur |
| Cacher le Markdown original | ✅ Oui, s'il reste côté serveur |
9. Dans le cas de Babelio
Le comportement observé avec HTML Beautifier est compatible avec un filtrage HTTP côté serveur / système anti-bot ou anti-scraping.
Ce n'est donc pas nécessairement :
« Babelio cache son code HTML »
mais plutôt :
« Babelio refuse certaines requêtes qui cherchent à récupérer son contenu »
Le navigateur normal reçoit la page et peut donc en examiner le DOM.
Un outil externe comme HTML Beautifier peut, lui, recevoir un refus ou une réponse différente.
En résumé
Le mécanisme de base est très simple :
requête HTTP
↓
contrôle côté serveur
↓
┌──────────────┐
│ autorisée ? │
└──────────────┘
↓ ↓
OUI NON
↓ ↓
HTML 403
envoyé refus
Avec Apache, le premier niveau peut être réalisé directement dans .htaccess.
Avec PHP, le même contrôle peut être effectué dans index.php.
Pour obtenir une protection réellement efficace contre les outils de récupération automatique, il faut cependant aller au-delà du simple User-Agent et combiner plusieurs critères de détection.