Enciclopedia de Seguridad

Los usuarios pueden actuar fuera de sus permisos, accediendo a datos de otros usuarios o funcionalidad admin sin verificaciones de autorización.

Datos sensibles expuestos por encriptación débil o faltante — usar algoritmos obsoletos como MD5/SHA1, guardar passwords en texto plano o transmitir datos sin TLS.

Tu aplicación hereda vulnerabilidades de dependencias de terceros — paquetes desactualizados con CVEs conocidos que los atacantes explotan activamente.

Configuraciones por default, CORS abierto, modo debug en producción o mensajes de error detallados exponen tu aplicación a atacantes.

El atacante inserta código malicioso en queries o comandos explotando input de usuario sin sanitizar — inyección SQL, NoSQL y de comandos del sistema.

La arquitectura de la aplicación tiene fallas de seguridad fundamentales — lógica de negocio en el cliente, falta de validación server-side o sin modelado de amenazas.

Mecanismos de autenticación débiles permiten a atacantes comprometer passwords, keys o tokens de sesión — JWT sin expiración, tokens en localStorage o sin MFA.

Aplicaciones que no verifican la integridad de datos, actualizaciones de software o pipelines CI/CD son vulnerables a manipulación — deserialización insegura y updates sin firmar.

Logging insuficiente o faltante de eventos de seguridad como logins fallidos, violaciones de acceso y cambios de datos hace imposible detectar y responder a ataques.

El atacante engaña al servidor para hacer requests a recursos internos — accediendo a metadata de cloud, APIs internas o servicios que no deberían ser alcanzables públicamente.

API keys, passwords o tokens hardcodeados directamente en el código fuente de la app móvil — fácilmente extraíbles al decompilar el bundle.

SDKs vulnerables, librerías nativas desactualizadas o módulos de terceros comprometidos introducen riesgos de seguridad desde tus dependencias.

Apps móviles con autenticación débil — guardando sesiones de forma insegura, sin refresh de tokens o checks de autorización solo en el cliente.

Apps móviles que no validan input de usuario o sanitizan output son vulnerables a ataques de inyección, corrupción de datos y comportamiento inesperado.

La app móvil transmite datos sensibles por HTTP en vez de HTTPS, o acepta certificados SSL inválidos — habilitando ataques man-in-the-middle en WiFi público.

La app móvil recolecta, almacena o transmite información personal (PII) sin consentimiento adecuado, encriptación o prácticas de minimización de datos.

La app móvil carece de ofuscación de código, anti-tampering o protecciones anti-debugging — facilitando ingeniería inversa, modificación y redistribución.

La app móvil sale con modo debug habilitado, permisos excesivos, activities exportadas o backup permitido — exponiendo datos y funcionalidad a otras apps.

Datos sensibles como tokens, passwords o información personal guardados en texto plano en el dispositivo — en AsyncStorage, SharedPreferences o bases de datos locales sin encriptación.

La app móvil usa algoritmos de encriptación débiles, keys hardcodeadas o implementa criptografía custom — dejando datos encriptados efectivamente desprotegidos.

Los endpoints de API no verifican que el usuario que hace el request es dueño del recurso al que accede — permitiendo a atacantes acceder a datos de otros usuarios cambiando IDs.

Los mecanismos de autenticación de la API son débiles o están mal implementados — JWT sin validación adecuada, tokens fuera de cookies httpOnly o sin expiración.

La API permite a usuarios leer o modificar propiedades a las que no deberían tener acceso — mass assignment, exposición excesiva de datos o falta de control de acceso a nivel de campo.

Endpoints de API sin rate limiting, paginación o límites de recursos — permitiendo a atacantes agotar recursos del servidor, generar costos o extraer datasets grandes.

Endpoints admin o privilegiados accesibles a usuarios regulares — la falta de checks de roles permite escalación de privilegios a funciones administrativas.

Flujos críticos de negocio como registro, reset de password o compras no tienen protección contra bots como CAPTCHA, rate limiting o fingerprinting de dispositivo.

La API hace fetch a una URL proporcionada por el usuario sin validación, permitiendo a atacantes acceder a servicios internos, endpoints de metadata cloud o redes privadas.

Las APIs exponen información excesiva a través de CORS abierto, errores verbosos, headers de seguridad faltantes o configuraciones por default sin endurecer.

Múltiples versiones de API siguen activas sin documentación ni deprecación, dejando endpoints antiguos con vulnerabilidades conocidas accesibles para atacantes.

Tu API confía ciegamente en respuestas de APIs de terceros sin validación, permitiendo a atacantes explotar servicios upstream para comprometer tu aplicación.

Las tablas de Supabase sin RLS habilitado permiten a cualquier usuario autenticado o anónimo leer, insertar, actualizar y eliminar todas las filas usando la librería cliente.

Las políticas RLS que usan USING(true) o WITH CHECK(true) efectivamente deshabilitan la seguridad a nivel de fila al permitir todas las operaciones para todos los usuarios.

RLS está habilitado en una tabla pero no hay políticas definidas, lo que silenciosamente bloquea todo el acceso incluyendo queries legítimos de tu aplicación.

La service_role key de Supabase está hardcodeada en código frontend, comiteada en un repo o expuesta en bundles del cliente, dando acceso admin completo a la base de datos a cualquiera.

