Antes de pagar por una auditoría de seguridad: ¿existe una lista de verificación que podamos aplicar nosotros mismos?

Abre la consola de desarrollador del navegador, mira la pestaña de seguridad y escanea tu sitio con herramientas gratuitas de análisis de cabeceras. Añadir a la configuración del servidor las cabeceras de seguridad que falten en el informe solo lleva 30 minutos y descarta la mitad del reporte de entrada.

El año pasado pagamos 3.200 libras por un informe de pentesting que contenía 11 hallazgos. 7 de ellos eran cabeceras faltantes en el servidor y listado de directorios abierto. Si hubiéramos hecho esas comprobaciones antes, habríamos obligado a la empresa auditora a buscar fallos lógicos reales en el flujo de pagos.

Personaliza sí o sí las páginas de error. Si tu servidor o software muestra un stack trace o la versión de la base de datos cuando da un error 500, le estás dando un mapa al atacante. En producción, desactiva los detalles del error y muestra solo un código genérico.

Añade también esto a tu checklist: 1) Tokens CSRF activos en los formularios de reserva. 2) Que el robots.txt no exponga paneles ocultos o directorios de respaldo. 3) Escanear archivos de configuración sensibles como .zip, .sql o .env que hayan quedado olvidados en el servidor.

Con tu propia lista cubres la higiene básica, pero no creas que es un sustituto de un test profesional. Los fallos en la lógica de negocio (por ejemplo, escalar privilegios cambiando el ID de reserva de otra persona) no salen en ninguna lista automática. Haz tu lista, pero no descartes la auditoría por completo.

yo tmb diría q revises el sistema de copias de seguridad... la seguridad no es solo el momento del ataque; si algo sale mal ¿puedes volver a los datos limpios de hace 1 hora y esa copia está en otro servidor aislado? eso es súper crítico.

Al operar en el Reino Unido, la protección de los datos de los usuarios conlleva una responsabilidad legal directa. Elaborar un informe interno con las comprobaciones básicas realizas y fecharlo demostrará la buena fe y el enfoque proactivo de su empresa ante una eventual auditoría de seguridad de datos.

No te asustes estos controles los haces en un día. Al menos arregla las configuraciones básicas antes de ir a hablar con ellos; cuando les digas "ya hicimos las comprobaciones básicas, solo queremos un análisis profundo de la lógica de negocio" puede que hasta te bajen el precio del presupuesto.

Yo también pienso lo mismo. Todo lo que no está por escrito, ambas partes lo recordarán de forma distinta en el futuro.

Corrijanme si me equivoco.

estoy siguiendo esto. las soluciones que funcionan a pequeña escala se rompen al crecer, aprendí esto tarde.

tomar notas durante dos semanas da mejores resultados que estimar seis meses luego en fin si escribís el resultado aquí también servirá de ayuda a otros.

Hay una cosa a la que hay que prestar atención. Si es la primera vez que lo hacéis, empezad poco a poco, la escala llegará después.

Intentar hacerlo solo es la vía más cara. Ánimo.

La respuesta de arriba ha dado en el clavo. Intentar hacerlo solo es la vía más cara.

Si el camino de la notificación es largo, la notificación no llega; una notificación que no llega significa un incidente detectado tarde. Yo seguiría por ese camino.

Este hilo es para archivar.

no te olvides de: El tiempo que tardas en detectar un problema determina directamente su coste.

por supuesto cambia si tu situación es diferente.

Tengo una pregunta, no quiero desviarme del tema, pero... Al tomar decisiones, escribe también el peor escenario, no solo el mejor.

Corrijanme si me equivoco.

el año pasado nos pasó casi exactamente lo mismo. la seguridad no es absoluta; significa hacer que el ataque no merezca la pena.

también me gustaría saber si alguien lo hace de otra manera.

Lo probaré.

Han surgido tres opiniones distintas, todas se complementan. Si el permiso y el alcance no están por escrito que no empiece la prueba.

Si escribís el resultado aquí, también servirá de ayuda a otros.