Lista de verificación de seguridad de Claude Code para comprobaciones rápidas en aplicaciones web

Qué es una comprobación ligera de seguridad

Una comprobación ligera de seguridad es una revisión rápida (a menudo 30–60 minutos) pensada para detectar problemas obvios y de alto impacto antes de que se publiquen. No es una auditoría completa. Piénsalo como un recorrido de seguridad: repasas las rutas que fallan con más frecuencia en apps reales y buscas pruebas, no suposiciones.

Esta lista de verificación de seguridad de Claude Code se centra en las áreas que más se rompen en aplicaciones web cotidianas:

• Suposiciones de autenticación (cómo se sabe quién es el usuario)
• Brechas de autorización (qué se le permite hacer)
• Validación de entradas
• Manejo de secretos
• Superficies comunes de inyección (SQL, ejecución de comandos, renderizado de plantillas, redirecciones, uploads)

No pretende probar la ausencia de bugs, modelar actores de amenaza complejos ni sustituir pruebas de penetración.

“Hallazgos concretos” significa que cada problema que documentes tiene evidencia que un desarrollador puede usar de inmediato. Para cada hallazgo, captura:

• Los archivos y la(s) función(es)/handler exactos
• El comportamiento riesgoso en una frase
• Un paso mínimo de reproducción (petición, payload o ruta de clic)
• Por qué importa (impacto) y quién puede desencadenarlo
• Una dirección de arreglo segura (no una reescritura completa)

La IA es una ayuda, no una autoridad. Úsala para buscar, resumir y proponer pruebas. Luego verifica leyendo el código y, cuando sea posible, reproduciendo con una petición real. Si el modelo no puede señalar ubicaciones y pasos específicos, trata la afirmación como no probada.

Define el alcance en 10 minutos

Una revisión rápida solo funciona si delimitas el objetivo. Antes de pedirle a Claude Code que mire algo, decide qué intentas probar hoy y qué no vas a revisar.

Empieza con 1 a 3 recorridos de usuario reales donde los errores cuesten dinero, expongan datos o otorguen poder. Buenos candidatos son login, restablecimiento de contraseña, checkout y pantallas de edición de admin.

Luego nombra los activos que debes proteger. Sé específico: cuentas de usuario, acciones de pago, datos personales, operaciones solo para admin.

Después escribe tus supuestos de amenaza en palabras simples. ¿Te defiende contra un usuario curioso que hace clic, un atacante externo con scripts o un insider con cierto acceso? Tu respuesta cambia qué significa “suficiente”.

Finalmente, define criterios de aprobado y fallado para que la comprobación termine con hallazgos, no impresiones. Reglas simples funcionan bien:

• Aprobado: cada acción sensible muestra una verificación explícita de authn y authz.
• Fallado: cualquier endpoint confía en el cliente para el ID o rol de usuario.
• Aprobado: las entradas se validan en el servidor, no solo en la UI.
• Fallado: secretos aparecen en logs, configs o código cliente.

Si no puedes describir cómo se ve un fallo, el alcance sigue siendo demasiado vago.

Prepara el contexto que le das a Claude Code

Una comprobación solo funciona si el modelo mira en los lugares correctos. Reúne un pequeño paquete de código y notas para que la revisión produzca evidencia, no suposiciones.

Empieza compartiendo la ruta crítica de seguridad: puntos de entrada de la petición y el código que decide quién es el usuario y qué puede hacer. Incluye el código suficiente alrededor para mostrar cómo fluye la información.

Un paquete práctico suele incluir:

• Entrada de auth: parsing de session/JWT, ajustes de cookies, callbacks de login, middleware de auth
• Rutas + handlers: controladores, métodos RPC, resolvers GraphQL, handlers de jobs en background
• Capa de datos: consultas ORM, helpers SQL crudos, constructores de consultas, migraciones para tablas sensibles
• Chequeos de políticas: comprobaciones de rol, verificación de propiedad, feature flags, endpoints solo admin
• Validación: validadores de esquema de petición, handlers de subida de archivos, código de deserialización

