Directrices de seguridad de la API interna

Listas de control de seguridad, perspectivas de revisión del código y plantillas de políticas para equipos de desarrollo.

📋 Lista de comprobación previa al desarrollo

Elementos que deben verificarse antes de desarrollar un nuevo punto final de API.

  • Se ha creado la especificación API (OpenAPI)
  • Se han determinado los métodos de autenticación y autorización
  • Se han definido los tipos y restricciones de los parámetros de entrada
  • Se han definido claramente los campos que deben incluirse en las respuestas
  • El formato de respuesta a errores está estandarizado
  • Se han establecido requisitos de limitación de la tasa
  • Se ha confirmado el tratamiento de datos personales y sensibles
  • Se ha determinado el método de autenticación (OAuth 2.0, JWT, API Key)
  • Se han definido los permisos necesarios (ámbitos/roles) para cada punto final
  • Se han diseñado controles de autorización a nivel de recursos (contramedida BOLA)
  • Las funciones administrativas están claramente separadas
  • Se han determinado los métodos de caducidad y actualización de los tokens
  • La comunicación utiliza TLS 1.2 o superior
  • Se ha determinado el método de cifrado de los datos almacenados
  • Se han determinado las políticas de enmascaramiento y anonimización de la información personal
  • La información sensible (tokens, contraseñas) no se incluye en los registros
  • La información de depuración y las trazas de pila no se incluyen en las respuestas de la API

👀 Perspectivas de la revisión de códigos

Perspectivas de seguridad a comprobar durante las revisiones del código de la API.

Comprobar artículoImportanciaExplicación
El middleware de autenticación se aplica a todos los puntos finalesRequeridoGarantizar que no falte ninguna comprobación de autenticación excepto en las API públicas.
Existen comprobaciones de autorización a nivel de objetoRequeridoVerificar que los recursos solicitados pertenecen al usuario solicitante
Las funciones de administración tienen verificación de funcionesRequeridoGarantizar que los usuarios normales no puedan llamar a las API de administración
El algoritmo se especifica durante la verificación JWTRequeridoPrevención de alg: ningún ataque
La caducidad del token está correctamente configuradaRecomendadoFicha de acceso: en 15 minutos
Comprobar artículoImportanciaExplicación
El cuerpo de la solicitud tiene validación de esquemaRequeridoValidación de tipo, longitud y formato
Las consultas SQL están parametrizadasRequeridoGarantizar que las consultas no se construyan con concatenación de cadenas
Existe validación del formato de los parámetros de rutaRequeridoCompruebe el formato esperado, como UUID
Los parámetros de paginación tienen límites superioresRecomendadoEvitar solicitudes excesivas como limit=999999
La carga de archivos tiene restricciones de tipo y tamañoRecomendadoValidación del tipo de contenido y del tamaño del archivo
Comprobar artículoImportanciaExplicación
Las respuestas no contienen campos innecesariosRequeridoEvitar la filtración de password_hash, ID internos, etc.
Las respuestas de error no contienen trazas de pilaRequeridoNo exponga información interna en producción
Las cabeceras de seguridad están configuradasRecomendadoX-Content-Type-Options, HSTS, etc.
Content-Type está correctamente configuradoRecomendadoEspecificar explícitamente application/json
Comprobar artículoImportanciaExplicación
Se aplica la limitación de velocidadRequeridoEspecialmente para los puntos finales de autenticación y pago
Se registran los datos adecuadosRecomendadoTrazabilidad: quién hizo qué y cuándo
Los secretos no están codificadosRequeridoUtilizar variables de entorno o gestores secretos
La configuración CORS es adecuadaRecomendadoEvitar el uso de comodines
Las dependencias no tienen vulnerabilidades conocidasRecomendadoComprobar los resultados de la auditoría npm / Snyk

📜 Plantillas de políticas de seguridad

Plantillas para políticas básicas en el desarrollo de API internas. Personalícelas para adaptarlas a su proyecto.

1. Política de autenticación

PolicyPlantilla
■ Métodos de autenticación
  - APIs de cara al usuario: OAuth 2.0 (código de autorización + PKCE)
  - APIs de servidor a servidor: OAuth 2.0 (credenciales de cliente) o mTLS
  - API de integración externa: Clave API + firma HMAC

■ Gestión de tokens
  - Caducidad de token de acceso: 15 minutos
  - Caducidad del token de actualización: 7 días (se requiere rotación)
  - Almacenamiento de tokens: HttpOnly + Seguro + Cookie SameSite

