Seguridad web sin paranoia: los 5 problemas que vemos repetidos en PyMEs

La conversación sobre seguridad en software arranca casi siempre con un PDF de OWASP Top 10 y termina en parálisis: hay tantas cosas para revisar que el equipo decide "lo vemos después". Y "después" suele ser cuando ya hay un problema.

Vamos a ir al revés. Estos son los 5 problemas concretos que vemos repetidos en proyectos de PyMEs que ya estaban en producción. Si cubris estos 5, estas mejor que el 90% de las webapps que circulan.

1. Validación solo en el frontend

El error más común. El formulario tiene validación en JavaScript del lado del cliente: "este campo es obligatorio", "el mail tiene que tener arroba", etc. Y el backend asume que los datos llegan bien.

El problema: cualquier persona con curl, Postman o las dev tools del navegador puede mandar lo que quiera al backend, salteandose la validación del frontend.

Lo que tenés que hacer: toda validación crítica DEBE estar también en el backend. El frontend válida para mejorar UX (que el usuario vea errores rápido). El backend válida para mejorar seguridad (que la base de datos no reciba basura).

En proyectos como Mi Seguro de Auto, donde se procesan datos personales y se cotizan pólizas reales, cada campo se válida dos veces: en el cliente para feedback inmediato, en el servidor para confianza.

2. Secretos hardcodeados en el código

Pasamos por esto en auditorías más veces de las que quisiera. API keys, contraseñas de base de datos, tokens de servicios, todo dentro del repositorio en archivos como config.js o constants.ts.

Eso es un problema doble: cualquiera con acceso al código (incluyendo developers que ya no están en la empresa) tiene acceso a los sistemas. Y si el repo se filtra alguna vez (sucede más seguido de lo que se cree), los secretos quedan públicos.

Lo que tenés que hacer:

• Todas las credenciales en variables de entorno (.env).
• .env en .gitignore siempre.
• Un .env.example con las variables sin valores reales.
• Para producción, usar el secret manager del proveedor (Vercel, AWS Secrets Manager, etc).
• Rotar credenciales cuando alguien deja el equipo.

3. Sin Row Level Security en bases multi-tenant

Si tu aplicación tiene varios clientes/usuarios que NO deben ver datos de otros, el aislamiento NO puede depender solo del filtro en el código de la aplicación.

Típico: una consulta que dice WHERE user_id = ? y se trustea que el código siempre pone el ID correcto. Una vulnerabilidad de IDOR (insecure direct object reference) o un bug en cualquier endpoint puede dejar que un usuario vea datos de otro.

Lo que tenés que hacer: configurar Row Level Security a nivel base de datos. En Postgres (y por ende en Supabase) se hace con políticas RLS que se aplican automáticamente. La base de datos NO devuelve filas que no correspondan al usuario actual, sin importar como está escrita la query.

Es una capa de defensa extra que vale oro. Si un endpoint olvida el filtro o un atacante logra ejecutar una query inesperada, RLS sigue protegiendo los datos.

4. Autenticación casera

"Hicimos nuestro propio sistema de auth porque tener todo bajo nuestro control es más seguro". Es el camino más rápido para tener un problema serio.

Hacer auth bien (hashing de passwords con argon2 o bcrypt y sus salts, tokens JWT con rotación, recuperación segura de password, prevención de timing attacks, rate limiting de intentos) lleva semanas y rara vez sale bien la primera vez.

Lo que tenés que hacer: usar un proveedor maduro. Supabase Auth, Auth0, Clerk, NextAuth/Auth.js. Todos resuelven los casos difíciles y se mantienen al día con las mejores prácticas. Tu código solo orquesta, no implementa criptografia.

5. Logs con información sensible

Cuando algo falla en producción, el primer instinto es loguear todo el contexto. Y entre ese contexto suelen aparecer: contraseñas en plano (porque venían en el body de la request), tokens, datos de tarjetas, números de documento.

Esos logs terminan en herramientas como Sentry, Datadog o CloudWatch, accesibles por más gente de la que debería, y persisten meses.

Lo que tenés que hacer:

• Tener una lista de campos sensibles que NUNCA se loguean (password, token, creditCard, ssn, dni).
• Sanitizar antes de loguear: reemplazar valores sensibles por *** automáticamente.
• Revisar periódicamente los logs para detectar fugas.

Lo que NO esta en esta lista (a propósito)

OWASP tiene cosas más avanzadas: cross-site scripting, SQL injection, deserialización insegura, etc. Son importantes, pero la realidad es que los frameworks modernos (React, Next.js, ORMs como Prisma) cubren esos vectores por defecto si no te peleas activamente con ellos. Para una PyME que arranca, los 5 puntos de arriba dan mucho más ROI de seguridad que pelearse con CSRF cuando ya estas usando Next.js bien configurado.

Conclusión

La seguridad no es un proyecto, es una costumbre. Si cubris los 5 puntos al desarrollar, repasas anualmente, y mantenes las dependencias actualizadas, estas en buena forma. Si nunca pensaste en ninguno y tenés algo en producción procesando datos de clientes, vale la pena una revisión.

Si querés una auditoría pragmática de tu aplicación (no un PDF de 80 páginas, un informe con cosas concretas para arreglar y orden de prioridad), escribinos.

---

Por Esteban Aleart, Founder & Lead Engineer de Pair Programming.