# Smisleno ograničiti post_max_size i upload_max_filesize

> Ograničite post_max_size i upload_max_filesize: odnos prema granicama web-poslužitelja, prijelazne vrijednosti php.net-a za PHP2Shell i tipični simptomi pogrešaka.

Izvor: https://phpsos.de/hr/blog/post-max-size-upload-limits/  
Stanje: 25.10.2026  
Pružatelj: PHP SOS, PHP hitna pomoć i sigurnost poslužitelja. Hitna pomoć putem WhatsAppa: https://wa.me/491736494914?text=Pozdrav%20PHP%20SOS%2C%20trebamo%20pomo%C4%87%20s%20na%C5%A1im%20PHP%20poslu%C5%BEiteljem.%20Tvrtka%3A%20%E2%80%A6%20Web-stranica%3A%20%E2%80%A6

**Ukratko:** `post_max_size` ograničava ukupnu veličinu POST zahtjeva, a `upload_max_filesize` pojedinu datoteku; zadano je prema PHP priručniku 8M i 2M. Vrijednosti moraju odgovarati granicama u web-poslužitelju i u aplikaciji, inače prijenosi propadaju bez jasne poruke. Do ažuriranja zbog PHP2Shella php.net savjetuje `post_max_size = 8M` bez prijenosa ili `32M` s prijenosima, `upload_max_filesize` ispod toga, postavljeno tako da ga aplikacije ne mogu nadjačati.

## Kad obrazac za prijave odjednom šuti

Nakon prijelaznih mjera za PHP2Shell mnogi su administratori snizili `post_max_size`. Nekoliko dana kasnije kadrovska služba javlja da prijave više ne stižu. Obrazac se jednostavno iznova učita, poruke o pogrešci nema. Razlog: zahtjev s tri PDF privitka bio je veći od nove granice i PHP je odbacio podatke obrasca.

