Por framework
Seguridad en Ruby on Rails — una referencia de endurecimiento para producción
Una referencia de endurecimiento para producción de Ruby on Rails: una lista de verificación por prioridad más secretos/credentials, configuración, CVE de gems, Strong Parameters, autorización, inyección y SSRF. Defensiva, sin pasos de ataque.
Para: cualquiera que gestione una aplicación Ruby on Rails. Aquí no hay pasos de ataque — esta es una referencia de trabajo para el endurecimiento: una lista de verificación ordenada por prioridad, guía por área y autoverificación. Para el panorama entre frameworks, consulta el centro de seguridad por framework.
Lista de endurecimiento ordenada por prioridad
Recorre esta tabla de arriba abajo. P0 es un prerrequisito, P1 es la fuente más frecuente de incidentes, P2 es higiene operativa continua.
P0 ── Prerrequisito (hazlo primero)
Gestión de secretos y credentials / configuración de producción (sin exposición de excepciones, force_ssl) / CVE de gems parcheados rápido
P1 ── Principal fuente de incidentes
Control de Strong Parameters/Mass Assignment / autorización (alcance de propietario)
P2 ── Higiene operativa
Inyección y métodos peligrosos / sesiones, CSRF / SSRF, subidas
| Prioridad | Control | Detalles (Rails) |
|---|---|---|
| P0 | Secretos y credentials | Credentials cifradas + master key separada. No incluyas la master key en el repositorio. Rota secret_key_base si se filtra |
| P0 | Configuración de producción | No expongas el detalle de las excepciones; config.force_ssl; filter_parameters para mantener los secretos fuera de los logs |
| P0 | CVE de gems (dependencias) | Monitoriza con bundler-audit / osv-scanner; juzga por la versión en ejecución, parchea rápido |
| P1 | Strong Parameters | Mantén permit al mínimo. No uses permit!. Nunca asignes un campo de privilegio |
| P1 | Autorización explícita | Pundit / CanCanCan + authorize + acotar por current_user para la propiedad |
| P2 | Inyección/métodos peligrosos | Usa binding en where. No pases entrada a send/constantize. No cargues YAML/Marshal no confiables |
| P2 | Sesiones/CSRF | protect_from_forgery (por defecto), cookie secure/httponly/samesite, regenerar al iniciar sesión |
| P2 | SSRF/subidas | Lista de permitidos para las peticiones del lado del servidor + bloquear IPs internas. Valida las subidas, almacénalas fuera de public/ |
1. Secretos y credentials (P0)
- Usa las credentials cifradas de Rails, y no incluyas la master key (de descifrado) en el repositorio (inyéctala mediante variables de entorno, etc.).
secret_key_basesustenta las cookies y sesiones firmadas/cifradas. Rótala de inmediato si se filtra (ten en cuenta que esto invalida las firmas/cifrados existentes).- No dejes
.env, volcados ni copias de seguridad en un directorio público (→ mantén los secretos fuera de los directorios públicos).
2. Configuración de producción (P0)
- En producción, no expongas el detalle de las excepciones (no habilites
consider_all_requests_local, etc.) — reduce la divulgación de la estructura interna. config.force_sslpara forzar HTTPS y marcar las cookies como secure. No habilites herramientas de desarrollo como la consola web en producción.- Usa
filter_parameterspara mantener las contraseñas y similares fuera de los logs.
3. CVE de gems (dependencias) (P0)
- Monitoriza de forma automática los CVE de gems con bundler-audit u osv-scanner, juzga por la versión en ejecución (Gemfile.lock) y parchea rápido (→ monitorizar los CVE de dependencias · el manual de respuesta a vulnerabilidades).
- Mantén Rails y Ruby en versiones con soporte y no dejes versiones EOL en su sitio.
4. Strong Parameters y Mass Assignment (P1)
- Mantén los campos de
permital mínimo, y evitapermit!(permitir todo). - Nunca asignes un campo de privilegio como
is_admindesde la entrada del usuario. Descarta el «permitir de forma amplia porque es cómodo».
5. Autorización (P1 — la principal fuente)
Común (peligroso)
- sin autorización — «con sesión iniciada = puede ver/actualizar»
- el binding ruta-modelo recupera el ID de otro usuario
- confiar en rutas ocultas / IDs difíciles de adivinar
- olvidar
authorizeen algunas acciones
Correcto
- política explícita con Pundit / CanCanCan +
authorizepor acción - las lecturas también se acotan al propietario con
current_user - verificado en cada ruta de lectura/actualización/borrado
- autorización construida explícitamente, no dejada a los valores por defecto
Consulta qué es el IDOR. La autenticación y la autorización son distintas; autoriza cerca de los datos.
6. Inyección y métodos dinámicos peligrosos (P2)
- SQL: usa binding con placeholders en
where; nunca construyas consultas por concatenación de cadenas (evitawhere("... #{params}")) (→ qué es la inyección SQL). - Métodos dinámicos peligrosos: no pases entrada del usuario a
send/public_send/constantize. Si debes hacerlo, restringe estrictamente con una lista de permitidos. - Deserialización: evita cargar
YAML/Marshalno confiables (puede llevar a la ejecución de código en las condiciones adecuadas).
7. Sesiones, cookies, CSRF (P2)
- No deshabilites globalmente la protección CSRF (
protect_from_forgery); usa el token de formulario (→ qué es el CSRF). - Establece secure/httponly/samesite en las cookies/sesiones, y regenera la sesión al iniciar sesión.
8. SSRF, subidas, cabeceras (P2)
- La obtención del lado del servidor de URLs proporcionadas por el usuario debe restringir los destinos a una lista de permitidos y bloquear el alcance a IPs internas/metadatos (→ qué es el SSRF).
- Valida las subidas (tipo/tamaño), almacénalas fuera de
public/y no concedas permiso de ejecución. - Añade cabeceras de seguridad (comprueba tu propio sitio con el verificador de cabeceras de seguridad).
Verifica: ¿está tu Rails realmente endurecido?
Construirlo no es el final — solo está hecho una vez que lo has comprobado. Estas son autocomprobaciones defensivas contra tu propio entorno.
Los secretos no están expuestos/incluidos
master.key no está en el repositorio, y que .env/volcados no se pueden obtener por URL.Sin detalle de excepciones en producción
La autorización se sostiene
Dependencias y cabeceras
bundler-audit/osv está limpio, y que HTTPS/HSTS están presentes mediante el verificador de cabeceras.La opinión de este sitio: aun protegido por convenciones, la autorización y las dependencias dependen de ti
Los buenos valores por defecto de Rails eliminan mucho riesgo, pero la autorización — quién puede hacer qué — y la frescura de las dependencias son específicas de cada aplicación y operación, así que un framework no puede protegerlas automáticamente. Los incidentes que seguimos viendo son menos ataques elaborados que del tipo «autenticado pero sin comprobación de propiedad». Por eso el centro de gravedad es trabajar la tabla de arriba de arriba abajo — ajusta Strong Parameters, haz la autorización explícita y monitoriza los gems en busca de CVE.
Lee a continuación
- Centro: seguridad por framework · seguridad en Laravel (mismo MVC, forma de autorización similar)
- Práctica: el manual de respuesta a vulnerabilidades · monitorizar los CVE de dependencias · mantén los secretos fuera de los directorios públicos
- Glosario: qué es el IDOR · inyección SQL · CSRF · SSRF
- Herramientas: verificador de cabeceras de seguridad
FAQ
Q¿Qué debo hacer primero para asegurar Rails?
Los tres elementos P0: (1) gestionar los secretos de forma segura (mantén las credentials cifradas separadas de la master key, no incluyas la master key en el repositorio; secret_key_base sustenta las cookies firmadas/cifradas, así que rótala si se filtra); (2) reforzar la configuración de producción (no expongas el detalle de las excepciones; force_ssl); (3) monitorizar de forma automática los CVE de gems (dependencias) y parchear rápido, juzgando por la versión en ejecución. Luego, pasa a Strong Parameters y a la autorización.
Q¿Qué debo vigilar con Strong Parameters?
Permite (permit) explícitamente qué campos aceptas para evitar el Mass Assignment (asignación masiva de campos no previstos). El peligro es permitir de forma amplia por comodidad, y usar permit! para permitir todo. Mantén los campos permitidos al mínimo, y nunca dejes que un campo de privilegio como is_admin se asigne desde la entrada del usuario.
Q¿Cómo implemento la autorización de forma segura?
Además del inicio de sesión (autenticación), implementa una comprobación de propiedad de que el objetivo pertenece realmente al usuario. Haz la política explícita con Pundit/CanCanCan, ejecuta authorize en cada acción y acota los recursos por current_user. No confíes en rutas ocultas ni en IDs difíciles de adivinar — verifica explícitamente en cada ruta de lectura/actualización/borrado.
Q¿Cómo gestiono las vulnerabilidades de gems (dependencias)?
Monitoriza de forma automática los CVE conocidos con bundler-audit u osv-scanner y parchea rápido, juzgando por la versión en ejecución (decide según la versión real en Gemfile.lock). Mantén Rails y Ruby en versiones con soporte y no dejes versiones EOL en su sitio. La frescura de las dependencias es un factor más realista en los incidentes que los ataques elaborados.
Q¿Cuáles son los métodos dinámicos peligrosos?
Pasar entrada del usuario a send / public_send / constantize puede llevar a llamadas de métodos o resolución de clases no previstas. Del mismo modo, cargar mediante Marshal o YAML no confiable (restaurar objetos) puede, en las condiciones adecuadas, llevar a la ejecución de código. No pases datos derivados del usuario a estos; si debes hacerlo, restringe estrictamente con una lista de permitidos.