Los buckets de storage de Supabase con políticas permisivas permiten a cualquier usuario subir, leer o eliminar archivos incluyendo documentos privados e imágenes de otros usuarios.

Las funciones de base de datos de Supabase (RPC) son invocables desde el cliente sin verificar auth.uid(), permitiendo a usuarios anónimos ejecutar operaciones privilegiadas.

El rol de base de datos anon tiene permisos en demasiadas tablas, expandiendo la superficie de ataque para cualquiera con la anon key públicamente disponible.

Los cambios de esquema de base de datos se aplican manualmente por el Dashboard de Supabase en vez de archivos de migración trackeados, haciendo imposible auditorías de seguridad y rollbacks.

Las reglas de seguridad de Firestore configuradas como 'allow read, write: if true' dan a cualquier usuario — autenticado o no — acceso completo para leer, crear, modificar y eliminar todos los documentos.

Las reglas de Firebase Realtime Database con '.read: true' y '.write: true' a nivel raíz permiten a cualquiera en internet leer y modificar todos los datos.

Las reglas de Firebase Cloud Storage permiten a cualquier usuario leer, escribir o eliminar archivos sin autenticación, exponiendo contenido subido y habilitando manipulación de archivos.

Las reglas Firebase a nivel padre sobreescriben reglas restrictivas de los hijos, otorgando involuntariamente acceso más amplio del pretendido a colecciones y documentos anidados.

La configuración de Firebase (apiKey, projectId, databaseURL) está hardcodeada en bundles de JavaScript y públicamente accesible, permitiendo a atacantes interactuar con tus servicios de Firebase.

Firebase Authentication permite registro sin verificación de email, habilitando a atacantes a crear cuentas ilimitadas y abusar de funciones que solo requieren autenticación.

Las Cloud Functions de Firebase expuestas como endpoints HTTP aceptan y procesan requests sin verificar tokens de autenticación ni validar datos de entrada.

Usar dangerouslySetInnerHTML de React con input de usuario sin sanitizar permite a atacantes inyectar scripts maliciosos que se ejecutan en los navegadores de otros usuarios.

Guardar JWT tokens, tokens de sesión o API keys en localStorage los hace accesibles a cualquier JavaScript corriendo en la página, incluyendo payloads XSS.

Los props de página de Next.js pasados por getServerSideProps o getStaticProps filtran datos sensibles como API keys, URLs de base de datos o configuración interna a través del script tag __NEXT_DATA__.

Los archivos source map de JavaScript (.map) son públicamente accesibles en producción, revelando el código fuente original completo incluyendo comentarios, nombres de variables y lógica interna.

Las API routes de Next.js configuradas con Access-Control-Allow-Origin: * permiten a cualquier sitio web hacer requests cross-origin autenticados, habilitando ataques tipo CSRF.

Los Server Actions ejecutados sin validar el origen permiten que sitios maliciosos disparen acciones en nombre de usuarios autenticados.

Una vulnerabilidad crítica en Next.js anteriores a la 15.2.3 permite a atacantes saltarse completamente los checks de autenticación en middleware enviando un header interno especial.

API keys, tokens o secretos escritos directo en el código fuente, visibles para cualquiera con acceso al repo — incluyendo repos públicos de GitHub.

Datos enviados por el usuario pasados directo a bases de datos o APIs externas sin ninguna validación de tipo, formato o contenido.

Contraseñas de usuarios guardadas como strings crudos en la base de datos en lugar de hashearse con bcrypt o Argon2.

JWTs firmados sin el claim `exp` que nunca expiran, lo que significa que un token robado da acceso permanente sin forma de revocarlo.

Mostrar u ocultar elementos de UI basándose en el rol del usuario en React, sin ninguna validación server-side — fácilmente bypasseable abriendo DevTools.

API routes que realizan operaciones sensibles — leer datos de usuarios, modificar registros, eliminar recursos — sin ninguna verificación de sesión o token.

Mensajes de error detallados, stack traces o rutas internas enviados al cliente o logueados públicamente, dándole a los atacantes un mapa de tus internals.

Paquetes npm u otras dependencias con vulnerabilidades de seguridad publicadas (CVEs) que no se han actualizado, dejando vectores de ataque conocidos abiertos en tu app.

Pasar datos controlados por el usuario a eval(), new Function() o funciones similares de ejecución de código dinámico, habilitando ejecución de código arbitrario en tu servidor.

Un archivo .env con credenciales reales commiteado a git, haciendo todos los secretos permanentemente accesibles para cualquiera con acceso al repo — incluso a través del historial de git.

El header Content-Security-Policy (CSP) está ausente, dejando a los navegadores sin instrucciones sobre qué fuentes de scripts, estilos y recursos confiar.

El header X-Frame-Options está ausente, permitiendo a atacantes embeber tu app en un iframe invisible y engañar usuarios para que hagan clic en tus elementos de UI (clickjacking).

El header X-Content-Type-Options: nosniff está ausente, permitiendo que los navegadores adivinen el tipo de contenido de una respuesta y potencialmente ejecuten contenido como script.

El header Strict-Transport-Security está ausente, permitiendo a los navegadores conectarse por HTTP plano y habilitando ataques de downgrade donde un atacante intercepta tráfico no cifrado.