Primjer pokazuje osnovni problem. Granice prijenosa djeluju na više mjesta istodobno i svako mjesto reagira drukčije kad se prekorači. Tko poznaje lanac, vrijednosti može postaviti tako da štite, a da ne ometaju rad. Kako PHP interno obrađuje prijenose, objašnjava članak [Kako PHP obrađuje prijenose datoteka](https://phpsos.de/hr/php/datei-uploads-intern/); sigurno programiranje funkcija prijenosa opisuje vodič [Sigurno implementirati prijenose datoteka u PHP-u](https://phpsos.de/hr/ratgeber/datei-upload-sicher/).

## Lanac granica prijenosa

Zahtjev prolazi kroz više granica prije nego ga aplikacija vidi. Sljedeći podaci potječu iz dokumentacije Nginxa, Apachea i PHP-a:

| Mjesto | Postavka | Zadano prema dokumentaciji | Pri prekoračenju |
|---|---|---|---|
| Nginx | `client_max_body_size` | 1m | pogreška 413 pregledniku |
| Apache od 2.4.54 | `LimitRequestBody` | 1 GiB (do 2.4.53: neograničeno) | odgovor s pogreškom umjesto obrade |
| PHP | `post_max_size` | 8M | `$_POST` i `$_FILES` prazni |
| PHP | `upload_max_filesize` | 2M | datoteka se odbija s kodom pogreške |
| PHP | `max_file_uploads` | 20 | daljnje datoteke se ignoriraju |
| PHP | `max_input_vars` | 1000 | nedostaju daljnja polja obrasca |

Iz toga proizlazi jednostavno pravilo: `upload_max_filesize` manji od `post_max_size`, `post_max_size` manji od granice u web-poslužitelju. PHP priručnik uz to preporučuje da `memory_limit` općenito bude veći od `post_max_size`. Tijekom prijelazne mjere za PHP2Shell s `memory_limit=-1` tu ulogu preuzima granica putem kontejnera ili cgroupa; više o tome u članku [Pravilno postaviti memory_limit](https://phpsos.de/hr/blog/memory-limit-richtig-setzen/).

## post_max_size nakon PHP2Shella: što php.net savjetuje

U sigurnosnoj obavijesti od 21. 10. 2026. php.net za poslužitelje bez ažuriranja navodi niske granice zahtjeva kao jednu od prijelaznih mjera. One smanjuju rizik pojedinih putova napada, ali izričito nisu potpuna zaštita:

1. **Bez prijenosa datoteka:** `post_max_size = 8M`.
2. **S prijenosima datoteka:** `post_max_size = 32M`.
3. **U oba slučaja:** `upload_max_filesize` držati ispod `post_max_size`.
4. **Dodatno razmotriti:** granice u web-poslužitelju ili proxyju za dekodiranu veličinu zahtjeva, broj ulaznih polja, broj multipart dijelova, broj redaka zaglavlja i dubinu ugniježđivanja. Prema php.net-u te granice moraju obuhvatiti i zahtjeve bez upotrebljivog podatka `Content-Length`.

Vrijednosti pripadaju tamo gdje ih aplikacije ne mogu nadjačati. Budući da se `post_max_size` i `upload_max_filesize` prema priručniku mogu mijenjati na razini direktorija, `.user.ini` ili kod mod_php-a `.htaccess` mogli bi ih inače ponovno povisiti:

```ini
; FPM pool web-stranice, s prijenosima (prijelazno do ažuriranja)
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 24M
php_admin_value[max_file_uploads] = 5
```

U web-poslužitelju granicu postavite malo iznad, kako prevelik zahtjev uopće ne bi stigao do PHP-a:

```nginx
# Nginx, u server ili location bloku
client_max_body_size 32m;
```

```apache
# Apache, u VirtualHostu: 32 MiB u bajtovima
LimitRequestBody 33554432
```

Zatim ponovno učitajte sve PHP workere i web-poslužitelj. Pregled svih prijelaznih mjera nalazi se na stranici [Hitne mjere ako još ne možete zakrpati](https://phpsos.de/hr/php2shell/sofortmassnahmen-ohne-patch/). Mogu li se i kako zahtjevi za prijenos dodatno filtrirati na proxyju, razmatra članak [Filtrirati zahtjeve za prijenos na rubu](https://phpsos.de/hr/blog/upload-anfragen-am-rand-filtern/).

> **Važno:**
> Nakon svake izmjene testirajte obrasce s najvećim legitimnim zahtjevima: prijave s više privitaka, uvoze proizvoda, galerije slika. Preuska vrijednost paralizira poslovne procese a da nitko ne vidi poruku o pogrešci.

## Odrediti pravu vrijednost za Vašu web-stranicu

Umjesto paušalnih vrijednosti isplati se kratka inventura. Popišite sve obrasce s prijenosima i zabilježite najveću legitimnu datoteku i najveći broj istodobnih datoteka. Iz toga proizlazi potreba: `upload_max_filesize` pokriva najveću pojedinačnu datoteku, `post_max_size` zbroj svih datoteka jednog zahtjeva plus malo rezerve za polja obrasca.

Ako potreba premašuje 32M, ne odgovara prijelaznoj preporuci php.net-a. To je tada dodatni razlog da se ažuriranje provede ranije. Veliki prijenosi mogu se obavljati i putem zasebne poddomene sa zasebnim poolom, kako bi ostatak web-stranice zadržao uske granice.

Nakon ažuriranja na 8.5.12, 8.4.27, 8.3.36, 8.2.35 ili potvrđeni backport vrijednosti možete ponovno uskladiti sa stvarnom potrebom. Ipak ne bi smjele biti velikodušnije nego što je nužno: svaka granica koja premašuje potrebu povećava napadnu površinu bez koristi. Ako web-stranici prijenosi uopće nisu potrebni, `file_uploads = Off` je najčišće rješenje.

## Ispravno tumačiti simptome pogrešaka

Kad prijenosi propadaju, ponašanje otkriva koja granica djeluje. Stranica s pogreškom 413 potječe od web-poslužitelja. Obrazac koji se bez poruke iznova učita ili javlja „nevažeći zahtjev“ upućuje na prazne `$_POST` podatke, dakle na `post_max_size`. Poruka aplikacije o pojedinoj datoteci odgovara `upload_max_filesize`. A polja koja nedostaju u vrlo velikim obrascima, primjerice kod varijanti proizvoda, govore u prilog `max_input_vars`. PHP zapisnik pogrešaka pri prekoračenom `post_max_size` u pravilu sadrži upozorenje s veličinom zahtjeva.

Da korisnici ne ostanu bespomoćni, aplikacija bi trebala prepoznati taj slučaj. PHP priručnik za to predlaže jednostavan put: obrazac u adresi prosljeđuje oznaku, primjerice `?processed=1`. Ako oznaka stigne, a `$_POST` i `$_FILES` su prazni, zahtjev je bio prevelik i aplikacija može prikazati razumljivu poruku s dopuštenom veličinom.

## Kako PHP SOS konkretno pomaže?

- Bilježimo sve putove prijenosa na Vašim web-stranicama i utvrđujemo stvarno potrebne veličine.
- Granice web-poslužitelja, PHP-a i poola postavljamo usklađeno i zaključane od nadjačavanja, uključujući prijelazne vrijednosti php.net-a.
- Nakon prijelaza testiramo obrasce, uvoze i prijenose te ciljano prilagođavamo vrijednosti.
- U sklopu [ojačavanja poslužitelja](https://phpsos.de/hr/leistungen/server-haertung/) nakon ažuriranja vrijednosti vraćamo na trajnu potrebu.


## Česta pitanja

**Koja je razlika između post_max_size i upload_max_filesize?**  
upload_max_filesize ograničava veličinu pojedine učitane datoteke. post_max_size ograničava ukupne podatke jednog POST zahtjeva, dakle sve datoteke i polja obrasca zajedno. Prema PHP priručniku post_max_size stoga mora biti veći od upload_max_filesize.

**Što se događa ako je zahtjev veći od post_max_size?**  
Prema PHP priručniku tada su $_POST i $_FILES prazni. Aplikacija dakle uopće ne dobiva podatke obrasca i često prikaže samo nejasnu poruku o pogrešci ili iznova učita obrazac. Zbog toga je tu pogrešku teško prepoznati.

**Koje vrijednosti php.net preporučuje zbog PHP2Shella?**  
Kao prijelaznu mjeru do ažuriranja: post_max_size = 8M za aplikacije bez prijenosa datoteka, 32M za aplikacije s prijenosima, a upload_max_filesize manji od toga. Prema php.net-u to nije potpuna zaštita; ranjivosti zatvara samo ažuriranje na ispravljenu verziju PHP-a.

**Mogu li post_max_size promijeniti putem ini_set() u kodu?**  
Ne. Prema PHP priručniku post_max_size može se mijenjati samo na razini direktorija, primjerice u php.ini, u FPM poolu, u .user.ini ili kod mod_php-a u .htaccess. Tko želi nametnuti vrijednost, postavlja je pomoću php_admin_value, i tada je ni .user.ini ne može nadjačati.

## Izvori

- [php.net: sigurnosna obavijest od 21. 10. 2026.](https://www.php.net/)
- [PHP priručnik: osnovne postavke (post_max_size)](https://www.php.net/manual/en/ini.core.php)
- [Nginx dokumentacija: client_max_body_size](https://nginx.org/en/docs/http/ngx_http_core_module.html)
- [Apache dokumentacija: LimitRequestBody](https://httpd.apache.org/docs/2.4/mod/core.html)