Una lista de seguridad para trabajar antes de lanzar

Veintidós preguntas, agrupadas en seis áreas. Cada una tiene un sí o un no, y cada una dice qué pasa si la respuesta es no — porque el sentido de una lista es dejarte decidir con qué estás dispuesto a lanzar, no hacerte sentir atrasado.

Nada de esto es específico de un framework, y no hace falta un fondo de seguridad. Si puedes leer tu propio código y cargar tu propio sitio, puedes responder las veintidós. Trabaja de arriba abajo: el orden es aproximadamente por lo que cuesta una respuesta incorrecta.

Secretos y credenciales

1. ¿Cada clave de API y URL de base de datos se lee del entorno? Busca en el código los prefijos que usan tus proveedores — sk_, AKIA, ghp_, -----BEGIN. Si una clave está en el código, cualquiera con acceso al repositorio la tiene, que suele incluir a más gente de la que crees.
2. ¿Se ha revisado el historial de git, no solo el árbol de trabajo? git log --all -p -S "sk_live". Borrar un secreto en un commit posterior no lo quita del repositorio, y reescribir el historial no lo des-divulga. Si encuentras uno, rótalo antes de hacer cualquier otra cosa.
3. ¿Las credenciales de producción son distintas de las de tu portátil? Compartirlas significa que un error en desarrollo es un error en producción, y que no puedes revocar un portátil sin tumbar el sitio.
4. ¿Sabes cómo rotar cada una? No en teoría. Qué página, qué botón y qué se rompe en los minutos entre que muere la clave vieja y se despliega la nueva. La primera vez que hagas esto no debería ser durante un incidente.

Autenticación

5. ¿Las cookies de sesión son HttpOnly, Secure y están acotadas con SameSite? Carga tu sitio y lee las cabeceras de respuesta. Sin HttpOnly, cualquier script de la página puede leer la sesión; sin Secure, viaja por HTTP plano si algo degrada la conexión.
6. ¿Un restablecimiento de contraseña invalida las sesiones existentes? Quien restablece una contraseña suele creer que accedieron a su cuenta. Si la sesión del atacante sobrevive, el restablecimiento no hizo nada.
7. ¿Hay un límite de tasa en el acceso, el alta y el restablecimiento? Sin uno, un atacante puede probar una lista de contraseñas filtradas contra tus usuarios tan rápido como responda tu servidor, y tu endpoint de restablecimiento se convierte en una forma de enviar correo desde tu dominio.
8. ¿Los accesos fallidos dicen lo mismo exista o no la cuenta? «No hay cuenta con ese correo» convierte tu formulario de acceso en una forma de comprobar cuáles de un millón de direcciones son tus clientes.

Autorización

9. ¿Cada endpoint que lee un registro por id comprueba quién pregunta? Es el fallo serio más habitual en una aplicación construida rápido. Recorre cada ruta que toma un id de la petición y pregunta qué impide que alguien envíe otro. «La interfaz solo les muestra los suyos» no es una respuesta; la interfaz no es un control.
10. ¿La comprobación de pertenencia está en la consulta y no después? Una búsqueda acotada a { id, ownerId: session.userId } no puede devolver la fila de otra persona. Una búsqueda seguida de un if se puede copiar sin su segunda mitad.
11. ¿Los endpoints de escritura comprueban lo mismo que los de lectura? Actualizar y borrar se olvidan a menudo porque primero se corrigió la lectura y pareció la parte difícil.
12. ¿Las rutas de administración están protegidas por una comprobación en el servidor? Ocultar el enlace, o comprobar un rol en el navegador, deja la ruta abierta a quien teclee la URL.
13. ¿Un usuario puede cambiar campos que no debería enviando propiedades extra? Si pasas el cuerpo de la petición a una llamada de actualización, una petición con role o plan puede establecerlos. Valida contra una lista explícita de campos en lugar de filtrar los que se te ocurrieron.

Pagos

14. ¿El manejador del webhook verifica la firma antes de leer el cuerpo? Y rechaza si falla, en lugar de registrar y continuar. Un manejador sin verificar deja que cualquiera que conozca la URL te diga que una factura se pagó.
15. ¿Los importes cobrados salen de tu propia base de datos? Si el navegador envía un importe y el servidor lo cobra, tus precios se editan en las herramientas de desarrollador. Envía un identificador de producto; busca el precio.
16. ¿Un evento de webhook repetido es inofensivo? Los proveedores reintentan. Un manejador que añade un mes de acceso cada vez que corre acabará regalando varios. Registra el id del evento e ignora uno que ya hayas procesado.
17. ¿El acceso se deriva del estado de la suscripción y no de un evento pasado? Si una cancelación o un pago fallido no te llega, los derechos deberían caducar solos en lugar de persistir porque nadie les dijo que pararan.

Dependencias y datos

18. ¿Has ejecutado la auditoría de tu gestor de paquetes y leído la salida? Léela, no la cuentes: una dependencia solo de build con un aviso grave suele ser menos urgente que una que atiende peticiones con uno medio.
19. ¿Hay una decisión registrada para lo que no estás corrigiendo? Un riesgo aceptado con fecha es una decisión. Un riesgo aceptado sin ella es algo que olvidaste.
20. ¿Hay copias de seguridad de la base de datos, y has restaurado una? Una copia que nunca has restaurado es una creencia sobre una copia. Restaura una vez en una base de pruebas, antes de necesitarlo.
21. ¿Tus logs se mantienen libres de contraseñas, tokens y datos de tarjeta? Registrar el cuerpo entero de una petición es la forma habitual de que lleguen. Revisa sobre todo lo que registras en la ruta de error, que es donde la gente vuelca todo lo que tiene.

Configuración de despliegue

22. ¿Producción está configurada de verdad como producción — sin salida de depuración, sin CORS permisivo, sin stack traces, sin rutas solo de desarrollo? Carga el sitio desplegado sin sesión y prueba una ruta que creas interna. Busca en la configuración "*" en cualquier cosa de CORS, y cada comparación contra NODE_ENV que apague una comprobación.

Qué hacer con los noes

Escríbelos con la consecuencia al lado de cada uno, y decide. Algunos merecen retrasar un lanzamiento y otros no, y la diferencia es si el daño se deshace con una disculpa. Una clave de pago divulgada, un cliente leyendo los datos de otro y una base de datos que no puedes restaurar son los tres que no.

Todo lo demás es una lista que recorres en las primeras semanas, y una lista es una posición mucho mejor que la sensación vaga de que probablemente deberías haber comprobado algo.

Hacer esto otra vez el mes que viene

Lo difícil no es el primer pase. Es la cuarta funcionalidad, cuando la lista está en un documento que nadie ha abierto y las respuestas de la primera semana ya no son ciertas.

Esa repetición es para lo que sirve de verdad la automatización. Audixa ejecuta las comprobaciones de las secciones de secretos, dependencias, control de acceso y configuración contra tu repositorio, y — cuando hayas demostrado que controlas el dominio — contra lo que sirve tu sitio. Cada resultado trae el código o la cabecera que coincidió, para que puedas decir si es real. Ver la lista completa de lo que comprueba, o leer la guía compañera sobre por qué se repiten estos errores.

Lo que ninguna herramienta puede responder por ti es la pregunta nueve. Si un usuario dado debería poder ver un registro dado es un hecho sobre tu producto, no sobre tu código, y es la pregunta en la que merece la pena gastar tu propia hora.