# Ficheiros de backup no webroot: .zip, .sql e .bak

> Qualquer pessoa pode descarregar ficheiros de backup no webroot. Como encontrar ficheiros .zip, .sql e .bak, bloqueá-los e verificar se foram consultados.

Fonte: https://phpsos.de/pt/blog/backup-dateien-im-webroot/  
Atualizado em: 25/10/2026  
Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**Em resumo:** Os ficheiros de backup no webroot, ou seja, dumps de bases de dados (`.sql`), arquivos (`.zip`, `.tar.gz`) e cópias de segurança (`.bak`, `.old`, `~`), podem ser descarregados por quem conheça ou adivinhe o nome do ficheiro. Procure regularmente esses ficheiros com `find`, mova as cópias de segurança para fora do diretório público, bloqueie extensões típicas no servidor web e verifique nos registos de acesso se já foram consultados.

## O backup que se torna uma fuga

Pouco antes de uma atualização, alguém cria ainda uma cópia de segurança à pressa: `backup.zip` no diretório principal, ao lado `datenbank.sql`. A atualização corre bem, os ficheiros ficam. Meses depois ainda lá estão, com todo o código, todos os dados de clientes e as credenciais do site.

Este padrão está entre os achados mais frequentes nas auditorias a servidores web. Não precisa de um exploit nem de uma falha no PHP. Um servidor web serve a partir do webroot o que lá estiver, e arquivos ou ficheiros SQL não os executa, oferece-os para descarregamento.

Um arquivo do site contém não só dados, mas também o código com a configuração. Quem o descarrega pode procurar vulnerabilidades à vontade e conhece as credenciais da base de dados.

Os scanners automatizados procuram de forma dirigida nomes típicos como `backup.zip`, `site.tar.gz` ou `dump.sql`, muitas vezes combinados com o nome de domínio ou uma data. Quem acredita que um nome de ficheiro invulgar protege subestima a sistematização com que esta pesquisa decorre.

## Que ficheiros estão em causa

Os ficheiros de backup no webroot surgem de várias formas:

| Tipo | Extensões típicas | O que contêm |
|---|---|---|
| Dumps de bases de dados | `.sql`, `.sql.gz`, `.dump` | dados de clientes, encomendas, hashes de palavras-passe, definições |
| Arquivos do site | `.zip`, `.tar`, `.tar.gz`, `.tgz`, `.rar`, `.7z` | todo o código, configuração, uploads |
| Cópias de ficheiros individuais | `.bak`, `.old`, `.orig`, `.save`, `.php~`, `.copy` | muitas vezes ficheiros de configuração com credenciais |
| Resíduos de editores | `.swp`, `.swo`, `~` no fim | partes de ficheiros que estavam a ser editados |
| Cópias de segurança de plugins | subpastas próprias no CMS | cópias completas, por vezes com nomes adivinháveis |

Particularmente delicadas são as cópias de ficheiros de configuração. O ficheiro original `config.php` é executado pelo servidor e o seu conteúdo permanece oculto. A cópia `config.php.bak` é entregue como texto, com a palavra-passe da base de dados.

## Encontrar backups no webroot: pesquisa no servidor

A pesquisa seguinte lista os ficheiros suspeitos abaixo dos webroots, com data e tamanho. Adapte os caminhos ao seu servidor:

```bash
find /var/www /srv/www -type f \( \
  -iname '*.sql' -o -iname '*.sql.gz' -o -iname '*.dump' -o \
  -iname '*.zip' -o -iname '*.tar' -o -iname '*.tar.gz' -o -iname '*.tgz' -o \
  -iname '*.rar' -o -iname '*.7z' -o \
  -iname '*.bak' -o -iname '*.old' -o -iname '*.orig' -o -iname '*.save' -o \
  -iname '*~' -o -iname '*.swp' \) \
  -printf '%TY-%Tm-%Td  %10s  %p\n' 2>/dev/null | sort
```

Nem todos os resultados são um problema. Alguns arquivos estão deliberadamente disponíveis para descarregamento, por exemplo manuais. Mas cada ficheiro merece uma decisão consciente. Atenção especial aos ficheiros grandes e às pastas de plugins de backup. Em alojamento partilhado sem acesso à shell, ajuda a vista de ficheiros do painel de alojamento ou uma consulta por SFTP.

> **Agir de imediato:**
> Se encontrar um dump de base de dados com dados de clientes no webroot, mova-o de imediato para fora do diretório público e guarde os registos de acesso antes de serem rodados. Só depois esclareça se o ficheiro foi consultado.

## O ficheiro já foi descarregado?

A resposta está nos registos de acesso do servidor web. Procuram-se consultas bem-sucedidas, ou seja, estado 200, aos ficheiros encontrados:

```bash
# Consultas bem-sucedidas a extensões de backup típicas (formato de registo combined)
zgrep -hE '\.(sql|sql\.gz|zip|tar|tgz|gz|bak|old|7z|rar)[ ?]' /var/log/nginx/access.log* \
  | awk '$9 == 200 {print $4, $1, $7, $10}'
```