Cookies de sesión configuradas sin el flag Secure, permitiendo que se transmitan por conexiones HTTP no cifradas y sean interceptadas por atacantes en la red.

Cookies de sesión o auth accesibles para JavaScript via document.cookie, permitiendo que ataques XSS roben tokens de sesión directamente del navegador.

Cookies sin el atributo SameSite (o configuradas como None sin Secure), habilitando cross-site request forgery al permitir que las cookies se envíen con requests de origen cruzado.

Servidor que acepta versiones obsoletas de TLS (TLS 1.0, TLS 1.1) o cipher suites débiles, habilitando ataques de downgrade que descifran tráfico supuestamente cifrado.

Input del usuario insertado en filtros de búsqueda LDAP sin escapar, permitiendo a atacantes manipular queries de directorio, bypassear autenticación o extraer datos sensibles del directorio.

Parsers XML configurados para procesar referencias a entidades externas, permitiendo a atacantes leer archivos arbitrarios del servidor o disparar SSRF con un payload XML malicioso.

Input controlado por el usuario incluido en headers de respuesta HTTP sin sanitizar, permitiendo a atacantes inyectar headers arbitrarios o dividir la respuesta en dos respuestas HTTP separadas.

Input del usuario sin sanitizar usado en los campos To, From, CC o Subject del email, permitiendo a atacantes inyectar destinatarios adicionales y convertir tu servidor de email en un relay de spam.

Input provisto por el usuario escrito en logs sin sanitizar, permitiendo a atacantes falsificar entradas de log, ocultar sus huellas o inyectar contenido malicioso en archivos de log.

Input del usuario pasado directamente a la función de renderizado de un motor de templates, permitiendo a atacantes ejecutar código arbitrario en el servidor inyectando sintaxis de template.

El servidor reutiliza el mismo ID de sesión antes y después del login, permitiendo a un atacante que plantó un ID de sesión conocido secuestrar la sesión autenticada.

Endpoints de login sin rate limiting ni mecanismo de bloqueo, permitiendo a atacantes probar combinaciones ilimitadas de usuario y contraseña hasta encontrar credenciales válidas.

Sin requisitos de longitud mínima, complejidad o verificación contra contraseñas comunes en el registro o cambio de contraseña, haciendo las cuentas fácilmente vulnerables a fuerza bruta.

Flujo de autorización OAuth implementado sin un parámetro `state` aleatorio, permitiendo ataques CSRF que vinculan la cuenta de una víctima con la identidad OAuth del atacante.

Tokens JWT o de sesión que siguen siendo válidos después de que un usuario hace logout porque no hay mecanismo de revocación server-side, permitiendo que tokens robados se usen indefinidamente.

Las sesiones activas siguen siendo válidas después de que un usuario cambia su contraseña, dejando a los atacantes que ya comprometieron una sesión con acceso continuo incluso después de que el usuario toma acción.

Tokens persistentes de 'recuérdame' que son predecibles, no expiran o se guardan de forma insegura — permitiendo a atacantes falsificar tokens o mantener acceso indefinido.

Tokens de reset de contraseña sin expiración, sin enforcing de uso único o sin aleatoriedad adecuada — permitiendo a atacantes usar links filtrados o predecibles para tomar control de cuentas.

Endpoints de login o reset de contraseña que devuelven mensajes de error diferentes para 'email no encontrado' vs 'contraseña incorrecta', permitiendo a atacantes confirmar qué direcciones de email están registradas.

Scripts maliciosos ejecutados al leer datos controlados por el atacante de la URL o APIs del navegador y escribirlos en el DOM usando sinks peligrosos como innerHTML o document.write.

Contenido provisto por el usuario guardado en la base de datos sin sanitizar y renderizado en el navegador como HTML, permitiendo inyección de scripts persistente que se ejecuta para cada usuario que ve el contenido.

Handlers de window.addEventListener('message') que procesan mensajes sin verificar event.origin, permitiendo que cualquier sitio web envíe comandos al handler de mensajes de tu app.

Ausencia de los headers X-Frame-Options y CSP frame-ancestors, combinada con sin lógica de frame-busting en el cliente, dejando la app completamente embebible en iframes maliciosos.

Contenido de terceros o generado por el usuario cargado en un iframe sin el atributo sandbox, permitiendo que ese contenido ejecute scripts, acceda a cookies del padre y navegue el frame de nivel superior.

Scripts y hojas de estilo alojados en CDN cargados sin el atributo integrity, lo que significa que un CDN comprometido puede servir versiones maliciosas de tus dependencias a todos tus usuarios.

JavaScript que redirige usuarios a URLs tomadas de parámetros de query o fragmentos URL sin validación, habilitando ataques de phishing usando tu dominio confiable como lanzadera.

Tokens, contraseñas o identificadores sensibles pasados como parámetros de query en URL, donde son visibles en el historial del navegador, logs del servidor, headers Referer y links compartidos.

Swagger UI, ReDoc u otras interfaces de documentación de API accesibles públicamente en producción, dándole a los atacantes un mapa interactivo gratuito de cada endpoint, parámetro y método de autenticación.

La introspección de GraphQL permanece habilitada en producción, permitiendo que cualquiera consulte el schema completo y descubra todos los tipos, campos, mutations y sus estructuras de argumentos.

