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

Por framework

#Laravel#framework#misconfiguration#access control

Segurança do Laravel — exposição de .env, APP_DEBUG e autorização

As três grandes armadilhas de segurança do Laravel — .env exposto a partir do diretório público, APP_DEBUG ligado em produção e autorização ausente (IDOR / Mass Assignment) — e como fechar cada uma. Defensivo, sem passos de ataque.

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

Para: qualquer pessoa que opere um app Laravel. Sem passos de ataque aqui — só os três grandes incidentes operacionais e como fechá-los. Para o panorama completo, veja o hub de segurança por framework.

As três grandes armadilhas (onde os padrões não te salvam)

O escapamento e a autenticação do Laravel são excelentes, mas estas três são suas para fechar.

① Segredos expostos

.env, backups ou chaves acessíveis por URL a partir de public/. Um deslize de posicionamento = vazamento instantâneo.

② Debug ligado em produção

APP_DEBUG=true expõe variáveis de ambiente e informações de conexão na página de erro. Extraídas via erros deliberados.

③ Autorização ausente

Autenticado, mas sem escopo de proprietário (IDOR) / Mass Assignment sobrescrevendo is_admin, etc.

Os três incidentes mais comuns ao operar o Laravel — todos fora dos padrões.

Como fechá-las (3 passos)

1

Mova segredos para fora do diretório público (permissão 600)

O Laravel já mantém o .env fora da raiz do documento, mas não deixe cair backups, exports ou arquivos de chave em public/ por acidente. Mantenha segredos fora da raiz do app com permissão 600 (só do proprietário). (→ mantenha segredos fora dos diretórios públicos · um caso completo de exposição de .env)
2

Desative o debug + cacheie a config em produção

Garanta APP_DEBUG=false e APP_ENV=production. Fixe isso com um cache de config e impeça que erros detalhados apareçam externamente. Embuta nos passos de deploy e verifique toda vez.
3

Construa a autorização (Policy/Gate + $fillable)

Não pare em "logado significa permitido." Implemente verificações de propriedade com Policy/Gate e dê escopo a cada leitura/atualização/exclusão por user_id, etc. Para o Mass Assignment, declare $fillable para evitar que campos não intencionais sejam sobrescritos. (→ o que é IDOR)

Comum (perigoso)

  • backups ou chaves colocados em public/, acessíveis por URL
  • produção deixada em APP_DEBUG=true
  • sem autorização — "logado = pode ver"
  • Model::create($request->all()) aceitando todos os campos

Correto

  • segredos fora da raiz do documento com permissão 600
  • produção com debug desligado + cache de config
  • escopo de proprietário com Policy/Gate
  • declarar $fillable para bloquear o Mass Assignment

A visão deste site: sólido até os padrões; a autorização é sua responsabilidade

O Laravel tem muitos bons padrões, mas a autorização — quem pode fazer o quê — é específica do app, então nenhum framework consegue protegê-la automaticamente. Os incidentes que continuamos vendo são menos SQLi ou XSS do que o tipo "autenticado, mas sem verificação de propriedade". Então o centro de gravidade não é configuração chamativa, mas o trabalho sem glamour de dar escopo a cada leitura/atualização por proprietário. Some a isso manter segredos fora da superfície pública e desligar o debug em produção, e você previne a maioria dos incidentes reais do Laravel com essas três.

Leia a seguir

FAQ

QO Laravel é um framework seguro?
A

O Laravel entrega muitos padrões seguros (escapamento, autenticação) e é razoavelmente sólido de saída. Mas 'padrões seguros' e 'operação segura' são coisas diferentes, e os incidentes reais não vêm do núcleo, mas da configuração e da operação. .env/segredos expostos, debug deixado ligado em produção e autorização rasa são áreas que o framework não cobre por você. Você não pode confiar só nos padrões — precisa fechar essas três por conta própria.

QO que é perigoso em publicar com APP_DEBUG=true?
A

Com o debug ligado, uma página de erro pode mostrar não só um stack trace, mas segredos internos como variáveis de ambiente e informações de conexão. Um atacante pode provocar erros de propósito para extraí-los. Em produção, sempre defina APP_DEBUG=false e cacheie a configuração (config cache) para fixar isso, e impeça que erros detalhados sejam mostrados externamente.

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

Isso é autenticação sem autorização. Mesmo logado, se os dados não têm escopo por usuário (por user_id, etc.), trocar o ID na URL pode revelar os dados de outra pessoa (IDOR). No Laravel, implemente verificações de propriedade com Policy/Gate e declare $fillable para o Mass Assignment, evitando que campos não intencionais sejam sobrescritos.