Agrega unas líneas de notas de entorno para dejar explícitos los supuestos: sesión vs JWT, dónde viven los tokens (cookie o header), comportamiento del reverse proxy o API gateway, workers/colas/cron y cualquier endpoint “solo interno”.

Antes de buscar bugs, pide un inventario: puntos de entrada, endpoints privilegiados y almacenes de datos tocados. Esto evita superficies olvidadas.

También acuerda un formato de salida que obligue a hallazgos concretos. Una tabla simple funciona bien: Hallazgo, Severidad, Endpoint/archivo afectado, Evidencia (fragmento exacto o rango de líneas), Escenario de explotación, Sugerencia de arreglo.

Flujo paso a paso para una revisión de 30–60 minutos

Cronometra:

• 10 minutos para orientarte
• 15–30 minutos para rastrear flujos
• 10 minutos para documentar

El objetivo no es cobertura perfecta. Es un pequeño conjunto de hallazgos comprobables.

Mantén la app abierta mientras lees. Haz clic en la UI y observa qué peticiones se disparan. Las notas deben apuntar a endpoints específicos, parámetros y fuentes de datos.

Un flujo que cabe en una sola sesión:

1. Esboza puntos de entrada y límites de confianza. Anota rutas públicas, rutas autenticadas, rutas admin, webhooks, uploads y callbacks de terceros. Marca dónde los datos pasan de controlado por el usuario a confiado por el servidor.
2. Para cada endpoint importante, anota qué prueba identidad y dónde ocurre. Si la comprobación es “middleware”, confirma que cada ruta lo use realmente.
3. Haz lo mismo para la autorización. Elige una acción riesgosa (ver datos de otros usuarios, cambiar roles, exportar, borrar) y traza la decisión de permiso hasta la consulta a la base de datos.
4. Traza la entrada del usuario hasta los sinks. Sigue un parámetro desde la petición hasta consultas SQL/ORM, renderizado de plantillas, ejecución de comandos, fetch de URLs (SSRF), redirecciones y rutas de archivos.
5. Escanea secretos y configuraciones mientras trazas. Busca tokens en logs, código cliente, mensajes de error y volcados de entorno.

Un hábito útil: por cada “parece bien”, escribe cómo lo romperías. Si no puedes describir un intento de ruptura, probablemente no lo verificaste.

Comprobaciones de authn: prueba quién es el usuario

La autenticación es donde la app decide “esta petición pertenece a esta persona”. Una comprobación rápida no consiste en leer cada línea. Se trata de encontrar el lugar donde se establece la identidad y luego revisar atajos y caminos de fallo.

Localiza el límite de confianza: ¿dónde se crea o acepta la identidad por primera vez? Puede ser una cookie de sesión, un token JWT bearer, una API key o mTLS en el borde. Pide a Claude Code que señale el archivo y la función exactos que convierten “anónimo” en un id de usuario, y que liste cada otro camino que pueda hacer lo mismo.

Chequeos de authn que vale la pena escanear:

• Identifica todos los puntos de entrada de auth (login web, tokens API, auth móvil, auth de servicios internos) y confirma que convergen en un modelo de identidad consistente.
• Revisa login y restablecimiento de contraseña en busca de rate limits, bloqueos y enumeración de usuarios (mensajes de error o tiempos distintos para cuentas existentes vs no existentes).
• Inspecciona session y cookies: HttpOnly, Secure, SameSite, expiración, rotación al iniciar sesión o cambiar privilegios, y invalidación al cerrar sesión (server-side, no sólo “borrar cookie”).
• Revisa MFA y recuperación para que la ruta de recuperación no sea más débil que la MFA (por ejemplo, restablecimiento solo por email que elude la MFA).
• Revisa logs de fallos de auth: útiles para ops, pero que no filtren detalles que ayuden a atacantes (sin pistas “el usuario existe”, sin volcados de tokens).