API GraphQL sin límite de profundidad en queries anidadas, permitiendo a los atacantes crear queries profundamente anidadas que agotan los recursos del servidor y causan denegación de servicio.

Endpoints GraphQL que aceptan arrays de operaciones sin límites de tamaño, permitiendo a los atacantes bypassear el rate limiting agrupando miles de requests en una sola llamada HTTP.

Endpoints de API que devuelven objetos completos de la base de datos con campos sensibles en lugar de solo los campos que el cliente realmente necesita, exponiendo hashes de contraseñas, IDs internos, flags de admin y otros datos sensibles.

Endpoints de API que devuelven todos los registros coincidentes sin paginación ni límite, permitiendo a los atacantes volcar tablas completas y causando problemas de memoria/rendimiento bajo carga normal.

Usar API keys de admin o acceso completo para operaciones que solo requieren acceso de lectura, lo que significa que una key comprometida le da a los atacantes mucho más acceso del necesario.

URLs de conexion a base de datos con usuario y password hardcodeadas en el codigo fuente, dejando las credenciales accesibles a cualquiera con acceso al repositorio.

Archivos de dump de base de datos (.sql, .dump, .bak) commiteados al repositorio exponen el esquema completo y datos, incluyendo credenciales de usuarios y registros sensibles.

Usar metodos de SQL crudo como $queryRaw de Prisma o query() de Sequelize con interpolacion de strings bypasea la proteccion contra SQL injection del ORM.

Deserializar datos no confiables con librerias como node-serialize o yaml.load de Python permite a los atacantes ejecutar codigo arbitrario en el servidor.

La expansion de relaciones sin limites en queries de ORM permite a los atacantes disparar miles de queries a la base de datos con un solo request de API, causando denegacion de servicio.

Rutas de archivos construidas con input de usuario sin validar permiten a los atacantes leer o escribir archivos arbitrarios en el servidor usando secuencias ../.

Aceptar cargas de archivos sin verificar tipo, tamano o contenido permite a los atacantes subir ejecutables maliciosos, web shells o archivos sobredimensionados que crashean el servidor.

Aceptar cargas de SVG sin sanitizacion permite a los atacantes embeber JavaScript en archivos SVG, habilitando ataques XSS cuando el SVG se renderiza en un navegador.

Imagenes servidas sin eliminar metadatos EXIF pueden filtrar coordenadas GPS, informacion del dispositivo, timestamps y otros datos sensibles de la persona que tomo la foto.

Inyectar HTML o JavaScript en templates de generacion de PDF permite a los atacantes leer archivos del servidor, hacer requests a la red interna o ejecutar scripts en el visor de PDF.

Extraer archivos ZIP sin validar las rutas permite a los atacantes crear archivos que escriben fuera del directorio destino, sobrescribiendo archivos criticos de la aplicacion.

Validar el tipo de archivo solo por extension en vez de contenido permite a los atacantes subir archivos maliciosos con extensiones renombradas, bypasseando controles de seguridad.

Operaciones de lectura-modificacion-escritura en pagos sin transacciones de base de datos permiten a los atacantes explotar ventanas de tiempo y gastar el mismo saldo multiples veces.

Aceptar precios del cliente en vez de buscarlos del lado del servidor permite a los atacantes modificar requests de checkout y comprar productos al precio que elijan.

Feature flags incluidos en el bundle de JavaScript del frontend revelan funciones no lanzadas, configuraciones internas de testing y superficies de ataque potenciales a cualquiera que inspeccione el codigo.

Rutas de desarrollo y testing como /debug, /test, /seed o /api/dev dejadas activas en produccion exponen datos internos, bypassean autenticacion o permiten manipulacion de estado.

Endpoints de actualizacion de perfil que aceptan campos de rol o permisos del body del request permiten a los usuarios promoverse a admin agregando role: 'admin' a su request de actualizacion.

Usar comparacion de strings estandar (=== o ==) para secretos como API keys o tokens permite a los atacantes adivinar valores caracter por caracter midiendo diferencias en el tiempo de respuesta.

Redirigir usuarios a URLs de parametros de query sin validar permite a los atacantes crear links de phishing que parecen venir de tu dominio de confianza.

Pasar el body del request completo directamente a operaciones de creacion o actualizacion de base de datos permite a los atacantes establecer cualquier campo, incluyendo internos como verified, credits o estado de facturacion.

Usar modo ECB (Electronic Codebook) para encriptacion produce bloques de texto cifrado identicos para bloques de texto plano identicos, revelando patrones en los datos encriptados.

Usar un Vector de Inicializacion (IV) o nonce hardcodeado o constante para encriptacion anula el proposito del IV y permite a los atacantes detectar patrones y desencriptar datos.

Usar llaves criptograficas mas cortas que los minimos recomendados (RSA menor a 2048 bits, AES menor a 128 bits) hace la encriptacion vulnerable a ataques de fuerza bruta con hardware moderno.

Deshabilitar la validacion de certificados TLS con NODE_TLS_REJECT_UNAUTHORIZED=0 o rejectUnauthorized: false permite ataques man-in-the-middle en todas las conexiones HTTPS.

Usar Math.random() o Date.now() para generar tokens, IDs de sesion o codigos de reset produce valores predecibles que los atacantes pueden adivinar o reproducir.