A saída mostra o momento, o endereço, o caminho e o tamanho da resposta. Se o tamanho transferido corresponder ao tamanho do ficheiro, o ficheiro foi carregado por inteiro. Até quando os registos recuam depende da rotação. Se não chegarem à data de criação do ficheiro, não é possível excluir uma consulta anterior. Isto é descrito em pormenor em [Analisar os registos do servidor web após um ataque](https://phpsos.de/pt/ratgeber/logfiles-auswerten/). Sem acesso aos registos em bruto, por exemplo em alojamento partilhado, peça ao fornecedor os registos do período em causa.

Se um dump com dados pessoais foi consultado ou isso não pode ser excluído, começa a verificação de um dever de notificação. Os princípios são resumidos em [Dever de notificação segundo o RGPD: 72 horas após o incidente](https://phpsos.de/pt/compliance/dsgvo-meldepflicht-72-stunden/); a avaliação em cada caso cabe ao seu encarregado da proteção de dados. As credenciais de ficheiros consultados substitui-as em qualquer caso.

## Plugins de backup, painéis e mudanças

Muitos achados devem-se a plugins de backup de CMS e lojas. Guardam muitas vezes as cópias de segurança numa subpasta do webroot, por vezes com nomes compostos por data e domínio, que se podem adivinhar. Verifique em cada plugin três definições: para onde é guardada a cópia? As cópias locais são apagadas depois do envio para um destino externo? A pasta local está protegida contra acesso direto?

As cópias de segurança de painéis de alojamento ficam, em regra, fora do webroot, por exemplo no diretório home. O problema surge quando alguém copia uma cópia dessas para o webroot porque o descarregamento no navegador é mais cómodo do que por SFTP. Para mudanças aplica-se, por isso: transferência por SFTP ou diretamente entre os servidores, nunca através de um link público.

Se agências ou prestadores de serviços tratarem dos seus sites, esta regra deve constar também do contrato, com o dever de arrumar após os trabalhos de manutenção. Indicações em [Contratos com prestadores de serviços de TI: regular com clareza as obrigações de segurança](https://phpsos.de/pt/blog/dienstleistervertrag-sicherheit/).

## Prevenir de forma duradoura: local de armazenamento e bloqueios

Para que o problema não se repita, são precisos dois níveis. O primeiro é organizacional: as cópias de segurança têm um local fixo fora do webroot e, além disso, fora do servidor. Como é uma cópia de segurança robusta é descrito no guia [Estratégia de backup para servidores: backups segundo a regra 3-2-1](https://phpsos.de/pt/ratgeber/backups-3-2-1/).

O segundo nível é técnico: o servidor web recusa por princípio extensões de backup típicas, mesmo que um ficheiro acabe por ficar esquecido.

```nginx
location ~* \.(sql|sql\.gz|dump|bak|old|orig|save|swp|swo)$ {
    return 404;
}
location ~ ~$ {
    return 404;
}
```

Arquivos como `.zip` só devem ser bloqueados se o seu site não oferecer descarregamentos nesse formato, ou de forma dirigida nos diretórios em que não há descarregamentos. Ajudam ainda uma pesquisa automática regular com notificação e uma regra breve na equipa: nenhuma cópia de segurança ou cópia de ficheiro no webroot, nem por cinco minutos. Casos relacionados, como ficheiros de configuração ocultos, são tratados em [Proteger corretamente credenciais e ficheiros .env](https://phpsos.de/pt/blog/env-dateien-schuetzen/).

## Como ajuda concretamente a PHP SOS?

- Percorremos os seus webroots à procura de dumps, arquivos, cópias e cópias de segurança de plugins e avaliamos cada achado.
- Verificamos, com base nos registos de acesso, se os ficheiros foram consultados e documentamos o resultado para a sua avaliação de proteção de dados.
- Configuramos bloqueios no servidor web e uma pesquisa automática regular.
- Transferimos as cópias de segurança para um local protegido fora do webroot.

Estes trabalhos fazem parte do nosso [reforço de segurança de servidores para servidores web PHP](https://phpsos.de/pt/leistungen/server-haertung/).


## Perguntas frequentes

**Porque é que os backups vão parar ao webroot?**  
Normalmente por comodidade: gera-se um dump para uma mudança, um plugin guarda cópias de segurança na sua própria pasta, ou antes de uma alteração cria-se depressa uma cópia de um ficheiro com a extensão .bak. Depois, o ficheiro cai no esquecimento.

**Quão perigoso é um ficheiro como config.php.bak?**  
Muito. Um ficheiro com a extensão .php é executado pelo servidor e o seu conteúdo permanece oculto. Uma cópia com outra extensão, pelo contrário, é normalmente entregue pelo servidor como texto, com a palavra-passe da base de dados e as chaves.

**Um dump de base de dados acessível publicamente é uma violação de dados?**  
Se contiver dados pessoais e tiver sido consultado, ou se não for possível excluir uma consulta, pode ser aplicável um dever de notificação nos termos do RGPD. A avaliação em cada caso cabe ao seu encarregado da proteção de dados ou ao seu aconselhamento jurídico.

**Onde devem estar os backups em vez disso?**  
Fora do webroot e, além disso, fora do servidor, segundo a regra 3-2-1. Pelo menos uma cópia deve estar guardada de modo a que o próprio servidor web não a possa apagar nem alterar.

## Fontes

- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [RGPD Art. 33: notificação à autoridade de controlo](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [Documentação do Nginx](https://nginx.org/en/docs/)