El patrón se repite semanalmente: una factura imprevista de miles de dólares en OpenAI, transferencias no autorizadas en cuentas de Stripe o clientes que reportan redirecciones silenciosas hacia pasarelas de phishing. Cuando auditamos la infraestructura afectada, la causa casi nunca es un exploit de día cero ultra sofisticado; suele ser una clave secreta compilada en un bundle de JavaScript o un plugin de WordPress vulnerable ejecutando código arbitrario.
En entornos de desarrollo ágiles o agencias que entregan sitios a contrarreloj, la frontera entre frontend y backend se difumina. Alguien necesita conectar un chatbot o un flujo de checkout rápido y termina inyectando un token con permisos de escritura directo en el DOM o en un script encolado.
La anatomía de una fuga de credenciales en el cliente
El error estructural más común es confundir claves públicas con privadas. Servicios como Stripe separan deliberadamente sus credenciales (pk_live_ para el frontend y sk_live_ para el backend). Sin embargo, plataformas como OpenAI, Anthropic o Resend no tienen ese concepto de clave cliente segura por diseño: cualquier token expuesto en el navegador otorga control total sobre la cuota y los endpoints de la API.
Esto suele llegar a producción a través de tres vías:
- Empaquetadores mal configurados: Webpack, Vite o Next.js exportando variables de entorno completas en el build estático porque alguien usó un prefijo indebido o configuró
DefinePluginapuntando aprocess.envsin filtrar. - Inyecciones directas en temas o plugins: Desarrolladores que usan
wp_localize_script()o imprimen scripts inline con credenciales codificadas a mano para evitar configurar un endpoint proxy en PHP/Node. - Compromiso de base de datos: Un plugin vulnerable permite una inyección SQL o actualización arbitraria de opciones (
wp_options), inyectando scripts maliciosos de terceros que capturan inputs de tarjetas o tokens de sesión.
Protocolo de auditoría técnica paso a paso
Para auditar si un sitio web tiene claves expuestas o código comprometido, no confíes en plugins de seguridad tradicionales de WordPress; muchos de ellos solo verifican firmas de archivos conocidos y pasan por alto scripts generados dinámicamente.
Arquitectura de remediación: Cómo aislar secretos
Eliminar la clave expuesta no basta; debes revocarla inmediatamente en el dashboard del proveedor. Luego, la arquitectura debe reestructurarse para evitar que el navegador vuelva a tocar una credencial sensible.
[ Cliente (Navegador) ]
│
│ (Solo consume endpoints relativos: /api/chat)
▼
[ Reverse Proxy / Backend Seguro (Node.js, Go o PHP aislado) ]
│
│ Lee variables de entorno locales (NO expuestas en build)
▼
[ API Externa (OpenAI, Stripe, Resend) ]
Reglas para el diseño seguro de endpoints:
- Implementa un Backend-For-Frontend (BFF): El cliente solo debe comunicarse con tus propios endpoints autenticados. Si necesitas usar OpenAI, crea un endpoint intermedio que gestione rate limiting, valide la sesión del usuario y llame a la API desde el servidor.
- Políticas de Seguridad de Contenido (CSP): Configura cabeceras HTTP
Content-Security-Policyestrictas para impedir que scripts no autorizados envíen datos a dominios externos:
Content-Security-Policy: default-src 'self'; script-src 'self'; connect-src 'self' https://api.stripe.com;
- Protección del archivo de configuración: Asegúrate de que los permisos de lectura de
wp-config.phpo.envestén restringidos al usuario del servidor web (chmod 600o640) y ubicados fuera del document root accesible por HTTP si la configuración del servidor lo permite.
La seguridad de un sitio en producción no es un checklist estático que se completa el día del lanzamiento. Exige observabilidad continua, validación de integridad en cada despliegue y una separación estricta entre la lógica de presentación y el manejo de credenciales privadas.
Si necesitas que revisemos tu código o sitio web, puedes contactarnos y te ayudamos a mejorar tu negocio digital