Aceptar 'none' como algoritmo válido en JWT permite que cualquiera forge tokens sin necesitar el secret.

Poner claves de cifrado como strings en el código significa que cualquiera con acceso al repo puede descifrar tus datos.

Hacer merge de objetos controlados por el usuario sin filtrar permite que atacantes modifiquen Object.prototype y afecten todos los objetos de la app.

Las expresiones regulares con cuantificadores anidados pueden tomar tiempo exponencial con ciertos inputs, congelando el event loop de Node.js.

Usar Math.random() para valores sensibles como tokens o IDs es predecible y puede romperse por fuerza bruta.

Un service worker registrado sin restricciones de scope puede interceptar todas las requests de red de un dominio, incluyendo las de otras páginas.

Las funciones serverless sin timeout configurado pueden mantenerse corriendo indefinidamente con requests maliciosas, drenando tu presupuesto.

Darle a funciones serverless o servicios más permisos IAM de los necesarios convierte una brecha menor en un compromiso total de la cuenta.

Loguear process.env vuelca todos tus secrets — API keys, contraseñas de base de datos, claves de firma — directamente en tu sistema de logs.

Las funciones serverless reutilizan entornos de ejecución entre invocaciones, por lo que archivos sensibles escritos en /tmp pueden ser leídos por requests posteriores de otros usuarios.

Las variables globales en funciones serverless persisten entre invocaciones en el mismo entorno de ejecución, filtrando datos de usuarios entre requests.

Instalar un paquete con un nombre que difiere por un caracter de una librería popular puede instalar malware en vez del paquete real.

Las dependencias que no han sido actualizadas en 2+ años no recibirán parches de seguridad cuando se descubran nuevas vulnerabilidades.

Los scripts postinstall de npm se ejecutan automáticamente con los permisos de tu sistema durante npm install, convirtiéndolos en un vector común de malware.

Los paquetes internos privados sin prefijo de scope pueden ser hijackeados publicando un paquete público con el mismo nombre pero mayor versión.

Sin un lockfile, npm install resuelve la versión compatible más reciente de cada dependencia — lo que puede introducir un paquete comprometido en tu próximo deploy.

Los esquemas de URL personalizados sin verificación de host permiten que apps maliciosas intercepten los deep links de tu app y roben tokens OAuth o parámetros sensibles.

Los datos sensibles copiados al portapapeles (contraseñas, tokens, números de tarjeta) persisten ahí indefinidamente y pueden ser leídos por cualquier app.

Las pantallas bancarias y de pago sin protección contra capturas permiten que datos sensibles sean capturados por malware o aparezcan en la pantalla de apps recientes de Android.

Sin certificate pinning, los atacantes en la misma red pueden interceptar el tráfico HTTPS de tu app con una autoridad de certificación falsa.

Ejecutar una app financiera o de salud en un dispositivo rooteado o con jailbreak significa que todos los controles de seguridad pueden ser eludidos por el dueño del dispositivo.

La autenticación biométrica que solo corre del lado del cliente puede ser eludida parcheando el binario de la app — el servidor debe validar la sesión de forma independiente.

Los contenedores que corren como root dan a cualquier vulnerabilidad de ejecución de código acceso root inmediato al contenedor — y potencialmente al host.

Usar FROM image:latest significa que un nuevo pull puede cambiar silenciosamente tu imagen base, rompiendo la reproducibilidad y potencialmente introduciendo vulnerabilidades.

Los secrets agregados via ENV, ARG o COPY .env en un Dockerfile quedan grabados en las capas de la imagen y son legibles por cualquiera que descargue la imagen.

Hacer EXPOSE de puertos que tu aplicación no usa realmente aumenta la superficie de ataque sin ningún beneficio.

Sin una instrucción HEALTHCHECK, Docker y los orquestadores no pueden detectar cuando tu contenedor está corriendo pero roto — enrutando tráfico a una app muerta.

Sin registros DNS SPF, DKIM y DMARC, cualquiera puede enviar emails fingiendo ser de tu dominio — habilitando ataques de phishing contra tus usuarios.

Incluir input del usuario sin validar en mensajes SMS permite a los atacantes inyectar saltos de línea y crear mensajes fraudulentos que parecen venir de tu aplicación.

Incluir input del usuario sin sanitizar en payloads de notificaciones push permite a los atacantes crear notificaciones engañosas a nombre de tu app.

Aceptar cualquier contraseña — incluyendo '123' o 'a' — hace las cuentas de usuarios trivialmente vulnerables a credential stuffing y ataques de fuerza bruta.

Un endpoint de login sin rate limiting puede ser forzado por fuerza bruta miles de veces por segundo hasta encontrar una contraseña válida.

Sin autenticación multifactor, una contraseña robada o adivinada es todo lo que se necesita para comprometer completamente una cuenta.

Permitir cuentas con email no verificado deja que atacantes se registren con la dirección de email de otra persona, potencialmente bloqueándolos o suplantándolos.

Los links de reset de contraseña que nunca expiran permanecen válidos indefinidamente — un email antiguo en una brecha le da a los atacantes una ruta permanente para tomar control de la cuenta.

No ofrecer una opción de 'cerrar sesión en todos los dispositivos' deja sesiones activas en dispositivos robados u olvidados indefinidamente.

