This repository contains an anonymized technical case study focused on the security and resilience analysis of a REST API within a digital health record platform.
A technical security analysis was conducted on a digital health record platform to evaluate API resilience against scenarios affecting service availability and unintended information exposure. The analysis focused on a second-generation REST API, reviewing input handling, error management, and authentication consistency.
- A. Denial of Service (DoS) via Resource Exhaustion: Integration endpoints accepted large POST payloads (tens of MBs) without validation, leading to main-thread blocking during JSON parsing.
- B. Metadata Exposure in Production: Verbose error responses revealed absolute file paths and specific framework versions, aiding technological enumeration.
- C. HTTP Verb Tampering: Inconsistencies in the authentication middleware allowed certain methods (e.g., HEAD) to bypass filters that were correctly applied to others (e.g., GET).
- Black-box analysis focused on observable API behavior and business logic.
- Responsible Disclosure: All findings were privately communicated to the organization.
- Data Integrity: No real user data was accessed, modified, or compromised.
- Payload Constraints: Explicit middleware configuration to limit request size.
- Rate Limiting: IP-based and identity-based throttling.
- Error Sanitization: Generic production messages; technical details restricted to internal logs.
- Schema Validation: Implementation of typed validators (e.g., Zod, Joi).
This case study reflects a defensive security analysis based on publicly exposed API behavior.
No internal access, credentials, or privileged information were used, and no intrusive testing techniques were performed.
This repository includes minimal code examples illustrating defensive mitigation patterns related to the findings (payload limits, error sanitization). These examples are not exploit PoCs and do not reproduce the original issues.
- Example mitigation (payload limits & error sanitization):
mitigations/payload-and-error-handling.example.js
Se realizó un análisis técnico de seguridad sobre una plataforma de historia clínica digital con el objetivo de evaluar la resiliencia de su API frente a escenarios que afectan la disponibilidad del servicio y la exposición no deseada de información.
- A. Denegación de Servicio (DoS): Endpoints de integración aceptaban peticiones de gran tamaño sin validación previa, provocando el bloqueo del hilo principal de ejecución.
- B. Exposición de Metadatos: Las respuestas ante errores revelaban rutas absolutas del sistema de archivos y versiones de librerías.
- C. Inconsistencia en Control de Acceso (Verb Tampering): El middleware de autenticación no filtraba correctamente métodos semánticamente equivalentes (como HEAD), permitiendo eludir controles previstos.
- Límites de tamaño en payloads.
- Implementación de rate limiting.
- Sanitización de errores en entornos de producción.
- Validación de esquemas de entrada.
- Restricción de Payloads: Configuración explícita de middlewares para limitar el tamaño de las peticiones.
- Rate Limiting: Aplicación de límites por IP y por identidad.
- Sanitización de Errores: Mensajes genéricos en producción; detalles técnicos restringidos a logs internos.
- Validación de Esquemas: Implementación de validadores tipados (por ejemplo, Zod, Joi).
Este caso de estudio refleja un análisis de seguridad defensivo basado en el comportamiento público de la API.
No se utilizó acceso interno, credenciales ni información privilegiada, ni se aplicaron técnicas de prueba intrusivas.
Este repositorio incluye ejemplos mínimos de código que ilustran patrones defensivos de mitigación relacionados con los hallazgos (restricción de payloads, sanitización de errores). Estos ejemplos no constituyen PoC de explotación ni reproducen las vulnerabilidades originales.
- Ejemplo de mitigación (restricción de payloads y sanitización de errores):
mitigations/payload-and-error-handling.example.js
All sensitive identifiers, company names, and infrastructure details have been removed or anonymized. Shared exclusively for educational and defensive purposes.
Todos los identificadores sensibles han sido omitidos o anonimizados. Compartido exclusivamente con fines educativos y defensivos.