Segurança do Ruby on Rails — uma referência de hardening de produção

Para: qualquer pessoa que opere um app Ruby on Rails. Sem passos de ataque aqui — esta é uma referência de trabalho para hardening: um checklist ordenado por prioridade, orientação por área e autoverificação. Para o panorama entre frameworks, veja o hub de segurança por framework.

Checklist de hardening ordenado por prioridade

Faça esta tabela de cima para baixo. P0 é um pré-requisito, P1 é a fonte mais frequente de incidentes, P2 é higiene operacional contínua.

1. Segredos e credentials (P0)

• Use as credentials criptografadas do Rails e não faça commit do master key (a chave de descriptografia) no repositório (injete via env, etc.).
• secret_key_base é a base dos cookies assinados/criptografados e das sessões. Rotacione prontamente se vazar (note que isso invalida as assinaturas/criptografia existentes).
• Não deixe .env, dumps ou backups em um diretório público (→ mantenha segredos fora dos diretórios públicos).

2. Config de produção (P0)

• Em produção, não exponha detalhes de exceção (não habilite consider_all_requests_local, etc.) — reduza a divulgação da estrutura interna.
• config.force_ssl para forçar HTTPS e marcar os cookies como secure. Não habilite ferramentas de dev como o web console em produção.
• Use filter_parameters para manter senhas e afins fora dos logs.

3. CVEs de gems (dependências) (P0)

• Monitore por máquina os CVEs de gems com bundler-audit ou osv-scanner, julgue pela versão em execução (Gemfile.lock) e corrija rápido (→ monitorar CVEs de dependências · o manual de resposta a vulnerabilidades).
• Mantenha o Rails e o Ruby em versões suportadas e não deixe versões EOL no lugar.

4. Strong Parameters e Mass Assignment (P1)

• Mantenha os campos do permit no mínimo e evite o permit! (permitir tudo).
• 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."

5. Autorização (P1 — a principal fonte)

Veja o que é IDOR. Autenticação e autorização diferem; autorize perto dos dados.

6. Injeção e métodos dinâmicos perigosos (P2)

• SQL: faça bind com placeholders em where; nunca construa queries por concatenação de string (evite where("... #{params}")) (→ o que é injeção de SQL).
• Métodos dinâmicos perigosos: não passe entrada do usuário a send/public_send/constantize. Se precisar, restrinja rigorosamente com uma allowlist.
• Desserialização: evite carregar YAML/Marshal não confiável (pode levar à execução de código sob as condições certas).

7. Sessões, cookies, CSRF (P2)

• Não desabilite globalmente a proteção CSRF (protect_from_forgery); use o token do formulário (→ o que é CSRF).
• Defina secure/httponly/samesite nos cookies/sessões e regenere a sessão no login.

8. SSRF, uploads, headers (P2)

• A busca server-side de URLs fornecidas pelo usuário deve restringir os alvos a uma allowlist e bloquear o alcance a IPs internos/metadados (→ o que é SSRF).
• Valide os uploads (tipo/tamanho), armazene fora de public/ e não conceda permissão de execução.
• Adicione headers de segurança (verifique o seu próprio site com o verificador de headers de segurança).

Verifique: o seu Rails está realmente protegido?

Construir não é o fim — só está pronto quando você verificou. Estas são autoverificações defensivas contra o seu próprio ambiente.

Leia a seguir

• Hub: segurança por framework · segurança do Laravel (mesmo MVC, forma de autorização parecida)
• Prática: o manual de resposta a vulnerabilidades · monitorar CVEs de dependências · mantenha segredos fora dos diretórios públicos
• Glossário: o que é IDOR · injeção de SQL · CSRF · SSRF
• Ferramentas: verificador de headers de segurança