Pular para o conteúdo
>_ITDITDPlataforma de Segurança Web

Por framework

#Rails#framework#access control#dependency management

Segurança do Ruby on Rails — Strong Parameters, autorização e CVEs de gems

O Rails tem padrões seguros, mas os incidentes vêm da operação: Strong Parameters permissivo demais (Mass Assignment), autorização rasa (autenticação ≠ autorização) e CVEs conhecidos de gems. Aperte o permit, torne a autorização explícita, monitore CVEs de gems. Defensivo, sem passos de ataque.

Publicado 2026-07-02 Atualizado 2026-07-02 4 min de leitura

Para: qualquer pessoa que opere um app Ruby on Rails. Sem passos de ataque aqui — só manter os padrões seguros funcionando enquanto fecha as lacunas que a operação abre. Para o panorama completo, veja o hub de segurança por framework.

As três grandes armadilhas (elas se abrem quando você sai dos padrões)

Os padrões do Rails são excelentes, mas estas três são suas para proteger deliberadamente.

① Mass Assignment

Permita de forma ampla demais e is_admin, etc. são sobrescritos inesperadamente.

② Autorização rasa

Autenticado, mas sem escopo de proprietário. Troca de ID revela os dados de outros (IDOR).

③ CVEs conhecidos de gems

Falhas de gems-dependências deixadas sem correção. Avalie pela versão em execução, corrija rápido.

Os três buracos com maior chance de se abrir ao operar o Rails — todos fora dos padrões.

Fique atento também a SQLi via interpolação de string em where, passar entrada do usuário a métodos dinâmicos perigosos (send/constantize) e vazar credentials/secret_key_base.

Como fechá-las (3 passos)

1

Mantenha os Strong Parameters mínimos

Permita apenas os campos de que você realmente precisa e nunca atribua um campo de privilégio como is_admin a partir da entrada do usuário. Abandone o "permitir de forma ampla porque é conveniente."
2

Torne a autorização explícita

Não pare no login (autenticação); dê escopo aos recursos por current_user e torne a política explícita com Pundit / CanCanCan. Verifique a propriedade em cada leitura/atualização/exclusão (→ o que é IDOR).
3

Monitore CVEs de gems (dependências) e corrija rápido

Avalie as vulnerabilidades de gems-dependências pela versão em execução, detecte cedo com monitoramento por máquina e corrija rápido (→ o manual de resposta a vulnerabilidades). E use placeholders em where, nunca interpolação de string.

Comum (perigoso)

  • Strong Parameters permitidos de forma ampla (Mass Assignment)
  • sem autorização — "logado = pode ver"
  • CVEs conhecidos de gems deixados sem correção
  • where("... #{params}") interpolação de string

Correto

  • permit mantido mínimo
  • autorização explícita (current_user/Pundit)
  • gems com CVEs monitorados + corrigidos rápido
  • where com placeholders

A visão deste site: mesmo protegido por convenções, a autorização e as dependências são sua responsabilidade

Os bons padrões do Rails apagam muito risco, mas a autorização — quem pode fazer o quê — e o frescor das dependências são as duas coisas que um framework não consegue proteger automaticamente. Os incidentes que continuamos vendo são menos ataques elaborados do que o tipo "autenticado, mas sem verificação de propriedade". Então o centro de gravidade é apertar os Strong Parameters, tornar a autorização explícita e monitorar os gems por CVEs. Por mais sem glamour que sejam, essas três previnem a maioria dos incidentes reais do Rails.

Leia a seguir

FAQ

QO Ruby on Rails é um framework seguro?
A

O Rails segue 'convenção sobre configuração' e entrega muitos padrões seguros — proteção CSRF, Strong Parameters e proteção de SQL baseada em ORM são padrão. Usado corretamente é um framework sólido, mas sair dos padrões ou pular o trabalho necessário abre brechas. Strong Parameters permissivo demais, autorização rasa e CVEs de gems (dependências) sem correção recorrem menos como problemas específicos do Rails e mais como problemas operacionais.

QCom o que devo me preocupar nos Strong Parameters?
A

Os Strong Parameters permitem explicitamente (permit) quais campos você aceita, para prevenir o Mass Assignment (atribuição em massa de campos não intencionais). O perigo é permitir de forma ampla por conveniência. Mantenha os campos permitidos no mínimo e nunca deixe um campo de privilégio como is_admin ser atribuído a partir da entrada do usuário.

QPor que 'se você está logado, pode ver' é perigoso?
A

Isso é autenticação sem autorização. O Rails fornece o mecanismo de login (autenticação), mas se os dados realmente pertencem àquele usuário é autorização específica do app que você precisa escrever. Se você pular o escopo dos recursos por current_user ou tornar a política explícita com Pundit/CanCanCan, trocar o ID na URL pode revelar os dados de outro usuário (IDOR).