# Superglobals: $_GET, $_POST, $_FILES m.fl.

> PHP-superglobals forklaret: hvad $_GET, $_POST, $_FILES og $_SERVER indeholder, hvordan PHP udfylder dem før jeres kode, og hvordan I bruger dem sikkert.

Kilde: https://phpsos.de/da/php/superglobals/  
Status: 25.10.2026  
Udbyder: PHP SOS, PHP-nødhjælp og serversikkerhed. Akut hjælp på WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20har%20brug%20for%20hj%C3%A6lp%20med%20vores%20PHP-server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kort sagt:** Superglobals er foruddefinerede arrays, som PHP automatisk udfylder ved hver forespørgsel, og som er tilgængelige overalt i koden. `$_GET` indeholder parametrene fra adressen, `$_POST` formulardataene, `$_FILES` uploadede filer, `$_COOKIE` cookies og `$_SERVER` oplysninger om forespørgsel og server. PHP opretter disse arrays, før jeres applikationskode starter. Derfor kan sårbarheder netop i denne behandling, som ved PHP2Shell, ikke opfanges af kontroller i applikationen.

## Hvad er superglobals?

I PHP gælder en variabel normalt kun i den funktion, hvor den blev oprettet. Superglobals er undtagelsen: De står til rådighed i ethvert gyldighedsområde, uden at man skal hente dem med `global`. PHP-manualen nævner ni af dem.

For ikke-teknikere kan det beskrives sådan: Superglobals er applikationens postkasse. Alt, hvad en besøgende sender, havner dér, før applikationen læser det. Og alt i postkassen stammer potentielt fra en fremmed.

## Superglobals i overblik

| Superglobal | Indhold | Oprindelse |
|---|---|---|
| `$_GET` | parametre fra adressen (query-string) | klient |
| `$_POST` | formularfelter i en POST-forespørgsel | klient |
| `$_FILES` | oplysninger om uploadede filer | klient, bearbejdet af PHP |
| `$_COOKIE` | cookies, som browseren sender med | klient |
| `$_REQUEST` | blanding af GET, POST og eventuelt cookies | klient |
| `$_SERVER` | forespørgsels-headere, metode, stier, serveroplysninger | webserver og klient blandet |
| `$_ENV` | miljøvariabler | server |
| `$_SESSION` | data fra den aktuelle session | serverlager |
| `$GLOBALS` | alle globale variabler | script |

Særligt snedig er `$_SERVER`. Ifølge manualen opretter PHP for hver forespørgsels-header en post med `HTTP_` i begyndelsen, f.eks. `HTTP_USER_AGENT`. Disse værdier sætter klienten selv. Også `SERVER_NAME` kan ifølge manualen indeholde det værtsnavn, klienten har leveret, og er ikke pålidelig til sikkerhedsbeslutninger.

## Hvordan PHP udfylder superglobals

Før det første tegn i jeres script udføres, har PHP allerede arbejdet. Det læser adressen, headerne og forespørgslens indhold, opdeler dem og lægger resultaterne i arraysene. Flere indstillinger styrer dette trin:

1. **`variables_order`** (standard `EGPCS`) fastlægger, hvilke superglobals der overhovedet oprettes: Environment, GET, POST, Cookie, Server.
2. **`request_order`** (standard tom) bestemmer, hvad `$_REQUEST` dannes af. Er den tom, gælder `variables_order`. De medfølgende php.ini-filer udelader ifølge manualen cookies af sikkerhedsgrunde.
3. **`max_input_vars`** (standard `1000`) og **`max_input_nesting_level`** (standard `64`) begrænser antal og indlejring af inputvariabler.
4. **`post_max_size`** (standard `8M`) begrænser forespørgslens indhold. Er en forespørgsel større, forbliver `$_POST` og `$_FILES` tomme.
5. **`enable_post_data_reading`** (standard til) styrer, om PHP overhovedet automatisk behandler indholdet af POST-forespørgsler.

