Datos de Prueba Hardcodeados
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.
Cómo Funciona
Los desarrolladores frecuentemente usan datos reales o que parecen reales en las pruebas por conveniencia. Si un archivo de prueba contiene el email de una persona real o una credencial que parece una key de producción, las herramientas de análisis estático la marcan como exposición de secret, y se vuelve poco claro si son datos de prueba o una filtración real.
// MAL: datos de prueba que parecen o son datos sensibles reales
describe('Auth de usuario', () => {
it('debería iniciar sesión', async () => {
await login('juan.perez@empresareal.com', 'P@ssw0rd123!');
// email real, contraseña que parece real — confuso y potencialmente real
});
});// BIEN: datos de prueba obviamente falsos usando patrones estándar de testing
describe('Auth de usuario', () => {
it('debería iniciar sesión', async () => {
await login('test@example.com', 'contrasena-de-prueba-no-real');
// dominio example.com + claramente etiquetado — sin confusión
});
});Ejemplo Real
Múltiples reportes de bug bounty han sido enviados por archivos de prueba que contenían lo que parecían credenciales reales. Incluso cuando no eran reales, el equipo de seguridad tuvo que pasar tiempo investigando — y ocasionalmente eran credenciales reales de producción dejadas de un copy-paste.
Cómo Prevenirlo
- Siempre usa @example.com o @test.invalid para direcciones de email de prueba
- Usa valores falsos claramente etiquetados como 'test-api-key-no-real' para campos de credenciales
- Configura Gitleaks o herramientas similares para escanear archivos de prueba con el mismo rigor que el código de producción
- Usa fixtures o factories de prueba en vez de valores hardcodeados — más fáciles de mantener y claramente falsos
Tecnologías Afectadas
Data Hogo detecta esta vulnerabilidad automáticamente.
Escanea Tu Repo GratisVulnerabilidades Relacionadas
Sin Archivo .env.example
lowSin 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 Linting de Seguridad
lowSin reglas de ESLint orientadas a seguridad, vulnerabilidades comunes como sinks XSS, dangerouslySetInnerHTML y uso de eval() pasan desapercibidas en code review.
Sin Git Hooks de Seguridad
lowSin 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.
.gitignore Inadecuado
mediumUn .gitignore que no cubre archivos .env, artefactos de build y configuraciones de IDE puede llevar a que secrets o datos sensibles sean accidentalmente commiteados.