Aller au contenu

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

Renforcez la sécurité de vos apps web avec Permissions-Policy Nginx pour restreindre les API navigateur et bloquer les bots malveillants. Guide complet.

Date de publication:
3 min de lecture

💡 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

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 :


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.


💡 À lire aussi : Step CA Docker : ta propre autorité de certification interne, dans la même veine que cet article.

Ressources utiles

Questions fréquentes

Le header Permissions-Policy remplace-t-il l'ancien Feature-Policy ?
Oui. Permissions-Policy est le successeur standardisé de Feature-Policy. La syntaxe a changé (plus de guillemets, nouvelle notation) mais le concept est identique. Feature-Policy est déprécié depuis Chrome 88.
Comment bloquer les bots sans affecter les vrais utilisateurs avec Permissions-Policy ?
Permissions-Policy contrôle les APIs navigateur (caméra, micro, géolocalisation), pas le trafic bot. Pour bloquer les bots, combiner fail2ban sur les logs Nginx + règles de rate limiting + Cloudflare Bot Management.
Peut-on tester ma Permissions-Policy sans la mettre en production ?
Oui. Dans Chrome DevTools, l'onglet Application > Permissions Policy affiche les permissions autorisées et bloquées sur la page courante. L'extension Security Headers permet aussi d'analyser les headers en temps réel.