No notificar a los usuarios de nuevos inicios de sesión significa que no tienen forma de saber si su cuenta fue accedida desde un dispositivo desconocido.

Sin retroalimentación en tiempo real sobre la fortaleza de la contraseña, los usuarios optan por contraseñas débiles que ya conocen — incluso cuando se requiere complejidad.

Las acciones destructivas o irreversibles (eliminar cuenta, transferir fondos, cambiar email) sin un paso de confirmación son vulnerables a CSRF y clics accidentales.

Sin un archivo .env.example, los nuevos colaboradores no saben qué variables de entorno se requieren, lo que lleva a soluciones inseguras como hardcodear valores.

Sin reglas de ESLint orientadas a seguridad, vulnerabilidades comunes como sinks XSS, dangerouslySetInnerHTML y uso de eval() pasan desapercibidas en code review.

Sin hooks de pre-commit que escaneen en busca de secrets y problemas de seguridad, los desarrolladores pueden accidentalmente pushear API keys y contraseñas al repositorio.

Un .gitignore que no cubre archivos .env, artefactos de build y configuraciones de IDE puede llevar a que secrets o datos sensibles sean accidentalmente commiteados.

Los npm scripts que obtienen y ejecutan código remoto, o que incrustan secrets como argumentos de shell, son un riesgo de supply chain y exposición de credenciales.

Un proyecto sin un lockfile commiteado puede instalar diferentes versiones de dependencias en cada máquina, haciendo builds no reproducibles y ataques de supply chain más difíciles de detectar.

Los archivos de prueba con direcciones de email reales, números de teléfono o credenciales que parecen de producción pueden filtrar PII y crear confusión de seguridad.

Loguear contraseñas, tokens, objetos de usuario completos o datos de pago a la consola envía esos datos a tu agregador de logs en texto plano.

Retornar stack traces o detalles de errores internos en respuestas de API revela tu estructura de archivos, versiones de librerías y rutas de código a los atacantes.

Sin error boundaries, un error de JavaScript en cualquier componente crashea todo el árbol de React y muestra una pantalla en blanco al usuario.

No loguear eventos de seguridad (logins fallidos, denegaciones de permisos, acciones sospechosas) significa que no puedes detectar ataques en curso ni reconstruir lo que pasó después de una brecha.

Loguear información personal identificable (email, nombre completo, IP, teléfono) crea riesgos de privacidad y cumplimiento bajo GDPR y CCPA.

Correr Node.js sin NODE_ENV=production habilita mensajes de error detallados, deshabilita optimizaciones de caché y puede activar middleware solo para desarrollo.

El modo debug habilitado en producción expone estado interno, habilita logging detallado y a veces activa endpoints de debugging interactivos que los atacantes pueden explotar.

Sin un endpoint /health, los load balancers y orquestadores no pueden verificar que tu aplicación realmente funciona antes de enrutar tráfico hacia ella.

Sin monitoreo de errores, los errores de producción son invisibles hasta que un usuario los reporta — lo cual la mayoría nunca hace.

Usar credenciales de desarrollo (API keys de prueba, URLs de base de datos local, keys de pago sandbox) en producción pone en riesgo a usuarios reales.

Sin respaldos regulares y probados, un ataque de ransomware, eliminación accidental o corrupción de base de datos puede resultar en pérdida permanente de datos.

Las sesiones que nunca expiran permanecen válidas indefinidamente, dándole a los atacantes tiempo ilimitado para usar tokens robados.

Operar sin una política de privacidad viola GDPR, CCPA y regulaciones similares — y hace que los usuarios desconfíen justificadamente del manejo de sus datos.

Sin términos de servicio, no tienes base legal para restringir el abuso, terminar cuentas o limitar tu responsabilidad por contenido generado por usuarios.

No ofrecer eliminación de cuenta viola el derecho de supresión del GDPR y el derecho a eliminar del CCPA — y es una señal de alerta de privacidad significativa para los usuarios.

Establecer cookies no esenciales sin consentimiento del usuario viola los requisitos del GDPR y la Directiva ePrivacy para usuarios de la UE.

Guardar números de tarjeta completos, CVVs o PANs en localStorage, sessionStorage o tu propia base de datos viola PCI DSS y crea una responsabilidad masiva.

Ejecutar tracking de usuarios, fingerprinting o analytics de comportamiento sin consentimiento explícito viola GDPR, CCPA y leyes de privacidad similares.

Recopilar más datos personales de los necesarios viola el principio de minimización de datos del GDPR y aumenta tu responsabilidad cuando ocurre una brecha.

No mostrar a los usuarios la última actividad de su cuenta dificulta que detecten accesos no autorizados.

Enviar contraseñas, tokens completos, detalles de tarjetas o datos personales excesivos por email expone esos datos a proveedores de email, destinatarios que reenvían y cualquiera con acceso a la bandeja de entrada.

Los endpoints de email y SMS sin rate limiting pueden ser abusados para enviar spam a usuarios o agotar tu presupuesto de envío mediante requests automatizadas.

Los payloads de notificaciones push son visibles en la pantalla de bloqueo y logueados por los servicios de notificaciones — no incluyas números de cuenta, saldos o identificadores personales.

