Sommaire :
Introduction
Lorsque vous avez déjà mis en place les headers classiques (HSTS, CSP, X-Frame-Options…), il reste encore des moyens d’affiner votre politique de sécurité.
Deux approches particulièrement utiles :
- Les Permissions-Policy : pour limiter ce que le navigateur est autorisé à faire (caméra, micro, géolocalisation…)
- Le Rate Limiting dans Nginx : pour bloquer ou ralentir les requêtes abusives, souvent utilisées par des bots ou des scripts malveillants
Ces deux mesures combinées offrent un contrôle plus précis du comportement client et protègent votre serveur contre les abus.
1. Permissions-Policy : contrôle des capacités navigateur
Anciennement connue sous le nom de Feature-Policy, cette en-tête HTTP permet de restreindre ou autoriser l’accès aux fonctionnalités sensibles du navigateur, comme la caméra, le micro, la géolocalisation, etc.
Objectif :
Empêcher les navigateurs d’accéder à des APIs si ce n’est pas nécessaire au bon fonctionnement du site.
Exemple de configuration :
add_header Permissions-Policy "geolocation=(), microphone=(), camera=(), fullscreen=(self), payment=()" always;
Explication :
geolocation=()→ désactive complètement l’accès à l’API de géolocalisationfullscreen=(self)→ autorise le plein écran uniquement depuis le site actuelpayment=()→ interdit l’usage de l’API de paiement
Vous pouvez affiner domaine par domaine, exemple :
camera=(self "https://appli.externe.com")
Pourquoi l’utiliser ?
- Réduction des risques d’exploitation des APIs navigateur
- Moins de permissions = surface d’attaque plus faible
- Compatible avec les navigateurs modernes (Chrome, Edge, Firefox)
- Permet de respecter les règles RGPD en désactivant des fonctions sensibles
2. Rate limiting avec Nginx : la protection anti-bots native
Les attaques par force brute, les scans automatisés ou les abus de formulaire sont des menaces constantes pour les serveurs web. Heureusement, Nginx dispose de modules intégrés pour contrôler le débit par IP.
Étape 1 : définir une zone de limitation
limit_req_zone $binary_remote_addr zone=antibot:10m rate=10r/s;
Cette directive :
- Crée une zone appelée
antibot - Limite à 10 requêtes par seconde par IP
- Utilise jusqu’à 10 Mo de mémoire partagée (peut contenir environ 160 000 IP)
Étape 2 : appliquer la règle
location / {
limit_req zone=antibot burst=20 nodelay;
}
burst=20: permet une petite tolérance en picnodelay: autorise le burst sans ralentissement
💡 Tu peux adapter cette règle pour les zones sensibles uniquement :
location /login {
limit_req zone=antibot burst=5;
}
Résultat :
Les requêtes excessives sont automatiquement ralenties ou rejetées avec une réponse HTTP 503 ou 429.
Bonus : filtrer certains User-Agent
Pour bloquer certains bots connus :
if ($http_user_agent ~* (HTTrack|wget|curl|scanner|sqlmap)) {
return 403;
}
Et si tu veux aller plus loin :
- fail2ban pour bannir les IP
- ModSecurity pour un WAF plus complet
Exemple combiné : sécurité sur un endpoint de formulaire
location /contact {
limit_req zone=antibot burst=3;
add_header Permissions-Policy "microphone=(), camera=(), payment=(), fullscreen=(self)" always;
try_files $uri $uri/ /contact/index.php?$args;
}
Astuces pour ne pas bloquer les vrais utilisateurs
- Adapte
rateetburstaux cas réels : 5 requêtes/seconde suffisent pour un humain. - Exclue les robots légitimes (Googlebot, Bingbot) si besoin avec une whiteliste.
- Surveille les logs de
limit_req_statuspour analyser les rejets.
Conclusion
Ces deux techniques permettent de passer un cap supplémentaire dans la sécurisation de votre site :
- Les Permissions-Policy vous donnent un contrôle fin sur les capacités du navigateur côté utilisateur
- Le Rate Limiting protège votre backend des abus, sans surcoût de performance
Intégrées intelligemment dans Nginx, elles renforcent l’intégrité, la disponibilité et la confidentialité de vos services web.
