Guías de seguridad
4 errores de seguridad habituales: configuración por defecto, servicios olvidados, falta de monitorización y confiar demasiado en la validación de entradas
Los incidentes reales rara vez implican ataques sofisticados. Ordenadas por la suposición que hay detrás, las causas se reducen a cuatro creencias, y cada una fue cierta en algún momento, por eso nadie las vuelve a revisar.
Si pones en fila los incidentes que ocurren de verdad, las técnicas de ataque sofisticadas casi no aparecen. Lo que aparece es un pequeño conjunto de patrones que se repiten, y esos patrones se ven más claros ordenados no por tecnología, sino por la suposición que hay detrás.
① La suposición de que lo que viene por defecto es seguro (no se configuró nada)
Valores por defecto pensados para desarrollar con comodidad
errores detallados · paneles de administración accesibles · permisos amplios
↓ se publican sin cambios
Muestra detalles internos a quien mire
la estructura, las rutas, las versiones y los valores internos quedan a la vista
- Salida de depuración activada en producción
- ¿Las páginas de error muestran variables de entorno, rutas de archivos o trazas de pila? Abre una URL que no exista y mira con tus propios ojos lo que devuelve. Los detalles de cada framework están en las guías por framework
- Paneles de administración accesibles
- Herramientas de gestión de bases de datos y consolas de administración accesibles desde internet. No confíes solo en la autenticación: añade restricciones por IP o un bloqueo a nivel de red
- Cabeceras sin configurar o copiadas de una lista desfasada
- Consulta qué cabeceras siguen importando y cuáles no. Una cabecera obsoleta puede hacer daño si la añades
- Almacenamiento débil que sigue en uso
- El almacenamiento de contraseñas, como se explica en hash y sal. «Está cifrado» no describe un esquema de almacenamiento
- Las actualizaciones se han parado
- Usar un lenguaje, framework o CMS más allá de su periodo de soporte. Consulta la monitorización automática de dependencias y qué significa realmente el fin del soporte
② La suposición de que lo que no se usa es inofensivo (no se cerró nada)
Buena parte de tu superficie de ataque viene más de lo que dejaste de usar que de lo que construiste. Cuando algo deja de usarse, sale de la monitorización y de las revisiones sin que nadie lo note.
- Secretos olvidados en un directorio público
.env, copias de seguridad, volcados, archivos de configuración. lo que nunca debe estar en un directorio público / la ubicación en un hosting compartido- Almacenamiento que sigue siendo público
- Activar el bloqueo no borra la política pública existente. buckets públicos
- Registros DNS colgantes
- Si borras un recurso sin borrar la entrada DNS, cualquiera puede reclamar el nombre y quedarse con el subdominio. toma de subdominios
- Rutas de registro y de administración abiertas
- ¿Sigue activado el registro abierto? Compruébalo por HTTP en lugar de leer la configuración (autenticación frente a autorización). No dejes que una URL fácil de adivinar sea lo único que «oculta» una página
- Cuentas que creías canceladas
- Darse de baja de un servicio y borrar la cuenta son cosas distintas, y los datos se quedan hasta que los borras. cuando tu proveedor de hosting sufre una brecha
- Claves, tokens y permisos antiguos
- Cuentas de compañeros que ya se fueron, tokens sin caducidad, alcances demasiado amplios. claves SSH y mínimo privilegio / gestores de contraseñas
No limites el inventario a lo que está en funcionamiento
Si limitas la revisión a «lo que se usa ahora», este patrón no se puede encontrar. Amplíala a todo lo que hayas creado alguna vez: subdominios, cuentas, claves, buckets, entornos de pruebas y suscripciones a terceros. Algo que dejaste de usar sigue siendo un activo hasta que se borra. Cómo hacer la lista: la lista de comprobación del inventario de activos.
③ La suposición de que te darías cuenta (no hay monitorización)
El daño depende menos de la brecha en sí que de cuánto tiempo pasa hasta que alguien se da cuenta. Y la mayoría de los entornos no tiene ningún mecanismo para darse cuenta.
La situación habitual
・Hay registros de acceso, pero nadie los lee
・No hay registro de auditoría de los intentos de autenticación (así que después no se puede reconstruir «qué se vio»)
・Hay límites de frecuencia configurados, pero nadie ve cuándo saltan
・Que algo sea público depende de la combinación de varias capas, así que ninguna por sí sola responde la pregunta
Al final, sobre si pasó algo, solo se puede decir «no lo sabemos».
El mínimo que merece la pena tener
・Un aviso cuando se registra un usuario nuevo (una sola señal basta para detectar algo raro)
・Un registro de los inicios de sesión correctos y fallidos, con un periodo de conservación
・Monitorización automática de las vulnerabilidades de las dependencias (las personas no pueden seguirlo → osv-scanner)
・Un registro de las veces que salta un límite y una alerta ante un pico (limitación de frecuencia y control de abusos)
No necesitas todo. Una forma de detectar problemas que funcione es lo que evita que un incidente se alargue.
Sin registros, la respuesta honesta es «no lo sabemos», no «no pasó nada»
El movimiento más peligroso en la respuesta a incidentes es tomar la ausencia de registros como prueba de que no pasó nada. Sin registros, lo único que se puede afirmar es «no lo sabemos», y en ese caso hay que actuar suponiendo un compromiso y cambiar todo lo que pudo quedar expuesto. El mínimo para una organización está en la base de seguridad para organizaciones.
④ La suposición de que la entrada validada es segura
La pregunta real sobre una entrada no es «¿este valor es correcto?», sino «¿cuánto he dejado que decida esta entrada?». Cuantas más decisiones delegas, menos puede seguir el ritmo la validación.
- Solo el valor
- Entrada normal. Las comprobaciones de longitud, formato y rango funcionan: el lado seguro
- También la estructura
- Diseños que aceptan un objeto anidado completo y lo fusionan. contaminación de prototipos
- También el tipo
- Formatos que reconstruyen objetos. El ataque tiene éxito antes de que se ejecuten tus comprobaciones de valores. deserialización insegura
- Dónde termina
- Subidas de archivos que acaban en un lugar donde se pueden ejecutar. vulnerabilidades en la subida de archivos
- Quién hace la petición
- Confiar en una cabecera de la petición para decidir la identidad del cliente. la suplantación de X-Forwarded-For y los proxies de confianza
Contar las decisiones que has delegado te muestra los puntos peligrosos. Y la causa de fondo suele ser la misma: intentar resolver con validación lo que debería resolverse con la estructura. Cambiar el formato que aceptas es más fiable que añadir otra comprobación.
Hacerlo por orden
Mira cómo se ve realmente producción (①)
Una URL que no existe, una petición que da error, las rutas de administración: pídelas por HTTP y mira lo que devuelven. Se trata de leer la salida, no la configuración. Las cabeceras se pueden medir de una vez con el analizador de cabeceras.
Apunta todo lo que hayas creado alguna vez (②)
Subdominios, cuentas, claves, buckets, servicios de terceros. El truco es no filtrar por «sigue en funcionamiento». Haz la lista con la lista de comprobación del inventario de activos y lleva lo que no se usa hasta el borrado (no basta con desactivarlo).
Prepara una sola forma de detectar problemas (③)
Intentar montar una monitorización completa suele acabar en ninguna. Empieza por una: avisos de registros nuevos, un pico de inicios de sesión fallidos o el correo de vulnerabilidades de las dependencias. Una, comprobando que de verdad salta (una monitorización configurada pero nunca verificada es una monitorización que no tienes).
Cuenta lo que dejas decidir a tus entradas (④)
Escribe si los datos externos deciden solo valores o también la estructura, el tipo y el destino. Cualquier sitio donde decidan más que valores es un punto prioritario para cambiar.
Convierte las actualizaciones en un mecanismo (para que ① no vuelva)
El primer patrón vuelve sin falta si se deja estar. Poner las actualizaciones de dependencias y del framework bajo monitorización automática es la única respuesta realista (primeros pasos con osv-scanner / un manual práctico para corregir CVE). Un procedimiento que solo existe en un documento es lo primero que se salta en un día de mucho trabajo.
La visión de este sitio: las cuatro fueron ciertas en algún momento
Lo que tienen en común las cuatro es que cada una fue correcta en algún momento. Los valores por defecto eran razonables durante el desarrollo; lo que no se usaba realmente no se usaba; cuando eras pequeño, de verdad te habrías dado cuenta; y la validación de entradas ha resuelto muchísimos problemas. Precisamente por eso no se revisan.
Nuestra postura es preguntarse de forma periódica cuándo dejó de ser correcta una suposición que antes lo era. Esa revisión es más barata y más eficaz que añadir más tecnología. Y fíjate en la diferencia: una lista de comprobación te dice qué hacer, pero no por qué se pasó algo por alto, y si la razón no cambia, lo mismo se volverá a pasar por alto en el mismo sitio.
Leer a continuación
- Como pasos: la lista de comprobación de la base de seguridad (particulares y equipos pequeños) / la base de seguridad para organizaciones
- Inventario: la lista de comprobación del inventario de activos
- A partir de casos reales: análisis de incidentes (los mismos patrones se repiten una y otra vez)
- Tendencia: en 2026, los atacantes llegaron con credenciales más a menudo que con exploits
FAQ
Q¿Por dónde empiezo con la seguridad?
Comprobar con cuál de los cuatro patrones coincide tu entorno da resultados más rápido que aprender técnicas de ataque concretas. ¿La configuración de producción sigue con los valores por defecto? ¿Sigue abierto algo que creaste y nunca cerraste? ¿Te darías cuenta si algo fallara? ¿Cuánto dejas decidir a la entrada externa? Este artículo da las comprobaciones concretas de cada uno y enlaza a los artículos que profundizan.
Q¿Esto se aplica a un sitio personal pequeño?
Los patrones son los mismos; cambia el orden. Para un particular o un equipo pequeño, los dos que antes compensan son revisar la configuración por defecto (¿está activada la salida de depuración en producción?) y hacer inventario de lo que nunca se cerró (secretos en un directorio público, subdominios sin uso, cuentas inactivas). La observabilidad necesita más infraestructura y puede esperar, pero incluso una sola señal, como un aviso cuando se registra un usuario nuevo, acorta mucho el tiempo que un problema pasa sin detectarse.
Q¿En qué se diferencia esto de una lista de comprobación?
Una lista de comprobación te dice qué hacer; esto trata de por qué se pasan cosas por alto. Enumerar elementos no ayuda si la razón por la que se pasaron por alto sigue igual: lo mismo se volverá a pasar por alto en el mismo sitio. Las cuatro creencias fueron ciertas en algún momento, y por eso siguen sin revisarse. Cuando quieras los pasos concretos, sigue los enlaces a los artículos de listas de comprobación de cada sección.
QSolo tengo tiempo para uno. ¿Cuál?
Corrige algo del tercero: poder darte cuenta. Los dos primeros se convierten en incidentes si se ignoran, pero sin el tercero no sabrás que hubo un incidente. El daño depende menos de la brecha que del tiempo que pasa sin detectarse. Guarda un registro, añade un aviso, haz un inventario al mes: cualquiera de esas cosas es la inversión individual más rentable para que un incidente no se alargue.