Política de contraseñas
  - Mínimo 12 caracteres, al menos una mayúscula, una minúscula, un número y un símbolo
  - Hash con bcrypt (factor de coste 12 o superior)
  - Protección contra ataques a listas de contraseñas (integración con la API Have I Been Pwned)

2. Política de diseño de API

PolicyPlantilla
Gestión de versiones
  - Gestión de versiones mediante ruta URL: /api/v1/recursos
  - Periodo de soporte mínimo de 6 meses para versiones antiguas
  - Notificación de obsoletos a través de la cabecera Deprecation

■ Limitación de tarifas (valores por defecto)
  - API generales: 100 peticiones/15 min
  - API de autenticación: 5 peticiones/15 min
  - API públicas: 30 solicitudes/min
  - Devuelve siempre cabeceras RateLimit-*

■ Respuestas
  - Content-Type: application/json (fijo)
  - Respuestas de error en formato RFC 7807 (Detalles del problema)
  - Nunca devuelve trazas de pila en producción
  - Paginación: por defecto 20 elementos, máximo 100 elementos

3. Política de registro y auditoría

PolicyPlantilla
■ Campos de registro obligatorios
  - Sello de tiempo (ISO 8601, UTC)
  - ID de solicitud (UUID para la trazabilidad)
  - ID de usuario / ID de cliente de API
  - Método HTTP + punto final
  - Código de estado
  - IP de origen
  - Tiempo de respuesta

■ Campos de registro prohibidos (datos sensibles)
  - Contraseñas / Tokens / Claves API
  - Números de tarjetas de crédito
  - Visualización completa de PII (se requiere enmascaramiento)

Alertas de supervisión
  - Fallos de autenticación: Alerta a partir de 5/min
  - Errores 403: Alerta a 10+/min
  - 500 errores: Alerta inmediata en 1 ocurrencia
  - Límite de velocidad superado: Análisis de patrones

🚨 Flujo de respuesta a incidentes

Fase 1: Detección

Detectar incidentes mediante alertas de supervisión, informes de usuarios o notificaciones externas. Determinar la gravedad mediante el triaje inicial.

0-30 minutos

Fase 2: Contención

Prevenir la escalada de daños. Invalide las claves API, suspenda temporalmente los endpoints afectados e identifique el alcance del impacto.

30 min - 2 horas

Fase 3: Erradicación y recuperación

Solucionar las vulnerabilidades, aplicar parches y restablecer los servicios. Notificar a los usuarios afectados.

2-24 horas

Fase 4: Análisis posterior al incidente

Realizar la autopsia. Realice un análisis de la causa raíz, desarrolle medidas de prevención de la recurrencia y documente los resultados.

1-5 días laborables

🤖 AI / LLM Security Checklist

Additional checklist items for systems integrating AI models and LLM-powered features.

  • Model provider has been evaluated for security and compliance (SOC 2, data processing agreement)
  • System prompts are stored securely and not exposed to end users
  • Token budget and cost limits are configured per request and per user
  • Data classification policy defines what data can be sent to external LLM APIs
  • LLM outputs are validated and sanitized before rendering or downstream processing
  • Fallback behavior is defined for model unavailability or degraded responses
  • Model version pinning strategy is documented to prevent unexpected behavior changes
OWASP References

Related: LLM06: Excessive Agency, LLM02: Insecure Output Handling

  • Agent permissions follow least privilege principle — only necessary tools and APIs are accessible
  • Tool/function calling uses an explicit allowlist (not a denylist)
  • Human-in-the-loop approval is required for high-impact actions (payments, deletions, external communications)
  • Agent memory scope is bounded — conversation history does not leak across tenants or sessions
  • Inter-agent communication is authenticated and uses signed messages
  • Goal drift detection is implemented — agents are monitored for deviation from intended objectives
  • Emergency kill switch exists to halt agent execution immediately
OWASP References

Related: ASI01: Excessive Agency, ASI03: Insecure Tool/Function Calling, ASI09: Inadequate Sandboxing

  • Training data provenance is documented with lineage tracking
  • Data integrity checks exist for training and fine-tuning datasets (hash verification)
  • Model artifacts are versioned and stored in a tamper-proof registry
  • Model drift monitoring is in place to detect performance degradation
  • Third-party models and embeddings have been evaluated for known vulnerabilities
  • PII and sensitive data scrubbing is applied to training datasets
OWASP References

