Secureheaders, une gem ruby pour ajouter et configurer des entêtes liées à la sécurité sur vos applications web.
- Content Security Policy (CSP) – Helps detect/prevent XSS, mixed-content, and other classes of attack. CSP 1.1 Specification
- HTTP Strict Transport Security (HSTS) – Ensures the browser never visits the http version of a website. Protects from SSLStrip/Firesheep attacks. HSTS Specification
- X-Frame-Options (XFO) – Prevents your content from being framed and potentially clickjacked. X-Frame-Options draft
- X-XSS-Protection – Cross site scripting heuristic filter for IE/Chrome
- X-Content-Type-Options – Prevent content type sniffing
Et vous, quelles entêtes ajoutez vous à vos sites pour gérer la sécurité ?
2 réponses à “Secure headers”
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)
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.