ForHosting KIT · Outils pour développeurs

Vérifiez Secure, HttpOnly et SameSite des cookies

La sécurité d’un cookie repose sur de petits attributs faciles à omettre lors d’un changement de configuration.

● BetaGratuit · dans votre navigateur
Utilisez-le depuis WebAPIE-mailTelegramApp bientôt

Cet outil lit une valeur d’en-tête Set-Cookie, confirme qu’elle commence par un nom et une valeur, puis indique la présence de Secure, HttpOnly et SameSite. Il fournit aussi la liste précise des attributs absents, afin de faciliter les revues, déploiements, tests et pipelines CI. Le contrôle est déterministe, ne tient pas compte de la casse des noms d’attribut et n’effectue aucune requête réseau.

Ce que l’outil examine

Collez la valeur d’un seul en-tête de réponse Set-Cookie, en commençant par le nom et la valeur du cookie. L’outil sépare la première paire name=value des attributs délimités par des points-virgules. Il recherche ensuite Secure, HttpOnly et SameSite sans dépendre de leur casse. Le résultat contient un booléen pour chaque protection, une liste ordonnée des attributs absents et le résumé `all_present`. Cette sortie convient à une inspection humaine comme à une règle automatisée. Le contrôle porte uniquement sur la présence des trois attributs ; il ne garantit pas la sécurité de la portée, de la durée, de la conception du cookie ou du comportement de l’application. Un résultat complet constitue donc un contrôle de configuration précis, et non un audit global de sécurité web.

Comment interpréter chaque attribut

Secure demande aux clients compatibles de n’envoyer le cookie que par un transport sécurisé. HttpOnly empêche le JavaScript ordinaire côté client de lire le cookie au moyen des API habituelles du navigateur, ce qui réduit les possibilités d’extraction d’un jeton de session. SameSite détermine si le navigateur joint le cookie dans différents contextes de requêtes intersites et participe souvent à la défense contre leur falsification. L’outil signale la présence sans choisir la bonne politique SameSite, car Strict, Lax et None répondent à des besoins différents. Une intégration intersite peut, par exemple, exiger SameSite=None avec Secure. Interprétez les résultats selon l’usage du cookie, sa sensibilité, les navigateurs pris en charge et les flux intersites prévus.

Utilisation en développement et en CI

Lancez le contrôle sur des valeurs Set-Cookie représentatives provenant des tests de l’application, du proxy inverse ou du framework. Dans un test automatisé, faites échouer le build lorsque `all_present` est faux, ou appliquez une politique plus ciblée à partir des trois booléens et de `missing_attributes`. L’analyseur étant déterministe et sans réseau, une entrée identique produit la même sortie dans le navigateur et par l’API. Envoyez un seul en-tête par requête : réunir plusieurs Set-Cookie crée des ambiguïtés. Une entrée dépourvue de paire name=value initiale est rejetée. Après une correction, testez de nouveau la réponse réellement émise, car un middleware, un proxy, un CDN ou un composant d’authentification peut modifier les attributs.

Examiner les cookies d’authentification

Vérifiez un cookie de session émis à la connexion et repérez immédiatement l’un des trois attributs manquants.

Ajouter une règle de sécurité au CI

Transmettez à l’API une valeur Set-Cookie issue d’un test d’intégration et arrêtez le pipeline si `all_present` est faux.

Valider les modifications du proxy

Comparez les en-têtes après une modification du proxy inverse ou du CDN pour détecter un attribut perdu lors de la réécriture.

Quel est le coût du contrôle ?

Chaque requête API coûte $0.002. La version navigateur peut fonctionner localement sans transmettre l’en-tête à un service réseau.

La valeur de SameSite est-elle validée ?

Non. L’outil indique si SameSite est présent. Le choix entre Lax, Strict et None dépend du comportement intersite attendu.

Les noms d’attribut sont-ils sensibles à la casse ?

Non. Secure, HttpOnly et SameSite sont reconnus quelle que soit leur combinaison de majuscules et de minuscules.

Puis-je vérifier plusieurs en-têtes Set-Cookie ensemble ?

Non. Envoyez une seule valeur Set-Cookie par requête afin d’obtenir un résultat sans ambiguïté pour chaque cookie.

Pourquoi mon entrée a-t-elle été rejetée ?

La valeur doit commencer par un nom de cookie non vide, suivi d’un signe égal et de sa valeur, avant les attributs séparés par des points-virgules.

Tout sur cette page est disponible par programmation. Cette section s'adresse aux équipes qui veulent l'intégrer à leurs systèmes ; les autres peuvent simplement utiliser l'outil ci-dessus.

POSThttps://api.kit.forhosting.com/security/cookie-attribute-check

Authentification par jeton Bearer : un seul POST met la tâche en file d’attente, et le résultat vous parvient par webhook ou lien signé.

curl -X POST https://api.kit.forhosting.com/security/cookie-attribute-check \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"text":"session_id=abc123; Path=/; Secure; HttpOnly; SameSite=Lax"}'
{
  "text": "session_id=abc123; Path=/; Secure; HttpOnly; SameSite=Lax"
}
{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "security.cookie_attribute_check",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

L’API est asynchrone : chaque appel renvoie un task_id immédiatement, puis vous interrogez l’état à raison d’une requête par seconde.

par requête$0.002

Le prix est publié, sans tokens ni crédits. Une tâche qui échoue n’est pas facturée.

HTTPCodeSignification
401unauthorizedClé API absente ou invalide : vérifiez l’en-tête Authorization.
402insufficient_balanceSolde insuffisant : rechargez votre compte pour lancer cette tâche.
404unknown_typeType de tâche inconnu : vérifiez le champ type de votre requête.
429rate_limitedTrop de requêtes : ralentissez la cadence, puis réessayez.

Consulter la documentation complète du KIT →