Especificación de Desarrollo Seguro de Sistemas / Secure System Development

Si el entorno de ejecución tiene una prohibición global de activos (prohibición de atacar/escanear ciertos activos propios), prevalecerá la configuración global; este skill no la anula. Si se necesita una plantilla general, consulte references/internal-policy.example.md (la versión publicada no contiene direcciones internas reales).

Modo de uso

Lea la «Lista de Líneas Rojas» antes de escribir código; verifique después de terminar. Lea la «Fase Uno» durante el diseño y la revisión. Cuando involucre un módulo específico, abra el archivo correspondiente en references/. Antes de enviar, ejecute la «Revisión Previa al Lanzamiento». Después del lanzamiento, consulte la sección «Tiempo de Ejecución y Día Cero».

Si una tarea involucra solo una parte (por ejemplo, escribir solo una interfaz de inicio de sesión o diseñar solo una tabla de pedidos), lea solo el capítulo correspondiente y la referencia correspondiente; no memorice todo.

Autoverificación Ejecutable (Se recomienda ejecutar primero)

python scripts/scan_redlines.py <directorio_objetivo> --format text            # Lectura humana
python scripts/scan_redlines.py <directorio_objetivo> --format sarif --fail-on high   # Bloqueo en CI
python scripts/scan_redlines.py <directorio_objetivo> --code-only              # Saltar documentación, solo escanear código

Biblioteca estándar de Python puro, sin necesidad de instalar dependencias. Cubre 18 categorías de reglas, incluyendo: concatenación SQL, innerHTML/eval, comodines CORS y reflexión, fallback global a la página de inicio, claves secretas codificadas, almacenamiento de contraseñas en MD5, inyección de comandos, desactivación de verificación de certificados, interruptores de depuración, campos sensibles en registros, rutas de carga no validadas, etc. Los resultados de las coincidencias apuntarán a la referencia correspondiente.

Manejo de falsos positivos: agregue el comentario redline: ignore al final de esa línea (ignorar toda la línea) o redline: ignore SQL001 (ignorar solo la regla especificada). No desactive una regla completa para eliminar una alerta; anote el motivo y explíquelo durante la revisión.

Dos plantillas: assets/threat-model-template.md (modelado de amenazas en la fase de diseño), assets/review-checklist.md (lista de verificación previa al lanzamiento según el tipo de proyecto).

Primero, Determine el Tipo de Proyecto (Decide qué reglas aplican)

Escenario	Forma Típica	Reglas de Seguridad	Requisitos de Integridad	Indexación (SEO)
Sitio público	Sitio web corporativo, landing page, blog, documentación, frontend de tienda	Conjunto completo	Bajo (contenido público)	Obligatorio: 404 real, sitemap, canonical, datos estructurados
Producto con inicio de sesión	SaaS, sitio de herramientas, portal de comunidad	Conjunto completo + sistema de cuentas completo	Medio (operaciones sensibles firmadas)	Solo enviar páginas públicas (marketing/centro de ayuda); páginas privadas con noindex
Panel de administración	admin, panel de operaciones, sistema de atención/revisión	Conjunto completo + entrada independiente + MFA + registro de auditoría	Alto (todas las operaciones de escritura firmadas + auditoría)	Prohibido indexar: noindex en todo el sitio + autenticación obligatoria
Sistema interno/personal	Plataforma interna, herramienta personal, panel de scripts, NAS doméstico	Autenticación + mínima exposición + limitación de tasa + actualizaciones oportunas	Medio (dependiendo de la superficie de exposición)	Prohibido indexar; no poner en la ruta predeterminada de la red pública, no confiar en la "ocultación" como seguridad
API pura	REST / GraphQL / Llamadas entre servicios	Autenticación + validación de entrada + limitación de tasa + gestión de versiones	Según el negocio (pagos/fondos deben ser altos)	No aplica (no genera páginas)

Solo hay una pregunta para la determinación: ¿Debería aparecer esta URL en los motores de búsqueda?

Si debería → Ejecutar como sitio público, todo el capítulo de SEO aplica.
Si no debería → Ejecutar «Prohibir indexación»: X-Robots-Tag: noindex en todo el sitio, robots prohibir rastreo, autenticación obligatoria. No aplique optimizaciones de SEO (sitemap, canonical, datos estructurados) a sistemas de administración o personales; es un desperdicio y expondrá la superficie de ataque.
Independientemente del escenario, «Las rutas inexistentes deben devolver un 404 real» deben cumplirse; eso es corrección HTTP, no SEO.

