Cuánta seguridad necesita realmente un blog personal
Audité la seguridad de mi blog con varias herramientas públicas. Un análisis práctico sobre riesgos reales, decisiones conscientes y por qué no todo sitio necesita seguridad de banco.
Inicio — contexto
Se me dio por revisar la seguridad de este blog. No es que saltara alguna alarma, sino que me picó la curiosidad técnica. También me rondaba una pregunta medio rara:
¿Qué tan bien está esto que armé?
Y de esa pregunta, salió otra que me dejó pensando:
¿Hasta dónde tiene sentido complicarse la vida con la seguridad en los proyecto dev que uno emprenda?
Solo quiero entender lo que pasa en el lado oscuro de la web.
El punto de partida
Mi blog corre detrás de Cloudflare.
Tiene HTTPS forzado. Certificados válidos. No hay errores visibles cuando lo abro en el navegador.
Desde afuera parece “bien”.
Pero aquí va una cosa que muchos se olvidan:
“funciona” no siempre significa “está seguro”, ni mucho menos “está bien”.
Lo que hice — desde cero y con herramientas públicas
Pegué la URL en algunas herramientas gratuitas de análisis de seguridad:
- SSL Labs: Evalúa la configuración HTTPS y TLS del sitio. https://www.ssllabs.com/ssltest/
- SecurityHeaders: Analiza encabezados HTTP relacionados con seguridad. https://securityheaders.com/?q=&hide=on&followRedirects=on
- Mozilla HTTP Observatory: Escáner más estricto, orientado a “best practices”. https://developer.mozilla.org/en-US/observatory
- Sucuri SiteCheck: Escaneo de malware y listas negras. https://sitecheck.sucuri.net/
Sí… lo sé…
“Pegar la URL en herramientas de análisis y esperar que te digan si estás seguro” suena medio ingenuo.
Pero esa ingenuidad fue parte de esto. Yo no buscaba la perfección, solo entender un poco qué pasa y con suerte aprender algo.
Resultados… y primeros aprendizajes
SSL Labs dio A+ — eso estuvo claro desde el principio.
HTTPS está bien configurado. El transporte está cifrado.
Nada grave ahí.
Pero SecurityHeaders fue… bastante más brutal:
Resultado D — faltaban varios encabezados de seguridad básicos.
El escáner marcaba la ausencia de varios headers de seguridad comunes:
Content-Security-PolicyX-Frame-OptionsX-Content-Type-OptionsReferrer-PolicyPermissions-Policy
El único encabezado presente era Strict-Transport-Security (HSTS), heredado de la configuración base de Cloudflare.
Esto no indicaba un problema activo, pero sí un hardening incompleto a nivel de headers HTTP.
Y Mozilla HTTP Observatory fue también estricto, con un D+ (40/100).
Las penalizaciones principales se debían a:
- ausencia de Content-Security-Policy
- falta de X-Frame-Options
- falta de X-Content-Type-Options
- falta de Subresource Integrity (SRI)
Al mismo tiempo, no se detectaban:
- cookies inseguras
- CORS abierto
- redirecciones incorrectas
Es decir: la nota era baja, pero no por vulnerabilidades críticas, sino por falta de configuraciones consideradas “best practices”.
¿Esto significa que está “inseguro”? No exactamente.
Significa que no estaba endurecido según ciertas listas de best practices estrictas.
Y Sucuri no pudo escanear porque Cloudflare le devolvió un 403 — típico cuando un CDN bloquea bots “automáticos”.
El sitio bloqueaba el escaneo, algo habitual cuando está protegido por Cloudflare.
Lo importante:
- el dominio no aparecía en ninguna lista negra
- no había alertas de malware
- Google Safe Browsing y otros proveedores lo marcaban como limpio
Lectura del estado inicial
Los números eran claros, pero no contaban toda la historia.
- 🔐 Conexión segura (HTTPS / TLS): correcta
- 🛡️ Headers de seguridad: incompletos
- ☠️ Riesgos críticos: no detectados
- 📉 Notas bajas por falta de hardening fino
El sitio no estaba en riesgo, pero tampoco estaba deliberadamente configurado.
Había decisiones no tomadas, no errores.
Así que, en lugar de corregir todo de golpe o seguir ciegamente lo que sugerían los escáneres, decidí avanzar paso a paso, entendiendo qué hacía cada cambio y por qué.
El primer lugar donde empecé a intervenir fue Cloudflare.
Qué cambié después (y por qué)
Una vez que entendí el estado inicial del sitio, decidí no cambiar todo ni intentar “arreglar” cada advertencia que aparecía en los escáneres.
El objetivo fue otro:
reforzar primero lo básico y seguro, sin introducir complejidad innecesaria ni riesgo de romper el funcionamiento del blog.
Todo lo que hice en esta etapa fue desde Cloudflare, sin tocar el código ni el CMS.
Headers de seguridad básicos
Empecé agregando algunos encabezados HTTP ampliamente recomendados, con una característica en común:
son seguros de aplicar y no afectan el comportamiento normal del sitio.
Los principales fueron:
- X-Content-Type-Options
Evita que el navegador intente “adivinar” tipos de contenido.
Es simple, claro y de bajo riesgo. - X-Frame-Options
Protege contra ataques de clickjacking impidiendo que el sitio sea embebido en iframes externos. - Referrer-Policy
Limita la información que el navegador envía como referencia al navegar hacia otros sitios. - Permissions-Policy
Deshabilita explícitamente APIs del navegador que este sitio no utiliza (como cámara, micrófono o geolocalización).
Estos headers no convierten un sitio en “impenetrable”, pero sí eliminan vectores comunes y elevan el nivel general de endurecimiento.
Lo que no agregué (todavía)
Tan importante como lo que se agrega es lo que se decide no agregar.
Content-Security-Policy (CSP)
CSP es una herramienta poderosa, pero también delicada.
Una política mal definida puede romper scripts, estilos, embeds o integraciones externas.
En un blog con:
- contenido dinámico
- recursos externos
- CMS de terceros
agregar CSP “para subir la nota” no tiene sentido.
Prefiero entender primero qué bloquearía, antes de empezar a bloquear.
Subresource Integrity (SRI)
SRI exige definir hashes para cada recurso externo cargado.
En sitios modernos, esto se vuelve difícil de mantener y aporta un beneficio limitado en este contexto.
No lo descarté por desconocimiento, sino por proporcionalidad.
El resultado después de los cambios
Después de estos ajustes, los escáneres reflejaron una mejora clara:
SSL Labs se mantuvo en A+
SecurityHeaders subió a A
Mozilla Observatory mejoró, aunque sigue penalizando por CSP y SRI
Sucuri continúa bloqueado por Cloudflare, sin alertas reales
Más allá de las letras, el sitio quedó:
- mejor definido
- más explícito en sus límites
- más consciente de su superficie de ataque
¿Es suficiente?
Para este blog personal: sí.
Cubro:
✅ SSL/TLS correcto
✅ Headers principales implementados
✅ No estoy en blacklists
✅ Cloudflare protege contra DDoS y bots comunes
No tengo:
❌ SRI implementado
❌ CSP estricta sin unsafe-inline
❌ Score 100/100
Y esas ausencias son deliberadas. No son omisiones por desconocimiento, sino por proporción.
Dicho esto, estas decisiones no son universales.
Cambian por completo cuando cambia el tipo de proyecto.
Contexto importa
Blog personal (yo):
- Score 70/100 suficiente
- Balance entre seguridad y mantenimiento
E-commerce pequeño:
- Score 85/100 mínimo
- Más headers, mejor CSP
Banco/Fintech:
- Score 95/100 requerido
- Auditorías constantes, WAF enterprise
La pregunta no es "qué score puedo tener". Es "qué score necesito para mi caso".
Qué haría distinto en un proyecto más grande
Si este sitio fuera otra cosa —un producto, una plataforma con usuarios, o un sistema que maneje datos sensibles—, las decisiones serían distintas.
En un proyecto de mayor escala, sí tendría sentido:
- implementar Content-Security-Policy desde el inicio, incluso en modo estricto
- trabajar CSP en etapas, empezando por
report-onlyy ajustando con datos reales - evaluar Subresource Integrity para recursos críticos
- monitorear headers y cambios de configuración como parte del pipeline
- revisar periódicamente la superficie de ataque, no solo “una vez y listo”
La diferencia no está en las herramientas, sino en el contexto.
Un blog personal y un sistema con usuarios autenticados no enfrentan los mismos riesgos, y no deberían tener el mismo nivel de complejidad defensiva.
Conclusión
Esto no fue un ejercicio para sacar una A+ en alguna herramienta.
Fue aprender a leer qué dicen esas herramientas, pero más importante aún:
decidir con criterio qué aplicar y qué no.
Hoy este blog:
✅ está cifrado
✅ usa HTTPS bien
✅ tiene encabezados de seguridad básicos
❌ no tiene CSP completa
❌ no tiene SRI en todos lados
Y eso está bien — porque sé por qué tomé esas decisiones.
Última reflexión
Si tenés un e-commerce, un sistema con usuarios o datos sensibles, la respuesta cambia. Ahí sí hay que endurecer más y ser más rígido. cesarbeassuarez.dev
Pero para un blog personal, lo que importa no es el score perfecto,
sino entender realmente tus riesgos reales y tomar decisiones conscientes.
Seguridad es defensa en profundidad, no perfección absoluta. Tu nivel de seguridad debe coincidir con tu nivel de riesgo.
Para otros bloggers
Si tenés blog/sitio personal:
Mínimo indispensable:
✅ SSL/TLS (A o A+)
✅ X-Frame-Options
✅ X-Content-Type-Options
Nice to have:
⚠️ Referrer-Policy
⚠️ CSP básico
⚠️ Permissions-Policy
Overkill para blogs:
❌ SRI en todo
❌ CSP perfecto sin unsafe
❌ WAF enterprise
Herramientas para medir:
- SSL Labs (SSL/TLS)
- Mozilla Observatory (headers)
- Security Headers (headers)
- Sucuri (malware/blacklist)
—
Temas conectados:
La infraestructura completa que audité en este análisis: Cómo armé este sitio
Otro ejemplo de auditar configuración técnica: El correo “funciona” mucho antes de estar bien configurado