Guías de seguridad
La base de seguridad para desarrolladores independientes y pequeños operadores: el conjunto estándar completo
Lista de comprobación de seguridad para desarrolladores independientes y pequeños operadores: MFA, higiene de secretos, monitoreo de CVE y copias de seguridad, en orden de prioridad (llaves del reino → secretos y código → app → recuperar).
Para: desarrolladores independientes y pequeños operadores que no tienen claro "cuánto es el mínimo" en seguridad. Aquí no hay pasos de ataque — solo la base considerada estándar del sector, en orden de prioridad. Cada elemento enlaza a un artículo más profundo, así que puedes empezar aquí y leer solo lo que necesites.
La visión de este sitio: no 'hacerlo todo' sino 'completar en este orden'
Una persona sola o un equipo pequeño no puede hacerlo todo a la vez — que es justo por lo que el orden lo es todo. Si la capa superior, las "llaves del reino", queda tomada, todo control por debajo deja de tener sentido (el atacante lo restablece todo como si fuera tú). Completa desde la base hacia arriba y reducirás al máximo tu probabilidad de incidente para el tiempo que tienes. Este artículo está escrito no como conocimiento exhaustivo sino como un mapa que te permite decidir al instante qué completar a continuación.
Nivel 0 — llaves del reino
MFA · dominio · DNS · correo · pago
Nivel 1 — secretos y código
secretos fuera de git · detección pre-commit · separación/rotación de claves
Nivel 2 — la propia app
validación de entrada · auth/sesión · TLS/encabezados · autenticación de correo
Nivel 3 — parchear, detectar, recuperar
CVE de dependencias · actualizaciones del SO · SSH/FW · registros · copias de seguridad
Nivel 0 — protege las llaves del reino (primero)
Esta es la premisa para todo lo demás. Si toman tu dominio, correo o panel de hosting, todos los demás controles quedan anulados. El atacante restablece contraseñas como si fuera tú, reescribe el DNS, entra a tu servidor. Así que esto es lo que blindas primero.
Pon MFA resistente al phishing
Trata el correo como la 'llave madre', protégelo con más fuerza
Guarda los códigos de recuperación y respaldo con seguridad
Separa cuentas para reducir puntos únicos de fallo
Nivel 1 — no filtres secretos ni código
El incidente fundacional de este sitio, y muchos en el mundo real, vienen de un hueco aquí: secretos como archivos .env y claves de API colándose en el código o en un repositorio público.
Mantén los secretos fuera del código y de la documentación
.env y exclúyelas de git (.gitignore). No escribirlas en absoluto es el control más fuerte.Detén los secretos por máquina antes del commit
Si se filtró, asume que se filtró TODO — rota todo
Acota los tokens estrictamente y mantenlos de corta vida
¿Autoalojas Git? Precaución extra
Autoalojar porque te asusta el "público accidental" de GitHub no elimina el commit accidental. Sin nada del bloqueo de secretos integrado de GitHub, un hook de secretos pre-commit es obligatorio en el autoalojamiento. Ver Git autoalojado vs GitHub: cuál es más seguro.
Nivel 2 — endurece la propia app
El mínimo para la aplicación web que expones. El objetivo no es detener ataques novedosos sino cerrar los agujeros comunes y bien conocidos. Este sitio reformula cada uno como defensa en sus páginas de glosario.
Nunca confíes en la entrada (cierra los agujeros clásicos)
Acierta con auth, sesión y acceso
Haz que TLS y los encabezados de seguridad cuenten
Previene la suplantación de correo
Nivel 3 — parchear, detectar, recuperar
La base para "mantener el daño pequeño y recuperar rápido incluso tras una brecha". El monitoreo de dependencias como osv-scanner vive aquí.
Monitorea por máquina los CVE de dependencias de forma continua
Actualiza automáticamente el SO y el servidor
Endurece SSH y el cortafuegos
Privilegio mínimo para reducir el radio de la explosión
Copias de seguridad 3-2-1 + una restauración probada
Conserva registros para poder notar anomalías
Por dónde empezar
"Todo, ya mismo" no es realista. Compara el orden que la gente tiende a tomar con el que recomienda este sitio.
El orden que la gente tiende a tomar (ineficiente)
- empezar con trabajo llamativo de vulnerabilidades de aplicación
- dejar el MFA en "luego" indefinidamente
- tener copias de seguridad pero nunca haber probado una restauración
- los secretos están en
.envpero no hay hook de detección
El orden que recomienda este sitio
- Nivel 0: bloquea primero las llaves del reino (MFA, correo, dominio)
- Nivel 1: detén estructuralmente las fugas de secretos (detección pre-commit + política de rotar todo)
- Nivel 2: cierra los agujeros clásicos de la app
- Nivel 3: llega a "recuperable" con monitoreo de dependencias, actualizaciones y copias con restauración probada
Este sitio también se defiende en este orden
Este sitio aplica esta misma base a sí mismo: un servidor dedicado sin co-tenencia (separación del radio de la explosión) / una clave distinta por servidor / secretos nunca en git ni en documentación / monitoreo de CVE de dependencias antes de cada despliegue y a diario / copias de seguridad externas a un servidor aparte / solicitudes externas a través de un límite de seguridad. Un sitio que enseña seguridad no puede tener agujeros propios — así que ejecutamos este orden de prioridad sobre nosotros mismos primero. Nuestro incidente fundacional, también, no vino de un ataque novedoso sino de un único hueco en esta base. Por eso seguimos diciéndolo: la base antes del trabajo llamativo.
Sigue leyendo
- Versión para organización / equipo: la base de seguridad para organizaciones medianas y grandes
- Autoalojamiento: Git autoalojado vs GitHub: cuál es más seguro
- Dependencias: instalar y usar osv-scanner · no quedarse atrás con los CVE
- Secretos: archivos .env y secretos · incidente una clave filtrada y facturada por fraude
- Herramientas: comprobación de encabezados de seguridad · comprobador de autenticación de correo · consulta de CVE/KEV
FAQ
Q¿Cuál es el primer control de seguridad que debería configurar un desarrollador independiente?
Proteger las 'llaves del reino': pon MFA resistente al phishing (passkeys/llaves de hardware) en tu registrador de dominios, DNS, panel de hosting, correo y cuentas de pago. Si los toman, todos los demás controles quedan anulados — así que van primero.
Q¿Son todos los controles de la base igual de importantes?
No. Hay un orden claro. Este sitio recomienda completarla así: 1) llaves del reino, 2) secretos y código, 3) la propia app, 4) parchear/detectar/recuperar. Con recursos finitos, de arriba abajo reduce más los incidentes.
Q¿Cuenta el monitoreo de CVE de dependencias como base?
Sí. Verificar de forma continua y por máquina las dependencias en busca de vulnerabilidades conocidas con osv-scanner o pnpm audit es ya un estándar del sector. La mayoría de las brechas graves vienen de agujeros conocidos (CVE) descuidados, no de ataques novedosos.