Cinco Principios Fundamentales

Toda entrada no es confiable: URL, query, body, header, cookie, archivo subido, Webhook, cola de mensajes, valores de retorno de API de terceros, e incluso datos históricos sucios en la base de datos.
Denegar por defecto (fail closed): Cuando la autenticación/validación/parseo falla, devuelva denegación, no permita el paso; las rutas excepcionales no deben llegar a una rama que "salte la validación".
Privilegio mínimo: Las cuentas de base de datos deben tener privilegios separados por función (separación de lectura/escritura, sin DDL), los IAM de nube/almacenamiento de objetos deben autorizar por prefijo, los procesos deben ejecutarse como no root, los contenedores deben tener sistemas de archivos de solo lectura.
Defensa en profundidad: Cuando una capa no puede detener algo, la siguiente aún puede hacerlo. La validación del lado del cliente es para la experiencia, la validación del lado del servidor es para la seguridad; WAF es un recurso de último recurso, no un sustituto.
Limitar el radio de explosión: Las vulnerabilidades de día cero no se pueden eliminar mediante convenciones de código, sino mediante aislamiento, limitación de privilegios, listas blancas de salida y canales rápidos de parches para minimizar el daño.

Lista de Líneas Rojas (Obligatorio, verificar una por una)

Autenticación y Sesión

Las contraseñas deben usar hash Argon2id/bcrypt(cost≥12)/scrypt, prohibido MD5/SHA1/cifrado reversible
Los fallos de inicio de sesión deben limitar la velocidad en dos dimensiones: «cuenta + IP», con retraso progresivo, y si es necesario, código de verificación/bloqueo temporal
El texto de respuesta y el tiempo de respuesta para inicio de sesión, registro y recuperación de contraseña deben ser consistentes, sin revelar si la cuenta existe
Después de un inicio de sesión exitoso, rotar el session id (para prevenir fijación de sesión), la Cookie debe tener HttpOnly + Secure + SameSite
JWT: lista blanca de algoritmos fija del lado del servidor, rechazar alg:none y confusión de algoritmos; período de validez corto + rotación de refresh + posibilidad de revocación
Autenticación ≠ Autorización: Cada interfaz debe verificar explícitamente «si el usuario actual puede operar este objeto» (prevenir IDOR/escalada de privilegios)

Inyección y Salida

