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 mantenimiento continuo.
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 ── Mantenimiento continuo
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 con valores por defecto seguros, la autorización y las dependencias son responsabilidad tuya
Los buenos valores por defecto de Rails eliminan mucho riesgo, pero la autorización — quién puede hacer qué — y mantener las dependencias al día 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 lo prioritario es recorrer la tabla de arriba desde el principio: 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, problemas de autorización similares)
- 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
Fuentes y alcance
Estas fuentes primarias respaldan los ajustes, el alcance o las medidas anteriores; enlaces comprobados el 23 de octubre de 2026. Revisa sus condiciones de versión y configuración. Las prioridades y lecciones son recomendaciones del sitio, no una revalidación completa ni una garantía de seguridad.