Related: LLM03: Training Data Poisoning, ML02: Data Poisoning Attack, ML06: AI Supply Chain Attacks

🧐 AI / LLM Code Review Perspectives

Security check items specific to code that integrates LLMs, AI agents, and ML models.

Comprobar artículoImportanciaExplicación
System prompts are not exposed in client-side code or API responsesRequeridoPrompt leakage enables targeted prompt injection attacks
LLM outputs are validated before rendering (HTML/JS/SQL)RequeridoLLM-generated content may contain XSS payloads or injection vectors
User input and system instructions are clearly separated in promptsRequeridoPrevents direct prompt injection by maintaining instruction-data boundary
Tool/function call permissions are scoped per user roleRequeridoPrevent privilege escalation through agent tool access
Token count limits are enforced per request and per sessionRecomendadoPrevents cost explosion and denial-of-wallet attacks
RAG retrieval results are sanitized before insertion into promptsRequeridoRetrieved documents may contain indirect prompt injection payloads
Agent actions and tool calls are logged with full audit trailRecomendadoEssential for incident investigation and compliance in AI systems

📑 AI / LLM Security Policy Templates

Policy templates for organizations deploying AI models and LLM-powered applications.

4. AI Model Access Control Policy

PolicyPlantilla
■ Model Access Tiers
  - Tier 1 (Restricted): GPT-4 class / fine-tuned models — requires team lead approval
  - Tier 2 (Standard): GPT-3.5 class / embeddings — available to all developers
  - Tier 3 (Open): Open-source models (local inference) — no approval required

■ API Key Management for LLM Providers
  - One API key per service/environment (never share across projects)
  - Monthly spend alerts at 50%, 80%, 100% of budget
  - Hard spending caps enforced at the provider level
  - Key rotation: every 90 days or immediately upon team member departure

■ Data Sent to External Models
  - NEVER send: PII, credentials, internal IP, source code, customer data
  - ALLOWED with review: anonymized logs, public documentation, synthetic data
  - All prompts to external APIs must be logged (excluding PII)

5. AI Data Handling Policy

PolicyPlantilla
■ Training Data Requirements
  - All training data must have documented provenance and licensing
  - PII must be removed or anonymized before use in training/fine-tuning
  - Data poisoning checks: validate data integrity with hash verification
  - Retain training data snapshots for reproducibility and audit

■ RAG (Retrieval-Augmented Generation) Data
  - Document ingestion pipeline must sanitize content (strip scripts, injections)
  - Access control on vector store must mirror source document permissions
  - Embedding models must be versioned and pinned

■ Model Output Data
  - LLM outputs must not be trusted as authoritative — always verify facts
  - Generated code must pass the same security review as human-written code
  - Outputs containing PII must be flagged and redacted before storage

6. AI Incident Classification Policy

PolicyPlantilla
■ Severity Levels for AI-Specific Incidents
  - P1 (Critical): Prompt injection leading to data exfiltration or unauthorized actions
  - P1 (Critical): Model serving compromised or returning manipulated outputs
  - P2 (High): Training data poisoning detected, jailbreak bypass discovered
  - P2 (High): Agent performing unintended actions outside approved scope
  - P3 (Medium): Model drift causing degraded accuracy below threshold
  - P4 (Low): Cost overrun due to excessive token usage

■ Response Procedures
  - P1: Immediately disable affected model endpoint, notify security team
  - P2: Quarantine affected model version, roll back to last known good
  - P3: Trigger retraining pipeline, increase monitoring frequency
  - P4: Adjust rate limits and budget caps, review usage patterns

■ Post-Incident Requirements
  - Root cause analysis within 48 hours for P1/P2
  - Update prompt injection test suite with new attack vectors
  - Review and update guardrails configuration

⚡ Referencia rápida: Códigos de estado HTTP

Códigos de estado HTTP relacionados con la seguridad utilizados en el diseño de API.

CódigoSignificadoCaso práctico
400Bad RequestError de validación de entrada
401UnauthorizedSe requiere autenticación o el token no es válido
403ForbiddenAutentificado pero permisos insuficientes
404Not FoundEl recurso no existe (también puede utilizarse en lugar de 403)
405Method Not AllowedMétodo HTTP no permitido
413Payload Too LargeSe ha superado el tamaño del cuerpo solicitado
422Unprocessable EntitySintaxis correcta pero error semántico
429Too Many RequestsLímite de velocidad superado
500Internal Server ErrorError interno del servidor (ocultar detalles)