Todas las consultas SQL deben usar consultas parametrizadas/enlaces ORM, prohibido concatenar cadenas; los nombres de tabla/campos de ordenación deben pasar por un mapeo de lista blanca
Prohibido insertar la entrada del usuario directamente en shell/comandos; usar la serie execFile con matrices de parámetros
La salida debe codificarse según el contexto; dangerouslySetInnerHTML/v-html/innerHTML deben pasar por un sanitizador como DOMPurify
Rich text, Markdown, parámetros URL deben ser de lista blanca, no confiar en ningún filtrado del lado del cliente
Las solicitudes salientes (SSRF) deben usar lista blanca, prohibido seguir redirecciones arbitrarias, interceptar direcciones de intranet/metadatos (169.254.169.254, 127.0.0.1, 10/8, 172.16/12, 192.168/16, ::1, file://, gopher://)
Las rutas de archivo deben verificarse con path.resolve para validar el prefijo, rechazar ..; los archivos subidos deben tener nombres aleatorios, detección de tipo, almacenamiento aislado y sin permisos de ejecución

Datos y Concurrencia

Las operaciones de escritura críticas deben ser idempotentes (índice único / clave de idempotencia); pedidos, pagos, callbacks deben ser idempotentes
Los campos de stock, saldo, conteo de usos deben usar actualizaciones condicionales UPDATE ... WHERE saldo >= ?, prohibido leer-primero-y-luego-modificar
Las transacciones deben ser cortas, dentro de la transacción prohibido llamadas de red, enviar mensajes, renderizar plantillas
Cada nueva consulta debe ser revisada con EXPLAIN; prohibido paginación con OFFSET grande, SELECT *, consultas N+1
Los montos deben usar enteros en centavos o DECIMAL, prohibido float/double

Asincronía y Estabilidad

Todas las llamadas externas (HTTP/DB/Redis/MQ) deben configurar explícitamente un tiempo de espera, prohibido espera infinita
Los reintentos solo deben usarse para operaciones idempotentes, con retroceso exponencial + jitter + límite superior
El consumo de mensajes debe ser idempotente (tabla de deduplicación por message_id), los fallos deben ir a una cola de mensajes muertos y generar una alerta
Los cambios de estado críticos deben primero persistir en la base de datos y luego enviar el mensaje (Outbox/mensajes transaccionales), prohibido doble escritura

Lógica de Negocio y Condiciones de Carrera (La categoría que más se pasa por alto)

Precios, montos, descuentos, niveles de permisos deben calcularse siempre del lado del servidor; el valor enviado por el cliente solo se usa para mostrar
Cupones, códigos de canje, códigos de invitación deben estar vinculados al usuario y al conteo de usos, con canje atómico (actualización condicional o restricción única)
La máquina de estados debe validarse explícitamente: las transiciones ilegales deben rechazarse directamente (por ejemplo, pasar de pendiente a pagado sin pasar por el callback de pago)
Las interfaces de fondos/callbacks deben verificar firma + timestamp + clave de idempotencia, prevenir repetición y falsificación
La limitación de compra y el control de frecuencia deben juzgarse mediante la combinación de «usuario + dispositivo + IP», no solo una dimensión que se pueda eludir
Las interfaces de exportación, lote y búsqueda deben tener limitación de tasa + límite superior de volumen de datos + auditoría

Secretos y Operaciones

Las claves secretas solo deben colocarse en variables de entorno o en un servicio de gestión de claves; prohibido incluirlas en el repositorio, capas de imagen, bundle del frontend, registros o informes de errores
Las credenciales de CI/CD deben tener privilegios mínimos, las implementaciones en producción requieren aprobación; las dependencias de terceros deben tener versiones bloqueadas + escaneo
Las operaciones sensibles (inicio de sesión, cambio de permisos, exportación, eliminación, reembolso) deben escribir registros de auditoría, que el código de negocio no pueda alterar

Integridad de la Interfaz (Prevención de captura y modificación de paquetes / repetición / falsificación de respuestas)

Las solicitudes sensibles (pago, fondos, autorización, cambio de contraseña) deben tener firma: HMAC(secret, method+path+sortedQuery+sha256(body)+timestamp+nonce), el servidor recalcula
Almacenamiento de nonce para deduplicación (TTL = ventana de tiempo), ventana de tiempo ±300s, rechazar solicitudes caducadas y repetidas
Las respuestas sensibles (resultado de pago, resultado de autorización, saldo) deben incluir una firma del servidor, el cliente la verifica; pero la verdad siempre se vuelve a verificar en el servidor
Cualquier marca de "verificado", precio, rol enviado por el cliente no debe tomarse como fuente de verdad; el servidor recalcula/vuelve a verificar
Fijación de certificados en dispositivos móviles; las versiones de release deben prohibir la confianza en certificados de usuario, prohibir la activación del modo de depuración y captura de paquetes
El endurecimiento del cliente (ofuscación/endurecimiento/antidepuración) solo aumenta el costo, no es un límite de seguridad; las claves secretas no se envían al cliente

Aplicaciones AI / LLM

La salida del modelo debe considerarse como entrada no confiable: no eval, no insertar directamente en HTML/SQL/comandos, no ejecutar directamente argumentos de herramientas
Llamadas a herramientas/funciones: privilegios mínimos + validación de esquema de argumentos + confirmación humana para acciones de alto riesgo
Los documentos recuperados por RAG deben considerarse contenido no confiable, aislados de las indicaciones del sistema, para prevenir inyección indirecta de indicaciones
Las indicaciones del sistema y la entrada del usuario deben estar separadas; no colocar claves secretas o reglas internas en una posición que pueda ser inducida para su salida
Limitación de costo y frecuencia por usuario/inquilino; desinfección de registros (no registrar datos sensibles de indicaciones completas)

Dispositivos Móviles / Mini-Programas

Los datos sensibles deben almacenarse en Keychain (iOS) / Keystore (Android), no en SharedPreferences en texto plano
La transmisión debe ser TLS obligatorio + fijación de certificados; InsecureSkipVerify/verify=False están prohibidos
WebView: desactivar el acceso a file y la superficie de exposición del puente JS; onShouldStartLoadWithRequest debe tener una lista blanca de dominios
La session_key del miniprograma solo debe usarse en el servidor, nunca enviarse al frontend; después de code2session, emitir una sesión propia
La detección de root/jailbreak solo debe usarse como señal de riesgo, no como base para la autenticación

HTTP y Enrutamiento (Todos los escenarios)

Las rutas inexistentes deben devolver un HTTP 404 real + página 404, prohibido redirigir con 302/200 a la página de inicio
La estrategia de history fallback en SPA solo debe aplicarse a «rutas frontend conocidas»; /api y recursos estáticos con extensión deben devolver 404
CORS: usar lista blanca de Orígenes exactos, prohibido Access-Control-Allow-Origin: * con credentials, prohibido reflejar cualquier Origin
En producción, activar cabeceras de seguridad: HSTS, CSP, X-Content-Type-Options, Referrer-Policy, frame-ancestors
Las respuestas de interfaces de autenticación/sensibles deben incluir Cache-Control: no-store
Las respuestas de error no deben devolver stack traces, SQL, versiones de frameworks o rutas internas

Indexación (Solo para sitios públicos; para paneles de administración/sistemas internos, hacer lo contrario)

Sitios públicos: el sitemap solo debe listar páginas con código 200, canonical para deduplicación, robots que no revele rutas de administración, el sitio de preproducción debe tener noindex en todo el sitio
Paneles de administración/sistemas internos/personales: X-Robots-Tag: noindex en todo el sitio + robots Disallow: /, no generar sitemap, y debe tener autenticación (robots no es control de acceso)

Fase Uno: En el Diseño

Antes de comenzar, dedique 5 minutos a un modelado de amenazas ligero:

Determine el escenario: Consulte la tabla de tipos de proyecto anterior, confirme si es un sitio público, panel de administración, sistema interno o API; decida si ejecutar el capítulo de SEO y cuán grande es la superficie de exposición.
Dibuje el flujo de datos: Usuario → Puerta de enlace → Servicio → Base de datos/Caché/MQ/Terceros, marque cada punto donde se cruza un límite de confianza.
Enumere y clasifique los activos: Cuentas, credenciales, pagos, datos personales, panel de administración; pregunte «quién puede leer, quién puede escribir, cuáles son las consecuencias de la manipulación, cuánto tiempo conservar».
Para cada límite, pregunte tres cosas: ¿Quién puede llegar? ¿Se valida la entrada? ¿Se deniega por defecto en caso de fallo?
Determine el modelo de permisos: Rol → Recurso → Acción; aplicar en el servidor; ocultar botones en el frontend no cuenta; para sistemas multiinquilino, definir políticas de aislamiento adicionales.
Determine los límites asíncronos: Qué operaciones deben devolverse de forma síncrona (inicio de sesión, confirmación de pago) y cuáles pueden ser asíncronas (notificaciones, informes, exportaciones).

El documento de diseño debe incluir al menos: tipo de proyecto y estrategia de indexación, método de autenticación, modelo de autorización, clasificación y cifrado de datos sensibles, estrategia de limitación de tasa, clave de idempotencia, modo de degradación en caso de fallo, alcance de registros y auditoría.

Fase Dos: Durante la Implementación

Autenticación e Inicio de Sesión (Prioridad más alta)

El inicio de sesión es la entrada más fácil de atacar con fuerza bruta, relleno de credenciales y omisión. Las reglas completas están en references/auth-and-session.md; lo esencial no negociable:

Limitación de velocidad por capas: IP única, cuenta única, huella digital de dispositivo único; los contadores de fallos deben usar claves caducables en Redis, no solo en memoria.
El mensaje de error debe ser uniforme: «Cuenta o contraseña incorrecta»; el tiempo de respuesta debe estar alineado (incluso si la cuenta no existe, ejecutar un hash falso para evitar la enumeración temporal).
Después de un inicio de sesión exitoso, regenerar el identificador de sesión; invalidar la sesión anterior.
Las operaciones sensibles (cambio de contraseña, cambio de enlace, retiro de fondos, eliminación) requieren una segunda verificación o un tiempo de última autenticación reciente (ventana de re-autenticación).
Token de restablecimiento de contraseña: alta entropía, de un solo uso, corta duración (≤15 minutos), vinculado al usuario y al propósito.
El panel de administración debe tener una entrada independiente, un dominio o una lista blanca de IPs independientes, y no compartir la sesión con el lado del usuario.

Entrada, Inyección y Salida

Consulte references/web-vulnerability-prevention.md. Principio: Validación unificada en la entrada (schema), codificación según el contexto en la salida.

// Entrada: usar schema para validar, rechazar campos desconocidos, no "tomar los que se necesitan"
const LoginBody = z.object({ email: z.string().email(), password: z.string().min(8).max(128) }).strict();

// SQL: parametrizado, nunca concatenar
await db.query('SELECT id, password_hash FROM users WHERE email = $1', [email]);
// Para posiciones como ordenación/nombres de tabla que no se pueden parametrizar: lista blanca
const orderBy = { created_at: 'created_at', amount: 'amount_cents' }[sort] ?? 'created_at';

XSS: React/Vue tienen escape por defecto, las API peligrosas deben sanitizarse; CSP es la segunda línea de defensa.
Escalada de privilegios: Incluir owner_id = $currentUser en las condiciones de la consulta, no «consultar primero y luego filtrar en el frontend».
Deserialización/inyección de plantillas: No eval, no insertar la entrada del usuario en plantillas/expresiones/regex.
Subidas: Limitar tamaño y tipo (por bytes mágicos), nombres de archivo aleatorios, almacenar en almacenamiento de objetos, recodificar imágenes.

Base de Datos y Alta Concurrencia

Consulte references/database-concurrency.md. Puntos clave:

Índices antes que optimización: Revisar nuevas consultas con EXPLAIN antes del lanzamiento, prestando atención a type=ALL, filesort, tablas temporales.
Paginación con cursor (keyset), no con offset profundo; las interfaces de listas deben tener una ordenación estable + un límite superior.
Escrituras en puntos calientes usando «actualización condicional + bloqueo de fila», ejemplo de reducción de stock:

UPDATE sku SET stock = stock - $1, version = version + 1
WHERE id = $2 AND stock >= $1;
-- número de filas afectadas = 0 → stock insuficiente o conflicto de concurrencia, reintentar/fallar según el negocio

Trilogía de caché: Prevenir penetración (caché de valores nulos/filtro Bloom), prevención de avalancha (bloqueo mutuo/vuelo único), prevención de collapse (TTL con jitter aleatorio).
El límite superior del pool de conexiones debe ser menor que max_connections de la base de datos / número de instancias, y configurar un tiempo de espera de obtención.
Cuando la escala crezca, considere la fragmentación de bases de datos y tablas; primero haga índices, caché, separación de lectura/escritura, separación de datos fríos/calientes.

Lógica de Negocio y Condiciones de Carrera

Consulte references/business-logic-and-race-conditions.md. Estas vulnerabilidades no tienen un escáner unificado; solo se pueden prevenir mediante una consideración cuidadosa en el diseño: precios y montos calculados en el servidor, canje atómico de cupones, validación de máquina de estados, prevención de repetición, dimensiones de límite de compra, límite de exportación. Cambie todos los «leer primero, luego escribir» bajo concurrencia a actualizaciones condicionales o bloqueo + idempotencia.

Arquitectura Asíncrona por Defecto

Consulte references/async-architecture.md. El sistema está diseñado por defecto para ser asíncrono:

Todas las IO deben ser no bloqueantes; en Node, prohibido usar fs síncrono, crypto y cálculos pesados de CPU en la ruta de solicitud (usar worker_threads).
Cada llamada externa debe tener un tiempo de espera; pasar un trace id a lo largo de la cadena de llamadas.
Consumo de cola = al menos una entrega, por lo tanto debe ser idempotente; reintentos con límite superior, si se excede, ir a DLQ y generar alerta.
Consistencia entre servicios usando Outbox/CDC, no doble escritura.
Tareas largas (exportaciones, lotes, revisiones) van a una cola, la interfaz devuelve inmediatamente un task id, el frontend sondea o usa SSE para el estado.
Apagado ordenado: Dejar de aceptar nuevas solicitudes → Esperar a que las solicitudes en curso terminen → Cerrar los consumidores de cola → Cerrar las conexiones.

HTTP, Enrutamiento, CORS y SEO

Consulte references/http-routing-cors-seo.md. Tres errores más comunes:

El 404 debe ser 404. No haga un fallback global a la página de inicio: SPA solo debe redirigir las rutas frontend conocidas a index.html en tiempo de construcción; /api/* y las rutas con extensiones deben devolver 404 directamente.
CORS: lista blanca exacta, comparar Origin con la configuración como una igualdad de conjuntos, no includes, no coincidencia de prefijos, no reflejar directamente la cabecera de solicitud.
Semántica correcta de códigos de estado: 401 no autenticado, 403 sin permisos, 404 no existe, 409 conflicto, 422 error de validación, 429 límite de tasa.

SEO solo aplica para sitios públicos; para paneles de administración y sistemas internos, ejecute la sección «Prohibir indexación» de la tabla de escenarios anterior, no les agregue sitemap, canonical o datos estructurados; eso aumenta la superficie de ataque para los rastreadores.

Secretos, Operaciones y Correo Electrónico

Consulte references/operations-and-secrets.md. Puntos clave: Almacenamiento y rotación de secretos por capas, privilegios mínimos en CI/CD, contenedores no root, almacenamiento de objetos e IAM de nube minimizados, registros de auditoría inmutables, configuración de SPF/DKIM/DMARC en el dominio de correo para prevenir falsificaciones, período de retención de datos y proceso de eliminación.

Integridad de la Interfaz y Anti-Manipulación

Consulte references/api-integrity-and-tampering.md. La captura y modificación de paquetes y la repetición son los principales problemas en dispositivos móviles y APIs abiertas: firma de solicitud (HMAC + timestamp + nonce + body hash), recálculo en el servidor, firma de respuestas sensibles, deduplicación de nonce, ventana de tiempo, fijación de certificados. Recuerde: todo lo que el cliente pueda modificar no es confiable; la firma solo aumenta la dificultad, el recálculo en el servidor es la verdad.

Seguridad en Aplicaciones AI / LLM

Consulte references/ai-llm-security.md. La salida del modelo es equivalente a la entrada externa: no ejecutar, no insertar directamente, no usar como SQL/comando; llamadas a herramientas con privilegios mínimos + validación de esquema + confirmación humana para alto riesgo; contenido de RAG no confiable; limitación de costo por inquilino.

Dispositivos Móviles y Mini-Programas

Consulte references/mobile-and-miniprogram.md. Keychain/Keystore, fijación de certificados, endurecimiento de WebView, session_key del miniprograma no se envía al cliente, detección de root solo como señal.

Fase Tres: Revisión Previa al Lanzamiento

Revise en orden, cualquier elemento «no seguro» debe tratarse como no aprobado:

Marque el 100% de la lista de líneas rojas; luego verifique según el tipo de proyecto: para sitios públicos, revise los elementos de SEO; para paneles de administración/sistemas internos, revise noindex y aislamiento de entrada; para negocios sensibles, revise la integridad de la interfaz.
Ejecute python scripts/scan_redlines.py <directorio> --fail-on high, las vulnerabilidades altas deben llegar a cero.
Escaneo de dependencias (npm audit / pip-audit / govulncheck / OWASP Dependency-Check), las vulnerabilidades altas deben tratarse.
Verificación de secretos: No deben aparecer secretos en el repositorio, imágenes, registros, bundle del frontend; .env no debe estar en el control de versiones; los registros de CI también deben revisarse.
Contenedor/host: no root, sistema de archivos raíz de solo lectura, exposición mínima de puertos, lista blanca de salida.
Monitoreo y alertas: Tasa de fallos de inicio de sesión, 5xx, acumulación de colas, consultas lentas, solicitudes de salida anómalas.
Simulacros de copia de seguridad y restauración; privilegios mínimos para cuentas de base de datos.
Pruebas de rendimiento en rutas críticas (inicio de sesión, pedidos, listas) para confirmar que la limitación de tasa y el caché funcionan.
Dominio de correo: Configurar SPF/DKIM/DMARC, limitar la tasa de la interfaz de envío de correo, evitar ser falsificado para enviar correos de phishing o ser considerado una fuente de spam.
Ciclo de vida de los datos: Definir recopilación mínima, período de retención, proceso de exportación y eliminación; desinfección de registros después de la retención.
Plan de respuesta a incidentes de seguridad: Quién es responsable, cómo aislar, cómo notificar a los usuarios, cómo realizar la revisión post-mortem.
Mapa de cumplimiento (si es necesario): Consulte references/compliance-mapping.md para verificar los elementos de OWASP/ASVS/Grade de protección/PIPL.

Fase Cuatro: Tiempo de Ejecución y Mitigación de Día Cero

Las convenciones de código no pueden prevenir vulnerabilidades desconocidas; limite el impacto con los siguientes medios:

Salida denegada por defecto + lista blanca (primera barrera contra SSRF y conexiones de retorno de la cadena de suministro).
Aislamiento de servicios críticos en sandboxes/contenedores, reducción de privilegios de procesos, seccomp/AppArmor según sea necesario.
Bloqueo de versiones de dependencias + capacidad de reconstruir imágenes rápidamente; monitorear avisos de seguridad, reservar un canal de parches de emergencia.
WAF/puerta de enlace para interceptar patrones genéricos y limitar tasas, pero no depender solo de él.
Monitoreo de comportamiento: Inicios de sesión anómalos (saltos de ubicación geográfica/dispositivo), lectura/escritura por lotes, tráfico de salida anómalo.
Clasificación de datos: Cifrado de campos sensibles (AES-GCM/KMS), desinfección de registros, exportación con aprobación.

Índice de Referencias

Archivo	Cuándo Leerlo
`references/auth-and-session.md`	Inicio de sesión, registro, contraseña, JWT, 2FA, recuperación de contraseña, CSRF, escalada de privilegios, panel de administración
`references/web-vulnerability-prevention.md`	Inyección SQL, XSS, SSRF, subidas, path traversal, deserialización, cabeceras de respuesta, riesgos específicos de API
`references/business-logic-and-race-conditions.md`	Precios/montos, cupones, stock, máquina de estados, condiciones de carrera TOCTOU, límite de compra, abuso de exportación
`references/database-concurrency.md`	Creación de tablas, índices, transacciones, bloqueos, idempotencia, caché, separación de lectura/escritura, fragmentación de bases de datos/tablas
`references/async-architecture.md`	Tiempo de espera, reintentos, consumo de cola, Outbox, contrapresión, apagado ordenado, observabilidad
`references/http-routing-cors-seo.md`	404, códigos de estado, CORS, caché, robots/sitemap, diferenciación de indexación entre sitios públicos y paneles de administración
`references/operations-and-secrets.md`	Secretos, CI/CD, contenedores/nube, dominio de correo, registros de auditoría, ciclo de vida de datos, respuesta a emergencias
`references/api-integrity-and-tampering.md`	Captura y modificación de paquetes, firma de solicitudes/respuestas, protección contra repetición, fijación de certificados, límites de endurecimiento del cliente
`references/ai-llm-security.md`	Inyección de indicaciones, permisos de llamadas a herramientas, envenenamiento de RAG, manejo de salida del modelo, limitación de costos
`references/mobile-and-miniprogram.md`	Almacenamiento local, fijación de certificados, WebView, estado de inicio de sesión en miniprogramas, detección de root
`references/compliance-mapping.md`	OWASP Top 10 / ASVS / Grado de protección 2.0 / PIPL, para auditorías o informes de revisión
`references/internal-policy.example.md`	Cuando se necesita una plantilla personalizada de prohibición de activos (nombres de dominio de marcador de posición, sin direcciones reales)

Acuerdo de Entrega

En cada entrega de código, incluya en la respuesta de 3 a 6 líneas que expliquen las decisiones de seguridad tomadas esta vez (puntos de validación, puntos de autenticación, claves de idempotencia, limitación de tasa, manejo de errores); no lo omita.
Primero, indique el tipo de proyecto: si la entrega es para un panel de administración o sistema interno, indique claramente «No hacer SEO, noindex en todo el sitio»; solo para sitios públicos debe generar la configuración de indexación.
Si el código existente viola una línea roja, señale directamente la ubicación y proporcione una corrección; no se limite a decir «se recomienda reforzar».
Para las partes que no se pueden verificar (por ejemplo, no se han realizado pruebas de ataque reales), indique claramente «no verificado», no afirme que ha pasado las pruebas de seguridad.

bucai2417/desarrollo-seguro-de-sistemas

¿Qué es desarrollo-seguro-de-sistemas?

Preguntar en tu IA favorita

Documentación