web-dev-qa-db-fra.com

En-têtes de sécurité pour une API Web

Je viens de recevoir une configuration, une API Web golang derrière un serveur caddy qui a HTTPS par défaut via Let's Encrypt, le serveur proxy toutes les demandes à l'API Web. J'ai donc fait le tour de tester la "sécurité" de mon serveur Web sur des sites tels que securityheaders.io. Ils m'ont donné un F, alors j'ai ajouté les en-têtes qu'ils demandaient et j'ai obtenu un A

Access-Control-Allow-Methods "GET, POST, OPTIONS"
Strict-Transport-Security "max-age=31536000;"
Content-Security-Policy "script-src 'self'"
X-XSS-Protection "1; mode=block"
X-Content-Type-Options "nosniff"
X-Frame-Options "DENY"
-Server

Ce sont les en-têtes que j'ai actuellement, mais j'aimerais savoir s'ils sont nécessaires pour la sécurité lorsque ce que je fais n'est pas un site Web mais plutôt un serveur Web API, quelque chose comme

Access-Control-Allow-Methods "GET, POST, OPTIONS"
-Server

Donc, fondamentalement, tous ces en-têtes de sécurité nécessaires si vous souhaitez simplement demander votre API?

proxyapiheader
14
Whiteclaws

La vérification des en-têtes d'une liste n'est pas la meilleure technique pour affirmer la sécurité d'un site. Des services comme securityheaders.io peuvent vous orienter dans la bonne direction, mais ils ne font que comparer avec une liste de paramètres proposés sans aucun contexte sur votre application. Par conséquent, certaines des propositions n'auront aucun impact sur la sécurité d'un point de terminaison API qui ne sert que des réponses JSON.

  • Strict-Transport-Security est logique car il garantit que les utilisateurs se connecteront directement à votre site via HTTPS après leur première visite et jusqu'au max-age expiration du délai - empêchant ainsi les attaques de déclassement. Même un point de terminaison API doit être sécurisé avec SSL, alors gardez cet en-tête.

  • Access-Control-Allow-Methods: GET, POST, OPTIONS n'est pas une option de sécurité en soi. Si votre API fonctionne via CORS les demandes de contrôle en amont, vous devez décider quelles méthodes vous autorisez pour les sites multi-origines à utiliser. La désactivation de CORS pourrait rendre votre API indisponible. Si ce paramètre particulier est sensible, cela dépend de votre implémentation.

  • X-XSS-Protection: 1; mode=block peut être un bon conseil pour les sites réguliers car il indique à l'auditeur XSS (qui est implémenté dans les navigateurs WebKit mais pas Firefox) de ne pas rendre le site lorsqu'il détecte une tentative XSS reflétée. Mais pour une API qui fournit simplement des réponses JSON et ne sert pas de contenu actif, cet en-tête n'apporte aucun avantage.

  • X-Content-Type-Options: nosniff empêche les navigateurs de faire des hypothèses sur le type de contenu si le site n'a pas déclaré le type correctement. Si vous exécutez une API JSON, vous devez envoyer les réponses avec Content-Type: application/json. Si vous le faites correctement, vous n'aurez pas besoin d'ajouter la directive nosniff.

  • X-Frame-Options: Deny empêche tout site Web d'incorporer votre site dans un cadre HTML. Cette option s'arrête attaques de détournement de clics où un attaquant incite les utilisateurs à interagir avec votre site Web à travers un cadre déguisé. Mais sans éléments interactifs, le risque lié au cadrage cross-origine est limité. Cependant, comme il existe des attaques avancées impliquant de faire glisser du contenu hors du cadre qui pourraient révéler des réponses JSON, vous pouvez toujours laisser cet en-tête là.

  • Content-Security-Policy les en-têtes contrôlent le type de contenu de quelle origine votre site est autorisé à interagir (scripts, feuilles de style, images, etc.). Votre réglage "script-src 'self' signifie que seuls les scripts de la même origine peuvent être chargés. Un CSP est utile pour les sites classiques mais n'a aucun sens pour votre point de terminaison API car vous ne diffusez aucun contenu actif pouvant être contrôlé par le CSP.

  • L'en-tête Server spécifie des informations sur le serveur et les logiciels qui y sont exécutés. Il est souvent conseillé de ne pas envoyer cet en-tête du tout pour ne rien divulguer sur le logiciel et les versions du backend.

32
Arminius