# Superglobais: $_GET, $_POST, $_FILES e outras

> Superglobais do PHP: o que contêm $_GET, $_POST, $_FILES e $_SERVER, como o PHP as preenche antes do seu código e como usar os dados em segurança.

Fonte: https://phpsos.de/pt/php/superglobals/  
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:** As superglobais são arrays predefinidos que o PHP preenche automaticamente a cada pedido e que estão disponíveis em todo o código. O `$_GET` contém os parâmetros do endereço, o `$_POST` os dados do formulário, o `$_FILES` os ficheiros carregados, o `$_COOKIE` os cookies e o `$_SERVER` indicações sobre o pedido e o servidor. O PHP cria estes arrays antes de o código da sua aplicação arrancar. Por isso, as falhas precisamente neste processamento, como no PHP2Shell, não podem ser travadas por verificações na aplicação.

## O que são superglobais?

No PHP, uma variável normalmente só vale na função em que foi criada. As superglobais são a exceção: estão disponíveis em qualquer âmbito, sem ser preciso obtê-las com `global`. O manual do PHP refere nove.

Para quem não é técnico, pode descrever-se assim: as superglobais são a caixa de correio da aplicação. Tudo o que um visitante envia vai parar lá antes de a aplicação o ler. E tudo o que está na caixa de correio provém potencialmente de um desconhecido.

## As superglobais em resumo

| Superglobal | Conteúdo | Origem |
|---|---|---|
| `$_GET` | parâmetros do endereço (query string) | cliente |
| `$_POST` | campos de formulário de um pedido POST | cliente |
| `$_FILES` | indicações sobre ficheiros carregados | cliente, tratadas pelo PHP |
| `$_COOKIE` | cookies enviados pelo navegador | cliente |
| `$_REQUEST` | mistura de GET, POST e, se for o caso, cookies | cliente |
| `$_SERVER` | cabeçalhos do pedido, método, caminhos, dados do servidor | servidor web e cliente misturados |
| `$_ENV` | variáveis de ambiente | servidor |
| `$_SESSION` | dados da sessão atual | armazenamento do servidor |
| `$GLOBALS` | todas as variáveis globais | script |

Particularmente traiçoeiro é o `$_SERVER`. Segundo o manual, o PHP cria para cada cabeçalho do pedido uma entrada que começa por `HTTP_`, por exemplo `HTTP_USER_AGENT`. Estes valores são definidos pelo próprio cliente. Também o `SERVER_NAME` pode, segundo o manual, conter o nome de anfitrião fornecido pelo cliente e não é fiável para decisões de segurança.

## Como o PHP preenche as superglobais

Antes de o primeiro carácter do seu script ser executado, o PHP já trabalhou. Lê o endereço, os cabeçalhos e o conteúdo do pedido, decompõe-os e guarda os resultados nos arrays. Várias definições controlam este passo:

1. **`variables_order`** (por defeito `EGPCS`) determina que superglobais são sequer criadas: Environment, GET, POST, Cookie, Server.
2. **`request_order`** (por defeito vazio) determina de onde é formado o `$_REQUEST`. Se estiver vazio, vale `variables_order`. Os ficheiros php.ini fornecidos omitem os cookies, segundo o manual, por razões de segurança.
3. **`max_input_vars`** (por defeito `1000`) e **`max_input_nesting_level`** (por defeito `64`) limitam o número e o encadeamento das variáveis de entrada.
4. **`post_max_size`** (por defeito `8M`) limita o conteúdo do pedido. Se um pedido for maior, `$_POST` e `$_FILES` ficam vazios.
5. **`enable_post_data_reading`** (por defeito ligado) controla se o PHP avalia sequer automaticamente o conteúdo dos pedidos POST.

