Aller plus loin : Permissions-Policy et protection anti-bots sur Nginx

💡 TL;DR

• Après HSTS, CSP et X-Frame-Options, le header Permissions-Policy affine ta sécurité
• Il restreint les API navigateur (caméra, micro, géolocalisation) accessibles à ton site
• Plus des protections anti-bots intégrées à Nginx pour limiter les abus

Table des matières

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. Elle complète la Content-Security-Policy, qui contrôle les ressources chargées là où Permissions-Policy contrôle les APIs utilisées.

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éolocalisation
• fullscreen=(self) → autorise le plein écran uniquement depuis le site actuel
• payment=() → 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)
• Respect des 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. Le rate limiting agit en amont, avant même que la requête n’atteigne les blocs location que tu as sécurisés. 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 pic
• nodelay : 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 rate et burst aux 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_status pour 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.

Ressources utiles

• Permissions Policy - MDN
• Rate Limiting in Nginx
• OWASP Secure Headers Project
• Fail2ban - Official Site