Los endpoints de carga de archivos sin límites de tamaño permiten a los atacantes agotar el espacio en disco, la memoria y la CPU con cargas de múltiples gigabytes.

Los endpoints de API JSON sin límite de tamaño del body pueden ser víctimas de DoS enviando payloads JSON enormes que agotan la memoria del servidor durante el parseo.

Sin rate limiting global a nivel de edge o middleware, cualquier endpoint puede ser inundado con requests hasta que el servidor se desborde.

Las requests HTTP sin timeouts del lado del servidor permiten que clientes lentos o ataques slow-body mantengan conexiones del servidor abiertas indefinidamente.

Los endpoints WebSocket que aceptan conexiones sin verificar autenticación permiten que usuarios no autenticados reciban flujos de datos en tiempo real destinados a usuarios autenticados.

El input del usuario se concatena directo en el prompt del LLM, permitiendo que atacantes sobreescriban tus instrucciones y hagan que la IA haga lo que ellos quieran.

Tu app manda información personal identificable — emails, nombres, contraseñas, teléfonos — a APIs de IA externas, exponiendo datos de usuarios a proveedores de modelos de terceros.

El output de un LLM se renderiza o ejecuta directo sin verificar si coincide con el formato esperado o contiene contenido dañino.

Tu API key de OpenAI, Anthropic u otro proveedor de IA está expuesta en el código del cliente, donde cualquiera puede robarla y acumular cargos en tu cuenta.

El HTML o código generado por un LLM se renderiza directo en la UI sin sanitización, abriendo la puerta a ataques de XSS almacenado.

Tu app manda registros completos de base de datos, archivos de configuración o secretos como contexto a un modelo de IA, exponiendo mucho más datos de los que la tarea requiere.

Cuando el modelo de IA principal falla, tu app hace fallback silenciosamente a un modelo más débil o sin validar que evita tus configuraciones de seguridad.

Tu app hace llamadas a APIs de IA sin límites por usuario, dejando que un solo usuario (o bot) dispare miles de requests y agote tu presupuesto de API en minutos.

Tu app usa eval() o Function() para ejecutar código generado por un LLM, dando a los atacantes un camino hacia ejecución arbitraria de código vía inyección de prompts.

Tu conexión a la base de datos no usa SSL/TLS, lo que significa que todas las consultas y resultados viajan por la red en texto plano y pueden ser interceptados.

Tu base de datos está vinculada a 0.0.0.0 o expuesta en una IP pública sin VPC o firewall, haciéndola directamente accesible desde internet.

Tu base de datos usa credenciales predeterminadas de fábrica como postgres:postgres, root:root o admin:admin — lo primero que prueba cualquier atacante.

Una cadena de conexión a base de datos con contraseña en texto plano está hardcodeada en tu código fuente, comprometiendo tus credenciales de base de datos en el control de versiones.

Tu conexión a MongoDB no tiene credenciales de autenticación, permitiendo que cualquiera que pueda alcanzar el puerto de la base de datos lea, modifique o borre todos los datos.

Tu instancia de Redis no tiene contraseña y es accesible más allá de localhost, permitiendo que cualquiera que pueda alcanzarla lea todos los datos en caché, tokens de sesión y contenidos de colas.

Tu instancia de Elasticsearch es accesible desde internet sin autenticación, exponiendo todos los datos indexados a cualquiera que conozca la URL del endpoint.

Tu pool de conexiones a base de datos no tiene límite máximo de conexiones, lo que significa que un pico de tráfico o una consulta lenta puede agotar todas las conexiones disponibles y tumbar tu app.

Tu conexión a base de datos no tiene timeout configurado, así que una base de datos lenta o sin respuesta dejará tu aplicación entera colgada indefinidamente en lugar de fallar rápido.

Tu DATABASE_URL o contraseña de base de datos se imprime en los logs de la aplicación vía console.log o mensajes de error, exponiendo credenciales a cualquiera con acceso a los logs.

Tu conexión SSL a la base de datos usa rejectUnauthorized: false, que cifra el tráfico pero no verifica la identidad del servidor, dejándote expuesto a ataques de hombre en el medio.

El hostname y puerto de tu base de datos están hardcodeados en el código fuente en lugar de variables de entorno, exponiendo la topología de tu infraestructura y haciendo los despliegues inflexibles.

Tu bucket de S3 es públicamente legible debido a un ACL público, configuración de Block Public Access deshabilitada o una política de bucket con wildcard — cualquiera en internet puede listar y descargar tus archivos.

Tu app hace fetch de URLs proporcionadas por el usuario sin bloquear endpoints de metadata de cloud como 169.254.169.254, dejando a los atacantes robar tus credenciales cloud vía SSRF.

Las claves de acceso de AWS (que empiezan con AKIA) o las claves de acceso secretas están hardcodeadas en tu código fuente, dando a cualquiera que lea el código acceso completo a tu cuenta de AWS.

Tu política IAM usa Action: '*' o Resource: '*', otorgando muchos más permisos de los necesarios y convirtiendo cualquier fuga de credenciales en una toma de control completa de la cuenta.

Tu bucket de S3 o GCS tiene CORS configurado con origin: '*' o AllowedMethods: ['*'], permitiendo que cualquier sitio web lea las respuestas de tu almacenamiento y potencialmente acceda a datos privados.