Er `enable_post_data_reading` slået fra, læser applikationen det rå indhold selv via `php://input`. Siden PHP 8.4.0 findes desuden `request_parse_body()`, som behandler formular- og uploaddata også for andre metoder end POST og tillader egne grænseværdier. Hvordan upload-delen forløber i detaljer, forklarer siden [Sådan behandler PHP filuploads](https://phpsos.de/da/php/datei-uploads-intern/).

## Håndtér forespørgselsdata sikkert

Princippet er enkelt: Hver værdi fra `$_GET`, `$_POST`, `$_COOKIE`, `$_FILES` og `HTTP_`-posterne i `$_SERVER` er et fremmed input. Den kontrolleres ved modtagelsen og maskeres passende ved udskrivningen.

```php
<?php
declare(strict_types=1);

// Heltal forventet: kontrollér i stedet for at omdanne blindt
$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');
}

// Tillad kun tilladte værdier
$sortierung = in_array($_GET['sort'] ?? '', ['name', 'datum'], true)
    ? $_GET['sort']
    : 'datum';

// Maskér altid ved udskrivning
echo htmlspecialchars($_POST['kommentar'] ?? '', ENT_QUOTES, 'UTF-8');
```

En hyppig snublesten er oplysninger om en forespørgsels oprindelse. Står der foran webserveren en reverse proxy, en load balancer eller et CDN, indeholder `$_SERVER['REMOTE_ADDR']` mellemleddets adresse, ikke den besøgendes. Den rigtige adresse står så i en header som `X-Forwarded-For`, som dog enhver klient selv kan sætte. Applikationen må kun behandle sådanne headere, hvis forespørgslen påviseligt kommer fra en egen, kendt proxy. Ellers kan spærringer efter IP-adresse eller protokoller let snydes. Noget lignende gælder for `HTTPS`: Slutter krypteringen ved proxyen, skal applikationen udtrykkeligt vide, at den oprindelige forbindelse var krypteret.

Yderligere mønstre til validering og filtrering viser indlægget [Valider og filtrér input i PHP](https://phpsos.de/da/blog/eingaben-validieren-php/). For sessionsdata i `$_SESSION` gælder egne regler; de står på siden [Sessioner og cookies i PHP](https://phpsos.de/da/php/sessions-und-cookies/).

## Superglobals og PHP2Shell: hvad der sker før jeres kode

Her ligger sammenhængen med den aktuelle situation. [CVE-2026-109618](https://phpsos.de/da/php2shell/cve-2026-109618/) beskriver, at en out-of-memory-tilstand kan afbryde PHP, mens forespørgselsdata kun er delvis initialiseret; ved oprydningen af forespørgslen kan ugyldige data så blive behandlet som gyldige. Ved CVE-2026-109619 kan en forespørgsels interne tilstand blive bestående, efter at hukommelsen er frigivet, og blive udnyttet af en senere forespørgsel i den samme worker.

Begge sårbarheder ligger altså i den behandling, PHP selv udfører omkring forespørgslen, ikke i applikationskoden. PHP-teamet vurderer risikoen ved mod_php som den højeste; dér blev en exploit vist, før der overhovedet kører applikationskode. Ingen `filter_var()` og ingen kontrol i applikationen kan forhindre det.

> **Handl med det samme:**
> Pligt er opdateringen til PHP 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 og genstarten af alle PHP-processer. Overgangsforanstaltningerne fra php.net, f.eks. snævrere grænser for `post_max_size`, er ingen fuldstændig beskyttelse.

## Hvordan hjælper PHP SOS konkret?

- Vi kontrollerer de virksomme grænseværdier for forespørgselsdata pr. website og sætter dem passende til applikationen.
- Vi indspiller PHP-opdateringen, genstarter alle workere og dokumenterer patch-status som led i vores [PHP-patchservice](https://phpsos.de/da/leistungen/php-patch-service/).
- Vi kontrollerer egenudviklinger for, om værdier fra superglobals uden kontrol når ind i database, filsystem eller output.
- Vi sikrer webserverens logs fra og med den 20.10.2026, så en senere analyse forbliver mulig.


## Ofte stillede spørgsmål

**Hvor mange superglobals findes der i PHP?**  
PHP-manualen nævner ni: $GLOBALS, $_SERVER, $_GET, $_POST, $_FILES, $_COOKIE, $_SESSION, $_REQUEST og $_ENV. De er tilgængelige i ethvert gyldighedsområde, også i funktioner og metoder.

**Er værdier i $_SERVER troværdige?**  
Kun delvis. Poster med HTTP_ i begyndelsen stammer fra klientens forespørgsels-headere. Manualen advarer f.eks. om, at SERVER_NAME kan afspejle det værtsnavn, klienten har leveret, og ikke er pålidelig til sikkerhedsbeslutninger.

**Hvorfor er $_POST nogle gange tom, selv om en formular er sendt?**  
Hyppigste årsag er en forespørgsel, der er større end post_max_size. Så forbliver $_POST og $_FILES ifølge manualen tomme. Også en slået-fra indstilling enable_post_data_reading fører til det.

**Bør man bruge $_REQUEST?**  
Helst ikke. $_REQUEST blander data fra forskellige kilder, og hvilken kilde der vinder, afhænger af request_order og variables_order. Læs værdier målrettet fra $_GET eller $_POST.

## Kilder

- [PHP-manualen: Superglobals](https://www.php.net/manual/de/language.variables.superglobals.php)
- [PHP-manualen: $_SERVER](https://www.php.net/manual/en/reserved.variables.server.php)
- [PHP-manualen: php.ini-direktiver](https://www.php.net/manual/de/ini.core.php)
- [PHP-manualen: request_parse_body](https://www.php.net/manual/en/function.request-parse-body.php)
