Nuestra propia auditoría
Estos son los hallazgos que produce nuestra herramienta cuando audita nuestro propio sitio — y lo que hicimos con cada uno.
Toda herramienta de auditoría tiene un conflicto de interés: quien la construye controla los pesos y puede ajustarlos hasta que su propio sitio apruebe. Por eso, una nota de aprobación en nuestro propio sitio no probaría nada.
Esta página hace lo contrario. Registra, con fechas, dónde nuestro propio sitio no aprueba las comprobaciones que vendemos. Una entrada permanece aquí después de resolverse, con las dos fechas — la del hallazgo y la de la resolución. Mantenemos las fallas en el registro; borrarlas destruiría el sentido de la pieza.
Ejecutamos esta auditoría en nuestro propio sitio mientras lo construimos, y corregimos hallazgos antes de que lleguen a nadie. Cuando ejecutamos nuestra auditoría gratuita en nuestro propio sitio el 1 de agosto de 2026, obtuvo 96 de 100 — y, de las 31 comprobaciones, la única que no aprobaba era la Content-Security-Policy registrada abajo. Esa también ya está resuelta, así que los cuatro registros que siguen llevan ambas fechas.
Nuestras comprobaciones de accesibilidad aprobaban por presencia de string, no por elemento
Hallazgo: 31 de julio de 2026
- Qué. Ejecutadas en páginas reales, nuestras cinco comprobaciones de accesibilidad aprobaban siempre que el atributo relevante apareciera en cualquier lugar del HTML. Un único atributo alt, en cualquier imagen, marcaba la página entera como aprobada. Era un falso positivo, no un falso negativo — el sitio devolvía una aprobación que no era cierta, justo en las comprobaciones que el producto vende.
- Por qué. Las comprobaciones probaban la presencia de una string en el código fuente de la página en lugar de inspeccionar cada elemento. Medida contra axe-core en tres páginas reales, la superposición fue cero: en css-tricks.com nuestro motor reportaba el texto alternativo de las imágenes como aprobado con 7 imágenes sin alt, y los puntos de referencia semánticos como aprobados con 120 nodos fuera de cualquier landmark.
- Plan. Reescribimos las cinco comprobaciones para verificar cada elemento en lugar de casar una string, en el ticket DEV-236. Corregir un falso aprobado baja las notas, y lo hizo: en css-tricks.com la nota de accesibilidad cayó de 100 a 50 y la nota total de 87 a 79 — lo mismo para nuestras propias auditorías. Lo registramos porque es la prueba más directa de que no ajustamos notas para agradar: la corrección movió el número hacia abajo.
Resolución: 31 de julio de 2026. Un límite honesto permanece, abierto en el ticket DEV-238: el informe entrega el veredicto — aprobado o no — sin el recuento detrás de él. Dice que una comprobación no aprobó, pero aún no cuántos elementos fallaron. Publicar la corrección sin nombrar ese límite prometería más de lo que el producto entrega hoy.
Nuestra Content-Security-Policy no aprobaba nuestra propia auditoría
Hallazgo: 1 de agosto de 2026
- Qué. Ejecutada en nuestro propio sitio, nuestra comprobación de Seguridad para Content-Security-Policy (CSP) devolvía un fallo.
- Por qué. La política que servíamos dependía de 'unsafe-inline' en sus directivas de script y de estilo (y de 'unsafe-eval' para scripts). Esos permisos debilitaban la protección que una CSP existe para dar, así que la comprobación no aprobaba. La cabecera estaba presente; solo era demasiado permisiva para contar como aprobación.
- Plan. Estamos endureciendo la política en el ticket DEV-193. Quitar Google Tag Manager (ya hecho) hace que la política más estricta ya no necesite un nonce por petición — la parte cara y arriesgada de la corrección. Plazo: dentro de 30 días de esta entrada, hasta el 31 de agosto de 2026.
Resolución: 30 de agosto de 2026. La política que servimos ahora solo admite scripts mediante un nonce acuñado en cada petición — script-src 'self' 'nonce-…' 'strict-dynamic' — sin 'unsafe-inline', sin 'unsafe-eval' y sin el comodín que permitía cargar un script desde cualquier origen https. Lo comprobamos como lo haría un cliente: nuestra propia auditoría, ejecutada contra el sitio publicado y no contra el archivo de configuración, aprueba esta comprobación. Dos correcciones quedan a la vista, en lugar de una edición silenciosa del plan de arriba. El plan se equivocaba sobre el nonce: quitar Google Tag Manager no quitó los scripts inline, porque el framework sobre el que construimos escribe los suyos en cada página — 33 de las 35 etiquetas de script de nuestra portada son suyas, y cada una lleva ahora el nonce. Y la corrección es parcial en un punto que no vamos a ocultar: la nueva política no restringe los estilos. Una CSP no tiene forma de permitir un atributo style inline salvo con el propio 'unsafe-inline' — justo el permiso del que trata esta entrada — y los componentes de interfaz que usamos escriben esos atributos mientras la página se ejecuta. Así que nuestros scripts están cerrados y nuestros estilos no. Un script se ejecuta y un estilo no: por eso hicimos ese intercambio; pero es un intercambio, y su lugar es esta página.
Nuestro detector de tecnologías reportaba tecnologías que no estaban
Hallazgo: 27 de julio de 2026
- Qué. Nuestro detector de tecnologías nombraba tecnologías que un sitio no usaba. En un informe de pago listó nueve, y solo dos eran reales — se equivocaba siete de nueve. Como la Guía de IA leía esa lista, llegó a recomendar instalar un gestor de etiquetas en un sitio que no tenía ninguno.
- Por qué. El detector casaba texto mostrado en la página en lugar de la infraestructura detrás de ella — casaba substrings en prosa corrida y, en un caso, leyó la lista de tecnologías impresa de otro sitio como si fueran las de este. No fue una mala firma; fue un límite del método. Un análisis que no ejecuta JavaScript no ve lo que un sitio realmente carga en tiempo de ejecución.
- Plan. Como la causa era el método y no una regla, apagamos la capacidad en lugar de parchearla, en el ticket DEV-223 — la visualización, la alimentación de la Guía de IA y la mención comercial en el paywall, en los tres idiomas. Apagar la entrega significó quitar la promesa con ella.
Resolución: 31 de julio de 2026.
El informe de un cliente podía ser indexado por motores de búsqueda
Hallazgo: 27 de julio de 2026
- Qué. La ruta del informe de pago se servía sin una directiva noindex, así que el informe de un cliente — que nombra la URL auditada y sus hallazgos de seguridad — podía aparecer en resultados de búsqueda.
- Por qué. La ruta heredaba los metadatos por defecto del sitio, que permiten la indexación, y nunca los sobrescribía. El informe existe para tener un enlace permanente y compartible; nunca se pensó para ser descubierto en búsqueda.
- Plan. Añadimos noindex a la ruta del informe y quitamos la etiqueta canonical que apuntaba los informes de staging al dominio de producción, en el ticket DEV-222. El enlace del informe sigue siendo permanente y compartible, y ahora no es indexable.
Resolución: 28 de julio de 2026.
Si la fecha de un plan vence antes de que la corrección entre en producción, esta entrada se actualizará con el motivo y una nueva fecha — nunca se eliminará en silencio.
Ve los hallazgos de tu propio sitio
Ejecuta la misma auditoría en tu sitio.
Auditar mi sitio