Un ejemplo práctico: si los emails de restablecimiento devuelven “cuenta no encontrada”, eso es un problema rápido de enumeración. Incluso con un mensaje genérico, diferencias en el tiempo de respuesta pueden filtrar lo mismo, así que revisa tiempos también.

Comprobaciones de authz: prueba que el usuario tiene permiso

La autorización es la pregunta que causa más daño cuando falla: “¿Puede este usuario hacer esta acción sobre este recurso exacto?” Una comprobación rápida debe intentar romper esa suposición a propósito.

Escribe roles y permisos en lenguaje llano. Manténlo humano:

• El propietario puede invitar miembros
• El miembro puede editar su propio perfil
• Soporte puede ver detalles de facturación pero no cambiar el plan
• Admin puede borrar proyectos

Luego verifica que cada acción sensible aplique authz en el servidor, no solo en la UI. Los botones pueden estar ocultos, las rutas bloqueadas en el cliente, pero un atacante puede llamar la API directamente.

Un escaneo rápido que suele encontrar problemas reales:

• Encuentra endpoints/mutations que crean, borran, exportan, cambian roles o acceden a facturación
• Para cada uno, localiza la comprobación de permisos del lado servidor (no del frontend)
• Busca IDs controlados por el usuario (projectId, userId, orgId) y confirma comprobaciones de propiedad
• Confirma que rutas solo-admin fallen cerradas cuando falta el rol
• Verifica límites entre tenants: orgId/accountId debe provenir del contexto de session, no solo de la entrada de la petición

El olor clásico de IDOR es sencillo: una petición como GET /projects/{id} donde {id} la controla el usuario y el servidor la carga sin verificar que pertenezca al usuario o tenant actual.

Un prompt que fuerza una respuesta real:

“Para este endpoint, muestra el código exacto que decide el acceso, y lista las condiciones específicas que permitirían que un usuario de otra orgId lo acceda. Si no hay, explica por qué con nombres de archivo y función.”

Validación de entradas: mantén los datos malos fuera desde el principio

La mayoría de los problemas rápidos en apps web empiezan por un hueco: la app acepta entradas que el desarrollador no esperaba. Trata “entrada” como cualquier cosa que un usuario u otro sistema pueda influenciar, aunque parezca inocua.

Empieza nombrando las entradas para el endpoint que estás revisando:

• Valores de query y path de la URL
• Campos del body de la petición (incluyendo JSON anidado)
• Headers (auth headers, content type, forwarded IP)
• Cookies
• Subidas de archivos (nombre, tamaño, tipo, metadatos)

La validación debe ocurrir cerca de donde los datos entran en la app, no dentro de la lógica de negocio. Revisa lo básico: tipo (string vs número), longitud máxima, requerido vs opcional y formato (email, UUID, fecha).

Para valores conocidos como roles, campos de estado o direcciones de ordenación, prefiere una whitelist. Es más difícil de eludir que “bloquear algunos valores malos”.

También revisa el manejo de errores. Si la app rechaza una entrada, no reimprimas el valor crudo en la respuesta, logs o UI. Ahí es donde pequeños bugs de validación se convierten en fugas de datos o ayudas para inyección.

Un mini-plan de “entrada mala” para endpoints riesgosos (login, búsqueda, upload, acciones admin):

• Strings demasiado largas (10.000+ caracteres)
• Tipos incorrectos (array en lugar de string)
• Valores enum inesperados
• Caracteres especiales que pueden cambiar el significado
• Valores vacíos donde se requieren

Ejemplo: un parámetro de ordenación que acepta cualquier string puede convertirse en un fragmento SQL. Una whitelist como "date" o "price" evita esa clase de error temprano.

Superficies comunes de inyección para escanear rápido

La mayoría de las revisiones rápidas encuentran problemas en los mismos lugares: donde la entrada del usuario se interpreta como código, consulta, ruta o URL. Aquí cazas momentos en que “la entrada cruza un límite de confianza”.

Traza datos desde puntos de entrada (query params, headers, cookies, uploads, formularios de admin) hasta donde terminan.

