Secure headers

Commentaires

2 réponses à “Secure headers”

1. 

   JEDI_BC

   4 février 2013

   Perso comme tous mes formulaires sont en Ajax, j’inclus dans les entêtes émis par mon JS X-Request-Fingerprint (empreinte de la page) et X-Request-Token (token de la page) afin de valider que toute soumission provient de la bonne page et a un token valide. La réponse contient un entête X-Request-Token pour mettre à jour le token du formulaire (un token correspond à une seule page et une seule émission possible du formulaire)

   Répondre
2. 

   Bruno Michel

   4 février 2013

   Voici ce que cela donne pour LinuxFr.org :

   – CSP : pas encore, faut que j’étudie ça.
   – HSTS : on a essayé mais ce n’est pas jouable avec un certificat signé par CAcert tant que CAcert ne sera pas reconnu officiellement par les principaux navigateurs.
   – X-Frame-Options : on l’a eu pendant un temps mais on l’a retiré car ça pose problème dans certains agrégateurs de news (netvibes notamment).
   – X-XSS-protection : j’ai regardé ce que ça faisait, ça ne me semblait pas très intéressant pour LinuxFr.org (on a d’autres moyens de se protéger) et je craignais les effets de bord.
   – X-Content-Type-Options : celui-là, on l’a !

   Et tant que l’on parle des headers HTTP pour la sécurité, une bonne idée est de mettre ses cookies en HttpOnly (ça permet de limiter la casse lors d’une attaque XSS notamment) et en secure s’ils sont servis en HTTPS.

   Répondre