En corto
- El foco es seguridad y datos: quién puede llegar a qué y qué puede salir de tu sistema.
- Reviso control de acceso, credenciales expuestas, dependencias sin actualizar, validación en servidor, copias de seguridad y tratamiento de datos personales.
- El fallo que más datos filtra no es una intrusión: es el servidor entregando el pedido de otro a quien lo pide bien.
- Trabajo con acceso de lectura y autorización por escrito del titular. No modifico producción.
- Entrego un informe priorizado por riesgo: dónde está el fallo, qué se puede sacar aprovechándolo y cómo se cierra.
- Si lo que necesitas es la foto general del proyecto y no la seguridad, eso es la auditoría técnica y va por otro camino.
¿Qué se revisa en un análisis de seguridad de una web o una aplicación?
Seis frentes, siempre los mismos, porque son por donde salen los datos.
Lo que no entra es el estado general del proyecto ni la arquitectura. Eso es otra revisión distinta y tiene su propia página.
- Control de acceso: que el servidor no deje pedir lo que no es tuyo
- Credenciales, claves de API y tokens expuestos
- Dependencias con fallos publicados y entornos sin soporte
- Validación en servidor de todo lo que llega desde fuera
- Copias de seguridad: qué cubren, dónde viven y si se restauran
- Datos personales: qué guardas, quién los ve y a dónde salen
¿Puede un cliente ver los pedidos de otro cliente desde mi propia web?
Es un fallo que filtra muchísimo y que además no hace ruido. No hay intrusión: el servidor entrega los datos porque se los han pedido bien.
Tu pedido está en una dirección acabada en 1042. Cambias el número por 1041 y sale el pedido de otra persona, con su nombre, su dirección y su teléfono. Vale igual para una factura o un expediente. Que el botón no aparezca en pantalla da igual: la dirección responde.
La causa suele ser la misma: el servidor comprueba quién eres, pero no que el dato sea tuyo. Autenticar no es autorizar.
El arreglo va dentro de la consulta, filtrando siempre por el propietario del dato, no en una comprobación suelta que alguien olvidará en la ruta siguiente.
Claves, contraseñas y tokens expuestos: por dónde se escapan
Una credencial filtrada convierte todo lo demás en decoración.
El fichero de variables de entorno subido al repositorio el primer día. El historial de Git, donde la clave sigue viva aunque la hayas quitado del código: borrarla hoy no la borra del pasado. Claves de terceros incrustadas en el código que descarga el navegador, a la vista de cualquiera. Tokens de administrador usados para tareas que solo leen.
Dos cosas que puedes hacer sin ayuda: buscar en tu repositorio palabras como password, secret, token o api_key, y revisar quién entra hoy al hosting, la base de datos y la pasarela de pago. Una clave expuesta se cambia, no se esconde.
¿Qué riesgo corro por no actualizar las librerías de mi web?
Tu proyecto no es solo tu código. Instalas veinte librerías y esas veinte arrastran cientos. Cualquiera puede tener un fallo publicado, con su versión afectada y a menudo el ejemplo de cómo se aprovecha. Publicado quiere decir público.
Actualizarlo todo a ciegas tampoco es la respuesta: rompe cosas y come tiempo. Lo que importa es separar la librería que atiende peticiones de fuera de la que solo sirve para compilar.
Empieza por lo barato: el comando de auditoría de tu gestor de paquetes, comprobar si el lenguaje y el sistema donde corre la aplicación siguen recibiendo actualizaciones, y activar los avisos de dependencias del repositorio. Un entorno fuera de soporte ya no recibe parches.
El formulario valida en el navegador y eso no protege nada
Todo lo que llega al servidor viene de fuera y puede venir manipulado. El navegador es del usuario, no tuyo: cambiar un campo oculto o mandar la petición sin pasar por tu formulario es cuestión de un minuto.
Por eso la validación que cuenta está en el servidor. Miramos si cada campo se valida por tipo y tamaño; si se aceptan campos que el usuario no debería poder enviar, como el precio, el rol o el identificador del propietario; si las consultas van con parámetros en vez de pegando texto; y si lo que escribe un usuario se limpia antes de mostrárselo a otro.
¿Tus copias de seguridad servirían si mañana las necesitas?
Una copia es una promesa hasta que la restauras. Entonces pasa a ser un dato.
Tres preguntas que conviene responder por escrito. Qué entra: la base de datos sola no sirve si pierdes los ficheros que suben tus usuarios. Dónde vive: si está en la misma cuenta que la aplicación, un borrado se lleva las dos cosas. Y cuánto se guarda hacia atrás: si el problema se descubre a las tres semanas y solo conservas siete días, no tienes copia.
Después, restaurar en un entorno limpio y cronometrarlo. De ahí salen las dos cifras que importan: cuánto tardas en volver y cuántos datos pierdes por el camino.
¿Dónde están mis datos personales y quién puede verlos?
Antes de proteger datos personales hay que saber cuáles tienes, y esa lista casi nunca está escrita.
Aparecen en sitios que nadie decidió: registros de errores que guardan la petición entera con el correo o el documento dentro, copias de la base de datos en el portátil de alguien, hojas de cálculo exportadas hace dos años y cada servicio externo que se fue conectando, con su propia copia de tus clientes.
Lo que reviso: qué se guarda y para qué, qué campos se piden y no se usan, quién tiene acceso dentro de la empresa, qué sale hacia fuera y si se puede borrar todo lo de una persona cuando lo pide. Del cumplimiento formal se ocupa un especialista en protección de datos.
Cómo comprobar yo mismo si mi web tiene un problema de seguridad
Cinco comprobaciones que no necesitan desarrollador.
Abre dos cuentas de prueba y, con la sesión de una, intenta abrir el pedido de la otra cambiando el número en la dirección. Si sale, tienes el hallazgo más grave que te puede tocar.
Abre las herramientas de desarrollo del navegador y mira qué claves viajan al cliente.
Entra en los paneles de hosting, correo y pagos y quita a quien ya no trabaje contigo.
Pide la última copia de seguridad y restáurala aparte, con el reloj en marcha.
Escribe en una hoja qué datos personales guardas y a qué servicios externos salen.
Si algo de eso falla, ya sabes por dónde empezar aunque no me llames nunca.
¿Análisis de seguridad o auditoría técnica? Cuál te toca a ti
Se parecen, pero no responden a la misma pregunta.
El análisis de seguridad es esta página: quién puede llegar a tus datos y qué puede salir. Lo quieres si vendes por internet, si guardas datos de clientes o pacientes, o si el proyecto lo levantó otro y no sabes qué dejó abierto.
La auditoría técnica mira el proyecto entero: arquitectura, calidad del código, rendimiento y coste de infraestructura. La quieres si vas a comprar una empresa o un software, o si tienes que decidir entre arreglar lo que hay y rehacerlo.
Si dudas, cuéntanos el caso y te decimos cuál. Si con el análisis de seguridad tienes bastante, no te vendo la auditoría.
Preguntas frecuentes
¿En qué se diferencia un análisis de seguridad de una auditoría técnica?+
El análisis de seguridad responde a una pregunta concreta: quién puede llegar a tus datos y qué puede salir. Revisa control de acceso, credenciales expuestas, dependencias, validación en servidor, copias de seguridad y datos personales. La auditoría técnica es más ancha y responde al estado del proyecto: arquitectura, código, rendimiento, costes e infraestructura. Si lo que te preocupa son los datos, empieza por el análisis de seguridad.
¿Un análisis de seguridad es lo mismo que un test de intrusión?+
No. Un test de intrusión ataca el sistema desde fuera, sin conocerlo, e intenta explotar lo que encuentre. Un análisis de seguridad se hace desde dentro, con acceso de lectura al código y a la configuración. Así aparecen cosas invisibles desde fuera, como que una cuenta pueda pedir el pedido de otra. Si lo que necesitas es un test de intrusión formal para enseñárselo a un tercero, eso lo hacen empresas especializadas y te lo decimos.
¿Un escáner automático de vulnerabilidades no hace ya esto?+
Un escáner conviene pasarlo, pero encuentra lo que sabe buscar: versiones con fallos publicados, cabeceras mal puestas, patrones conocidos. Lo que no sabe es cómo funciona tu negocio. No puede saber que ese pedido no es de esa cuenta, que ese usuario no debería poder cambiar el precio ni que ese informe solo lo ve el responsable de una sucursal. El control de acceso se revisa leyendo el código y probando con cuentas creadas para la revisión, nunca con datos de clientes reales.
¿Necesitas acceso a mi código y a mi servidor para revisar la seguridad?+
Sí, acceso de lectura al repositorio y a la configuración de donde esté desplegado: ahí se ve el control de acceso, las dependencias y dónde acaban los datos. Firmamos acuerdo de confidencialidad antes de tocar nada y trabajamos con permisos de solo lectura: no se modifica producción, y las pruebas se hacen con cuentas creadas para eso, no con datos de clientes reales. Hace falta también autorización por escrito del titular.
¿Qué me entregas cuando terminas la revisión de seguridad?+
Un informe escrito y priorizado por riesgo, en castellano y sin jerga. Cada hallazgo lleva dónde está, qué datos se pueden sacar aprovechándolo, qué hace falta para aprovecharlo y cómo se cierra. Y una llamada para explicarlo a quien tú digas, incluido tu proveedor actual si el arreglo lo va a hacer él. El informe es tuyo y vale igual si el trabajo se lo das a otro.
Creo que ya se han llevado datos de mi web. ¿Qué hago primero?+
Lo primero, no borrar nada: los registros del servidor y de la aplicación son la única forma de saber qué pasó y qué se llevaron, y muchos sistemas los rotan en pocos días. Guarda una copia aparte antes de tocar. Después, cambiar credenciales, revisar qué cuentas de administrador existen y cerrar la vía de entrada. Una brecha con datos personales conlleva además obligaciones de notificación con plazos marcados por la normativa: eso se consulta con la Agencia Española de Protección de Datos o con un asesor legal.
Cuéntanos qué datos guardas y quién puede llegar a ellos
Escríbenos qué es el proyecto, qué datos de personas hay dentro y qué te ha hecho pensar en esto. Te contestamos si lo tuyo es un análisis de seguridad, una auditoría técnica o dos consejos por correo que lo dejan resuelto. Si por lo que cuentas hay algo urgente, te lo decimos en la respuesta y no te hago esperar a una reunión.
Pedir una revisión de seguridad