Objetivos de escaneo rápido

Busca estos patrones y exige un sitio de llamada concreto y un ejemplo de payload para cada uno:

• SQL injection: consultas construidas por concatenación de strings, ORDER BY dinámico y constructores IN (...) que unen valores de usuario
• XSS: renderizado HTML, plantillas, previews de markdown y editores rich text donde se asume “sanitizar después”
• Command injection: llamadas a shell alrededor de procesamiento de imágenes, herramientas PDF, backups o pasos convert que reciben flags controlados por el usuario
• SSRF: fetchers de URL para webhooks, previews de enlaces, importar desde URL y checks internos de estado que aceptan una URL de usuario
• Traversal de rutas: endpoints de descarga de archivos, extracción de zip y pipelines de upload que luego leen archivos por nombre

También vigila deserialización e inyección en plantillas. Cualquier cosa que parsee JSON, YAML o strings con plantillas proporcionadas por el usuario puede esconder comportamiento riesgoso, sobre todo si soporta tipos personalizados, expresiones o renderizado del lado servidor.

Si una función acepta una URL, un nombre de archivo o texto formateado, asume que puede ser abusada hasta que pruebes lo contrario con rutas de código y tests.

Manejo de secretos: busca fugas y almacenamiento débil

Los problemas con secretos suelen ser ruidosos una vez que sabes dónde buscar. Concéntrate en dónde viven los secretos y dónde pueden copiarse accidentalmente.

Lugares comunes donde aparecen secretos:

• Variables de entorno y archivos de configuración de la app
• Salida de CI y logs de build (incluyendo logs de deploy fallidos)
• Bundles cliente y builds móviles (cualquier cosa enviada a usuarios)
• Endpoints de debug, páginas de health y herramientas admin
• Páginas de error, stack traces y eventos de analytics

Luego fuerza una respuesta concreta: si un secreto está expuesto hoy, ¿qué pasa después? Un buen sistema tiene un camino de rotación (se emite una clave nueva), revocación (se deshabilita la vieja) y forma de redeploy rápido. Si la respuesta es “lo cambiaríamos después”, trata eso como un hallazgo.

El principio de menor privilegio es otra mejora rápida. Los incidentes empeoran porque las claves tienen demasiado poder. Busca usuarios de BD que puedan dropear tablas, tokens de terceros que puedan gestionar cuentas o API keys compartidas entre entornos. Prefiere una clave por servicio, por entorno, con el conjunto mínimo de permisos.

Prompts rápidos para pegar en Claude Code:

• “Busca tokens hardcodeados, contraseñas y claves privadas. Lista las rutas de archivo exactas y los patrones de string que emparejaste.”
• “Encuentra código que loguea headers de petición, cookies, env vars u objetos de error completos. Muestra las líneas de log y qué campos sensibles podrían aparecer.”
• “Revisa si los secretos pueden acabar en snapshots, exports o artefactos de build. Identifica qué se captura y dónde se almacena.”

Finalmente, confirma guardarraíles: evita secretos en control de versiones (pre-commit/CI checks) y asegúrate de que backups o snapshots no incluyan credenciales en texto plano. Si la plataforma soporta snapshots y rollback, verifica que los secretos se inyecten en tiempo de ejecución, no se horneen en imágenes guardadas.

Prompts que obligan a hallazgos concretos (patrones para copiar/pegar)

Prompts vagos devuelven respuestas vagas. Obliga al modelo a comprometerse con evidencia: ubicaciones exactas, un rastro que puedas seguir, un repro que puedas ejecutar y qué haría que la afirmación fuera falsa.

Usa un patrón a la vez y pídeles que revisen tras que confirmes o rechaces un detalle.