Tu Lambda o Cloud Function permite invocación sin autenticación, lo que significa que cualquiera en internet puede dispararla sin credenciales.

Tu bucket de S3 o GCS no tiene cifrado del lado del servidor habilitado, lo que significa que los datos se almacenan en texto plano en la infraestructura de AWS/Google.

Tus claves de cifrado KMS no tienen rotación automática habilitada, lo que significa que el mismo material de clave se usa indefinidamente — aumentando el riesgo si la clave alguna vez es comprometida.

Tu política de confianza IAM usa un principal wildcard o permite que cuentas AWS desconocidas asuman tus roles, dejando que cuentas externas accedan a tus recursos.

Tu app loguea PII, tokens o credenciales en CloudWatch, Stackdriver u otros servicios de logging cloud, donde persisten indefinidamente y son accesibles para cualquiera con permisos de lectura de logs.

Tus recursos cloud están desplegados sin una VPC o con security groups que permiten tráfico entrante sin restricciones (0.0.0.0/0), exponiendo servicios internos a internet.

Tus recursos cloud carecen de etiquetas de entorno, propietario o centro de costos, haciendo imposible rastrear la propiedad, asignar costos o identificar rápidamente recursos durante un incidente.

Tu archivo terraform.tfstate está commiteado en tu repositorio o almacenado en un lugar sin cifrar y públicamente accesible — contiene cada secreto e ID de recurso en tu infraestructura.

Las credenciales de AWS, GCP o Azure están hardcodeadas en tus archivos .tf en lugar de usar variables de entorno o roles de instancia, commiteando claves de acceso cloud al control de versiones.

Tu pod de Kubernetes corre con securityContext.privileged: true, dándole al contenedor acceso completo al kernel del host y efectivamente evitando el aislamiento del contenedor.

Los pods que corren con la cuenta de servicio predeterminada heredan permisos RBAC a nivel de cluster que generalmente son mucho mas amplios de lo que el workload necesita, permitiendo movimiento lateral si el pod es comprometido.

Contrasenas, API keys y otros secretos estan hardcodeados directamente en archivos values.yaml de Helm, que se commitean al control de versiones y quedan expuestos a cualquiera con acceso al repositorio.

Sin recursos NetworkPolicy, cada pod en el cluster puede comunicarse con todos los demas pods en cualquier puerto, habilitando movimiento lateral sin restricciones despues de que un solo pod sea comprometido.

Los Secrets de Kubernetes se almacenan como texto plano codificado en base64 en etcd por defecto, lo que significa que cualquiera con acceso al datastore etcd o sus respaldos puede leer todos los secretos del cluster.

Sin ejecutar terraform plan en CI o una herramienta de deteccion de drift, los cambios manuales a recursos cloud pasan desapercibidos, creando brechas de seguridad entre tu infraestructura declarada y lo que realmente corre en produccion.

Usar GitHub Actions referenciados por tags mutables como @main o @v3 en lugar de SHAs de commit completos significa que una action comprometida o secuestrada puede inyectar codigo malicioso en tu pipeline CI sin ningun cambio en tu archivo workflow.

Usar datos de eventos no confiables como github.event.issue.title directamente dentro de bloques run: permite a los atacantes inyectar comandos shell arbitrarios en tu pipeline CI creando titulos de issues, cuerpos de PR o mensajes de commit maliciosos.

Imprimir o hacer echo de variables de entorno que contienen secretos en scripts de CI los expone en los logs de build, que frecuentemente son accesibles para todos los colaboradores del repositorio y a veces visibles publicamente en proyectos open-source.

Usar runners self-hosted de GitHub Actions con pull_request_target o workflows de forks publicos permite que codigo no confiable de contribuidores externos se ejecute en tu infraestructura con acceso a secrets, estado persistido y la red del host.

Los workflows de GitHub Actions con permissions: write-all o sin bloque de permissions explicito otorgan al GITHUB_TOKEN acceso excesivo, permitiendo que un paso comprometido modifique codigo, cree releases, escriba paquetes o cambie configuraciones del repositorio.

Sin proteccion de rama en main/produccion, cualquier desarrollador (o cuenta comprometida) puede pushear directamente, hacer force-push con cambios destructivos o mergear sin revision de codigo, saltandose todas las validaciones de calidad y seguridad.

Un pipeline CI/CD que solo ejecuta tests y linting sin ningun SAST, DAST, escaneo de dependencias o deteccion de secretos significa que las vulnerabilidades solo se encuentran despues del despliegue -- si es que se encuentran.

Los artefactos de build (binarios, imagenes de contenedor, paquetes) producidos sin firmas criptograficas o atestaciones de procedencia pueden ser reemplazados silenciosamente por un atacante entre el build CI y el despliegue, resultando en compromiso de la cadena de suministro.

Un servidor WebSocket que no verifica el header Origin acepta conexiones de cualquier sitio web, permitiendo Cross-Site WebSocket Hijacking donde una pagina maliciosa se conecta a tu endpoint WS usando la sesion autenticada de la victima.

Un servidor WebSocket sin rate limiting de mensajes permite que un solo cliente envie miles de mensajes por segundo, agotando recursos del servidor, degradando el rendimiento para todos los usuarios y potencialmente causando denegacion de servicio.