Cabeceras de seguridad: Referrer policy: same-origin vs strict-origin-when-cross-origin

  • Autor Autor ramones33
  • Fecha de inicio Fecha de inicio
R

ramones33

Zeta
Verificación en dos pasos activada
¿Alguien me ayuda con esto de las cabeceras de seguridad? Ya estoy cansado de leer y no llego a la conclusión de cuál usar, entiendo la diferencia entre una y otra, pero ¿Cuál debo usar en mi web? Me parece entender que same origin es más estricta.

Mi web no tiene de especial, es sólo entrar, consumir el contenido y largarse, no hay registro, no hay compras, no hay comentarios, no hay enlaces de redes sociales. Es una web con AdSense y sólo AdSense como medio de monetización.
 
Si tu web no tiene la gran cosa... para empezar, para qué necesitas CORS? Same origin te indica que es para cuando queres que todo quede en "tudominio.com", en cambio con strict origin vos podes indicar que se pueda mostrar una imagen de tudominio.com en midominio.com, o viceversa usar cdn.midominio.com como servidor de imágenes para tudominio.com... de por sí es solo para restringir el uso de terceros de los recursos pero pueden hacer bypass si hay algo interesante... en caso de que no haya nada, no te sirve o solo usa same origin
 
Pero entiendo que sólo controla los datos que envía el referrer cuando el usuario va otro lugar desde un link de mi web, no el hotlinking.
 
ramones33 dijo:
Pero entiendo que sólo controla los datos que envía el referrer cuando el usuario va otro lugar desde un link de mi web, no el hotlinking.
Hacer clic para expandir...
Ahhh perdón, no había visto el referrer incluído y solo consideré lo último, acá te adjunto un enlace donde explica el autor de un plugin de wordpress cual tomó y porque: https://wordpress.org/support/topic/adsense-98/

Espero que te pueda ayudar ya que las razones están bastante buenas y completas
 
Ya lo tengo claro:

  • "same-origin" es más estricta que ya que sólo envía el referrer completo dentro del mismo origen, a saber, el mismo sitio web (esquema, puerto, dominio y subdominio), por lo que es la que he decidido usar en algunos sitios web, fuera del mismo origen no envía nada en el referrer.
  • "strict-origin-when-cross-origin" cumple perfectamente también pero funciona diferente, no envía nada si hay una degradación de seguridad, es decir, de https a http; si va al mismo origen, envía el referrer completo y si se navega fuera del origen, es decir, ejemplo a otro sitio web, envía sólo el dominio de origen en el referrer. Esta última opción me parece un poco menos privada pero perfectamente funcional y pienso que es útil en sitios multidominios.
Gracias por las respuestas
 
ramones33 dijo:
Ya lo tengo claro:

  • "same-origin" es más estricta que ya que sólo envía el referrer completo dentro del mismo origen, a saber, el mismo sitio web (esquema, puerto, dominio y subdominio), por lo que es la que he decidido usar en algunos sitios web, fuera del mismo origen no envía nada en el referrer.
  • "strict-origin-when-cross-origin" cumple perfectamente también pero funciona diferente, no envía nada si hay una degradación de seguridad, es decir, de https a http; si va al mismo origen, envía el referrer completo y si se navega fuera del origen, es decir, ejemplo a otro sitio web, envía sólo el dominio de origen en el referrer. Esta última opción me parece un poco menos privada pero perfectamente funcional y pienso que es útil en sitios multidominios.
Gracias por las respuestas
Hacer clic para expandir...
Nunca eh podido entender al 100% como funcionan estás propiedades..

Gracias por la info..
Aunque aún me resulta un poco confuso 😅
 
A ver si te sirve esta web, te analiza y te indica que necesitas mejorar: https://securityheaders.com/

2.webp
 
david limonche dijo:
Nunca eh podido entender al 100% como funcionan estás propiedades..

Gracias por la info..
Aunque aún me resulta un poco confuso 😅
Hacer clic para expandir...
Sí, es confuso, llevo varios días en ello. Los mejores sitios que he conseguido para entenderlo son:

developer.mozilla.org

Content Security Policy (CSP) - HTTP | MDN

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft, to site defacement, to malware distribution.
developer.mozilla.org developer.mozilla.org
www.keycdn.com

Hardening Your HTTP Security Headers - KeyCDN

HTTP security headers can provide another layer of security by helping to mitigate attacks and security vulnerabilities. Check out how to implement them.
www.keycdn.com www.keycdn.com
htaccessbook.com

Seven Important Security Headers for Your Website | .htaccess made easy

When it comes to securing your website, it's all about minimizing attack surface and adding more layers of security. One strong layer that you can (and...
htaccessbook.com htaccessbook.com

En el de mozilla, en el menú lateral tienes varias etiquetas, es parte de un tema más amplio que abarca diversas temas sobre http.

Varias las puedes implementar fácilmente utilizando Cloudflare.

developers.cloudflare.com

Available Managed Transforms · Cloudflare Rules docs

Create rules that adjust incoming HTTP requests at the edge.
developers.cloudflare.com developers.cloudflare.com

Yo estoy optando por hacerlo a nivel de servidor, pero primero me estoy documentando, me gusta entender qué estoy haciendo, te recomiendo abrir un word o excel y guardar un resumen de c/u para futura referencia porque sólo leyendo me pierdo ya que algunos nombres y funcionalidades de estas cabeceras de seguridad se parecen.
 
CSP es muy complicado de implementar con AdSense, voy a omitir esta cabecera.
 
Hay que estar conectado o registrado para responder aquí.
Atrás
Arriba