• Evidencia a nivel de archivo: “Busca en el repo auth, sessions, tokens y middleware. Nombra los archivos exactos, funciones y rangos de líneas implicados. Cita los fragmentos relevantes. Si no puedes apuntar a código, di ‘no se encontró evidencia’.”
• Traza de entrada a sink: “Elige una entrada controlada por el usuario (header, query, body, cookie). Muestra el flujo de datos paso a paso desde el punto de entrada hasta dónde se usa (SQL, HTML, shell, plantilla, redirect, ruta de archivo). Lista cada función en la cadena.”
• Pasos de repro: “Da un repro mínimo con curl (método, forma de URL, headers, body). Incluye el código de estado esperado y un ejemplo de respuesta en caso de éxito/fallo. Indica supuestos (roles, estado de auth).”
• Control de falsos positivos: “¿Qué refutaría este hallazgo? Lista 2–3 comprobaciones: flags de config, orden de middleware, validación por whitelist, consultas parametrizadas, escaping del framework. Si alguna está presente, explica por qué cambia el riesgo.”
• Pequeño arreglo seguro + test: “Propón el cambio más pequeño que bloquee el problema sin romper casos válidos. Luego escribe un test para añadir (nombre, intención, inputs, resultado esperado). Si hay compensaciones, escríbelas.”

Si la salida sigue siendo difusa, acótala:

“Contesta solo con: ruta de archivo, nombre de función, línea riesgosa y un impacto en una frase.”

Un ejemplo realista: convertir una corazonada en un problema verificado

Los endpoints de actualización de perfil suelen esconder fallos de control de acceso. Aquí tienes un caso pequeño que puedes recorrer con esta lista.

Escenario: un endpoint API actualiza un perfil de usuario:

PATCH /api/profile?accountId=123 con JSON como { "displayName": "Sam" }.

Le pides a Claude Code que encuentre el handler, trace cómo se usa accountId y pruebe si el servidor aplica la propiedad.

Lo que suele aparecer:

• Authn: la petición requiere sesión o token, así que parece protegida.
• Authz: el handler confía en accountId de la query y actualiza esa cuenta sin comprobar que coincida con el usuario autenticado.
• Validación de entradas: displayName se recorta, pero accountId no se valida como entero.
• Superficie de inyección: el SQL se construye por concatenación como "... WHERE account_id=" + accountId.

Un buen informe es concreto:

• Severidad: Alta (IDOR + posible SQL injection)
• Evidencia: una petición con login válido modifica otra cuenta al cambiar accountId; el SQL se construye con entrada no fiable
• Arreglo: ignorar accountId del cliente, usar el id de cuenta autenticado en el servidor; parametrizar la consulta
• Test: intentar actualizar otra cuenta y esperar 403; rechazar accountId no numérico

Tras parchear, vuelve a chequear rápido:

• Intenta la misma petición con otro accountId y confirma que falla.
• Confirma que los logs muestran que el servidor usa el id autenticado, no el query param.
• Confirma que la consulta usa placeholders/params, no concatenación.
• Ejecuta una prueba negativa para input malformado (letras, número muy grande).

Trampas comunes que hacen que las comprobaciones rápidas fallen

La forma más rápida de perder una vulnerabilidad es confiar en lo que parece imponer la UI. Un botón oculto o deshabilitado no es una comprobación de permiso. Si el servidor acepta la petición, cualquiera puede reproducirla con otro ID de usuario, otro rol o una llamada API directa.

Otro fallo común es pedir algo vago. “Haz una revisión de seguridad” suele producir un informe genérico. Una comprobación necesita un alcance ajustado (qué endpoints, qué roles, qué datos) y un formato de salida estricto (nombre de archivo, función, línea riesgosa, repro mínimo).

La misma regla aplica a la salida de IA: no aceptes afirmaciones sin referencias. Si un hallazgo no incluye una ubicación de código concreta y una forma paso a paso de activarlo, trátalo como no probado.

Formas rápidas en que las comprobaciones se desvían

Estas trampas aparecen una y otra vez:

• Asumir “solo admin” porque es una página de admin, no porque el servidor lo haga cumplir
• Pedir resultados amplios en vez de “muéstrame la petición exacta que bypassa X”
• Aceptar “posible SQL injection” sin el punto de construcción de la consulta y la ruta de entrada
• Saltarse puntos de entrada menos obvios como webhooks, jobs programados, herramientas de importación y acciones admin internas
• Parchear síntomas (añadir un filtro o regex) mientras falta la validación raíz o la autorización centralizada

Si te sorprendes añadiendo más filtros tras cada nuevo caso límite, pausa. El arreglo suele estar antes y es más simple: valida en el borde y centraliza las comprobaciones de autorización para que cada camino de código las use.

Comprobaciones rápidas que puedes ejecutar antes de publicar

Esto no sustituye una revisión completa, pero captura errores que se cuelan cuando todos están cansados. Manténlas enfocadas en lo que puedes probar rápido: una petición que puedas enviar, una página que puedas cargar, una línea de log que puedas encontrar.

Cinco comprobaciones rápidas que suelen dar resultado:

• Fricción de authn: Intenta 10 logins malos seguidos. ¿Ves rate limits, bloqueos o al menos una ralentización? ¿Puedes deducir si un email existe por mensajes de error o por tiempos?
• Authz por intercambio de ID: Elige un recurso real (orden, factura, perfil). Cambia el ID en la URL, body JSON o variables GraphQL. ¿Recibes datos que no son tuyos, aunque solo sea metadata?
• Guardarraíles de entrada: Para campos clave (email, nombre, búsqueda, upload), intenta strings muy largos, Unicode raro y tipos inesperados (número en lugar de string). ¿Aplican límites de longitud y whitelists donde importan?
• Exposición de secretos: Busca en logs recientes y bundles cliente tokens, API keys, JWTs o Authorization: Bearer. Revisa páginas de error también. “Solo estaba en staging” suele convertirse en “se publicó”.
• Superficies de inyección: Busca concatenación de strings en SQL, filtros, renderizado de plantillas, comandos shell o URLs de redirección. Si la entrada alcanza uno de estos sin validación fuerte, asume riesgo hasta probar lo contrario.

Apunta las 3 mejores correcciones que puedes publicar esta semana, no una lista de deseos. Ejemplo: (1) añadir rate limiting a login y reset, (2) imponer comprobaciones de propiedad server-side en el endpoint “get by id”, (3) limitar longitud de entrada y rechazar caracteres inesperados en el campo de búsqueda.

Siguientes pasos: integra esta lista en tu proceso de build

Una comprobación solo paga si los resultados cambian lo que se publica. Trata esta lista como un paso pequeño y repetible de build, no una misión de rescate única.

Convierte cada hallazgo en un ítem de backlog que sea difícil de malinterpretar:

• Arreglo: qué cambiará en código o configuración
• Test: cómo probarás que está solucionado (una petición, un unit test, un paso de QA)
• Responsable: una sola persona accountable
• Fecha objetivo: la próxima release o un día específico
• Evidencia: archivo/endpoint y la petición o payload exacto que mostró el problema

Elige una cadencia que cuadre con tu riesgo y tamaño de equipo. Para muchos equipos, cada release es lo ideal. Si las releases son frecuentes, haz una revisión de 30–60 minutos mensual y una comprobación más corta antes de publicar.

Hazlo más fácil de repetir creando un paquete de prompts reutilizable y una plantilla de checklist. Mantén los prompts enfocados en salidas concretas: muestra la ruta, la protección, la petición que falla y el comportamiento esperado. Guarda el paquete donde tu equipo ya trabaje para que no se salte.

Si construyes apps a través de chat, integra la lista en la planificación. Añade una breve nota de “supuestos de seguridad” para authn/authz, entradas y secretos, y ejecuta la comprobación justo después de la primera versión funcional.

Plataformas como Koder.ai (koder.ai) pueden encajar bien con este hábito porque permiten iterar rápido manteniendo puntos de revisión. Usar snapshots y rollback alrededor de cambios riesgosos facilita publicar correcciones de seguridad sin quedar bloqueado cuando algo rompe comportamiento.