Stručně: U práv k souborům na webovém serveru platí základní zásada: uživatel, pod nímž běží PHP, smí vlastní kód číst, ale ne měnit. Práva k zápisu dostávají jen složky pro uploady, cache a temp, a tam se PHP nespouští. Práva jako 777 na produkčním serveru nemají co dělat.
Proč práva k souborům po průniku rozhodují
Když útočníci přes zranitelnost spustí na serveru kód, běží tento kód s právy procesu PHP. Co smí tento uživatel, smí i útočník. Právě tady se rozhoduje, zda se z průniku stane trvalá zadní vrátka.
S PHP2Shell se tento scénář v říjnu 2026 stal velmi konkrétním. Zranitelnosti CVE-2026-109618 a CVE-2026-109619 umožňují spuštění škodlivého kódu bez přihlášení. Opraveny jsou od 21. 10. 2026 v PHP 8.5.12, 8.4.27, 8.3.36 a 8.2.35. Dobrá práva k souborům útoku nezabrání, ale zabrání tomu, aby podstrčený kód trvale přepsal vaši aplikaci.
V mnoha instalacích patří veškerý kód uživateli webového serveru, aby aktualizace fungovaly jedním kliknutím. Je to pohodlné, ale přesně tuto konstelaci útočníci hledají.
Základní princip: oddělit vlastníka a uživatele za běhu
Smysl má rozdělení na dvě role. Vlastník, například uživatel pro deploy, soubory vlastní a nasazuje aktualizace. Proces PHP běží pod jiným uživatelem a přes skupinu má jen právo ke čtení.
| Oblast | Vlastník : skupina | Práva souborů | Práva složek |
|---|---|---|---|
| Programový kód | deploy : seite1 | 640 | 750 |
| Konfigurace s hesly | deploy : seite1 | 640 | – |
| Uploady, cache, temp | seite1 : seite1 | 640 | 750 |
| Logy | root nebo seite1 | 640 | 750 |
Samotný webový server, například Nginx, potřebuje u PHP-FPM jen právo ke čtení statických souborů jako obrázky a CSS. To získá přes skupinu nebo cílené pravidlo přístupu. Kdo provozuje více webů, dá každému vlastního uživatele za běhu; jak to souvisí s pooly, popisuje příručka open_basedir a izolace jednotlivých webů.
Kontrola práv k souborům na webovém serveru
Než cokoli změníte, udělejte si přehled. Následující příkazy nic nemění.
# Pod jakým uživatelem běží procesy PHP?
ps -eo user,cmd | grep -E "[p]hp-fpm|[a]pache2|[h]ttpd" | sort | uniq -c
# Soubory a složky zapisovatelné pro všechny
find /var/www -perm -o+w -ls
# Soubory, které patří uživateli webového serveru (příklad www-data)
find /var/www -user www-data -type f -name "*.php" | head -50
# Práva konfiguračních souborů
ls -la /var/www/*/wp-config.php /var/www/*/.env 2>/dev/null
Položky zapisovatelné pro všechny jsou téměř vždy chyba. Soubory PHP, které patří uživateli za běhu, ukazují, že tento uživatel smí měnit svůj kód. Nápadné jsou také jednotlivé soubory, jejichž vlastník nebo práva se liší od sousedních. Může to být náznak podstrčených souborů, jak popisuje příručka Jak poznat a odstranit webshell.
Oprava práv krok za krokem
Práva měňte jen po zálohování a pokud možno nejdřív v testovacím prostředí. Pokud existuje podezření na průnik, zajistěte předem stopy, protože vlastník a časová razítka jsou pak důkazními prostředky.
SITE=/var/www/seite1
# Vlastník: uživatel deploy, skupina: uživatel za běhu
sudo chown -R deploy:seite1 "$SITE"
# Složky 750, soubory 640
sudo find "$SITE" -type d -exec chmod 750 {} +
sudo find "$SITE" -type f -exec chmod 640 {} +
# Jen tyto složky smí PHP zapisovat (cesty upravte podle aplikace)
sudo chown -R seite1:seite1 "$SITE/public/uploads" "$SITE/var/cache"
Poté web zkontrolujte celý: úvodní stránku, přihlášení, formuláře, nahrání obrázku, cache. Které složky musí aplikace zapisovat, uvádějí systémové požadavky výrobce na jeho oficiální stránce.
Příkaz chmod -R 777 pro rychlé vyřešení problému otevře server každému lokálnímu uživateli a každému podstrčenému procesu. Opravte místo toho vlastníka a skupinu.
Zabránit spouštění PHP v zapisovatelných složkách
Práva k zápisu jsou jen z poloviny tak nebezpečná, pokud tam nemůže běžet kód. Zakažte spouštění PHP ve složkách pro uploady a cache na úrovni webového serveru. Pro Apache v konfiguraci VirtualHost:
<Directory "/var/www/seite1/public/uploads">
<FilesMatch "\.(php|phtml|phar)$">
Require all denied
</FilesMatch>
</Directory>
Pro Nginx stačí blok location, který požadavky na soubory PHP v těchto složkách odmítá. Pravidlo patří do konfigurace serveru, nikoli do .htaccess ve složce uploadů, který by útočník s právy k zápisu mohl znovu změnit.
Vyplatí se také podívat se na umask uživatele pro deploy, aby se nové soubory nezakládaly automaticky příliš otevřené. Hodnota 027 vede k 640 pro soubory a 750 pro složky. Na vlastních serverech leží tato odpovědnost zcela na vás; co k tomu dále patří, popisuje článek Jak zabezpečit root server a vServer.
Zvláštní případy: hostingové panely, sdílený hosting a deploymenty
Ne každý server lze nastavit podle učebnice. Hostingové panely jako Plesk nebo cPanel zakládají vlastní uživatele a práva a při některých akcích je resetují. Práva tam měňte pokud možno přes funkce panelu, nebo po aktualizacích panelu ověřte, zda vaše nastavení stále platí.
Na sdíleném hostingu máte většinou jen jednoho uživatele pro všechno. Oddělení vlastníka a uživatele za běhu pak není možné. O to důležitější jsou úzká práva ke konfiguračním souborům, žádná práva 777 a vypnutí spouštění PHP ve složkách uploadů, pokud to poskytovatel umožňuje.
Kdo pracuje s automatickými deploymenty, měl by práva nastavovat přímo ve skriptu deploymentu. Jinak každá nová verze obnoví starý, příliš otevřený stav. Krátká kontrola na konci deploymentu, například výše uvedeným příkazem pro zapisovatelné soubory, takové kroky zpět spolehlivě zachytí a lze ji bez velké námahy zabudovat do každé pipeline.
Jak konkrétně pomáhá PHP SOS?
- Zjistíme vlastníky, práva a uživatele za běhu u všech webů na serveru.
- Stanovíme koncepci práv, která odpovídá vaší aplikaci a způsobu aktualizací.
- Práva a zákazy spouštění nasadíme a web poté kompletně otestujeme.
- Koncepci zdokumentujeme, aby ji deploymenty a aktualizace znovu nerozvolnily.
Jak je to zasazeno do trvalého zabezpečení, popisuje služba Zabezpečení serveru pro webové servery PHP.
Časté dotazy
Je právo 777 někdy v pořádku?
Na produkčním serveru prakticky nikdy. S 777 smí každý uživatel systému zakládat a měnit soubory. Pokud aplikace bez 777 nefunguje, je většinou špatně nastaven vlastník, nikoli práva příliš úzká.
Proč by webový server neměl smět měnit vlastní soubory?
Protože podstrčený kód běží s právy webového serveru. Pokud smí webový server zapisovat soubory PHP, může útočník manipulovat s existujícími skripty nebo zřizovat nová zadní vrátka. Když se vlastník a uživatel za běhu oddělí, zůstane kód chráněn proti zápisu.
Jak aktualizovat CMS, když webový server nesmí zapisovat?
Aktualizace pak probíhají přes vlastníka, například pomocí WP-CLI, Composeru nebo deploymentu, nikoli tlačítkem aktualizace v administraci. Je to o něco pracnější, ale podstrčený kód pak nemůže měnit programové soubory.
Jaká práva potřebuje konfigurační soubor s heslem k databázi?
Co nejmenší: čitelný pro uživatele PHP a pro nikoho jiného. Obvyklé je 640 s odpovídající skupinou, nebo 400, pokud je uživatel PHP sám vlastníkem.