Se `enable_post_data_reading` estiver desligado, a aplicação lê ela própria o conteúdo bruto através de `php://input`. Desde o PHP 8.4.0 existe ainda o `request_parse_body()`, que avalia dados de formulário e de upload também para outros métodos que não o POST e permite valores-limite próprios. Como decorre em pormenor a parte dos uploads explica-o a página [Como o PHP processa os uploads de ficheiros](https://phpsos.de/pt/php/datei-uploads-intern/).

## Lidar com segurança com os dados do pedido

O princípio é simples: cada valor de `$_GET`, `$_POST`, `$_COOKIE`, `$_FILES` e das entradas `HTTP_` de `$_SERVER` é uma entrada alheia. É verificado na receção e escapado de forma adequada na saída.

```php
<?php
declare(strict_types=1);

// Espera-se um número inteiro: verificar em vez de converter às cegas
$seite = filter_var($_GET['seite'] ?? '1', FILTER_VALIDATE_INT, [
    'options' => ['min_range' => 1, 'max_range' => 500],
]);
if ($seite === false) {
    http_response_code(400);
    exit('Ungültige Seitenzahl');
}

// Permitir apenas valores autorizados
$sortierung = in_array($_GET['sort'] ?? '', ['name', 'datum'], true)
    ? $_GET['sort']
    : 'datum';

// Escapar sempre a saída
echo htmlspecialchars($_POST['kommentar'] ?? '', ENT_QUOTES, 'UTF-8');
```

Um obstáculo frequente são as indicações sobre a origem de um pedido. Se à frente do servidor web estiver um reverse proxy, um load balancer ou uma CDN, o `$_SERVER['REMOTE_ADDR']` contém o endereço desse intermediário, não o do visitante. O endereço real consta então de um cabeçalho como `X-Forwarded-For`, que, no entanto, qualquer cliente pode definir. A aplicação só pode avaliar esses cabeçalhos se o pedido vier comprovadamente de um proxy próprio e conhecido. Caso contrário, os bloqueios por endereço IP ou os registos podem ser facilmente enganados. O mesmo vale para `HTTPS`: se a cifragem termina no proxy, a aplicação tem de saber expressamente que a ligação original era cifrada.

Outros modelos de validação e filtragem mostra-os o artigo [Validar e filtrar entradas em PHP](https://phpsos.de/pt/blog/eingaben-validieren-php/). Para os dados de sessão em `$_SESSION` valem regras próprias; constam da página [Sessões e cookies em PHP](https://phpsos.de/pt/php/sessions-und-cookies/).

## Superglobais e PHP2Shell: o que acontece antes do seu código

Aqui está a ligação à situação atual. O [CVE-2026-109618](https://phpsos.de/pt/php2shell/cve-2026-109618/) descreve que uma condição de falta de memória pode interromper o PHP enquanto os dados do pedido estão apenas parcialmente inicializados; na limpeza do pedido, dados inválidos podem então ser tratados como válidos. No CVE-2026-109619, o estado interno de um pedido pode persistir depois de a memória ser libertada e ser utilizado por um pedido posterior no mesmo worker.

Ambas as vulnerabilidades estão, assim, no processamento que o próprio PHP faz em torno do pedido, não no código da aplicação. A equipa do PHP classifica o risco como o mais elevado no mod_php; aí foi demonstrado um exploit antes de qualquer código de aplicação correr. Nenhum `filter_var()` e nenhuma verificação na aplicação o pode impedir.

> **Agir de imediato:**
> É obrigatória a atualização para PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 e o reinício de todos os processos PHP. As medidas transitórias do php.net, como limites mais estreitos para `post_max_size`, não são uma proteção completa.

## Como ajuda concretamente a PHP SOS?

- Verificamos os valores-limite efetivos para os dados do pedido por site e definimo-los de forma adequada à aplicação.
- Aplicamos a atualização do PHP, reiniciamos todos os workers e comprovamos o nível de patches no âmbito do nosso [serviço de patches PHP](https://phpsos.de/pt/leistungen/php-patch-service/).
- Verificamos nos desenvolvimentos próprios se valores de superglobais chegam sem verificação à base de dados, ao sistema de ficheiros ou à saída.
- Guardamos os logs do servidor web a partir de 20/10/2026, para que uma análise posterior continue a ser possível.


## Perguntas frequentes

**Quantas superglobais existem no PHP?**  
O manual do PHP refere nove: $GLOBALS, $_SERVER, $_GET, $_POST, $_FILES, $_COOKIE, $_SESSION, $_REQUEST e $_ENV. Estão disponíveis em qualquer âmbito, também em funções e métodos.

**Os valores em $_SERVER são de confiança?**  
Apenas em parte. As entradas que começam por HTTP_ provêm dos cabeçalhos do pedido do cliente. O manual avisa, por exemplo, que SERVER_NAME pode refletir o nome de anfitrião fornecido pelo cliente e não é fiável para decisões de segurança.

**Porque é que o $_POST por vezes está vazio, apesar de um formulário ter sido enviado?**  
A causa mais frequente é um pedido maior do que post_max_size. Nesse caso, $_POST e $_FILES ficam vazios, segundo o manual. Uma definição enable_post_data_reading desativada leva ao mesmo.

**Deve usar-se o $_REQUEST?**  
Melhor não. O $_REQUEST mistura dados de várias fontes, e que fonte prevalece depende de request_order e variables_order. Leia os valores de forma dirigida a partir de $_GET ou $_POST.

## Fontes

- [Manual do PHP: superglobais](https://www.php.net/manual/de/language.variables.superglobals.php)
- [Manual do PHP: $_SERVER](https://www.php.net/manual/en/reserved.variables.server.php)
- [Manual do PHP: diretivas do php.ini](https://www.php.net/manual/de/ini.core.php)
- [Manual do PHP: request_parse_body](https://www.php.net/manual/en/function.request-parse-body.php)