# display_errors off: a hibakimenet kikapcsolása éles üzemben

> display_errors Off és még több: mely PHP-beállítások tartják távol a hibaüzeneteket az éles weboldaltól, mit tesznek a keretrendszerek, hogyan ellenőrizze.

Forrás: https://phpsos.de/hu/blog/display-errors-produktion/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**Röviden:** Egy éles weboldalon a `display_errors = Off` a php.ini-be való, a `display_startup_errors = Off`, a `log_errors = On` és a webrooton kívüli hibanapló mellett. Ezenkívül a CMS-eknek és keretrendszereknek éles módban kell futniuk, különben a saját hibaoldalaik mutatják a részleteket. `php_admin_flag`-gel zárolva és minden frissítés után ellenőrizve a hibák a naplóban maradnak a böngésző helyett.

## Mit árul el egyetlen hibaüzenet

Egy figyelmeztetés az oldal tetején, egy „Fatal error” a rendelésösszesítő helyett: az ilyen kimenetek ártalmatlannak látszanak. A támadó számára térkép. Teljes fájlútvonalakat, adatbázisok és táblák nevét, használt könyvtárakat és gyakran a PHP-verziót mutatják.

Éppen az olyan helyzetekben, mint a PHP2Shell, amikor tömegesen keresnek sebezhető szervereket, a szervernek a lehető legkevesebbet kell elárulnia magáról. Ez nem zár le rést a PHP-értelmezőben, de megnehezít minden további lépést egy behatolás után, és fáradságosabbá teszi az Ön alkalmazása elleni célzott támadásokat.

Ehhez jön az adatvédelem. A hibaüzenetek kéréseknek részeit tartalmazhatják, például űrlapokból származó e-mail-címeket. Ami egy látogató böngészőjében megjelenik, az már nincs az Ön ellenőrzése alatt.

## Az alapértékek nem éles üzemre valók

Sokan abból indulnak ki, hogy a PHP magától elrejti a hibákat. A PHP kézikönyve mást mond: a `display_errors` beépített alapértéke 1, a `display_startup_errors` pedig a PHP 8.0 óta szintén alapértelmezetten be van kapcsolva. Csak a mellékelt `php.ini-production` sablon állítja mindkettőt Off-ra. A kézikönyv a `display_errors`-t kifejezetten fejlesztési funkciónak nevezi, amelyet internetre kapcsolt rendszereken soha nem szabad használni.

Hogy a szerver az éles sablont használja-e, nem magától értetődő. A konténer-image-ek részben egyáltalán php.ini nélkül indulnak, a tárhelypanelek saját értékeket állítanak be, egy költözés után pedig szívesen a fejlesztési sablont másolják.

## display_errors off: a beállítások áttekintése

A következő értékek értelmesek éles szervereken. Az olyan állandók, mint az `E_ALL`, csak a php.ini-ben működnek; az Apache-konfigurációban a PHP kézikönyve szerint nincs jelentésük, és számként kell megadni őket.

| Beállítás | Éles üzem | Cél |
|---|---|---|
| `display_errors` | `Off` | nincs hiba a böngészőben |
| `display_startup_errors` | `Off` | nincs hiba a PHP indulásakor a kimenetben |
| `log_errors` | `On` | a hibák naplóba írása |
| `error_log` | útvonal a webrooton kívül | saját naplófájl weboldalanként vagy poolonként |
| `error_reporting` | `E_ALL` | minden hibát naplózni, nem megjeleníteni |
| `html_errors` | `Off` | egyszerű szöveg HTML helyett a naplókban |
| `zend.exception_ignore_args` | `On` | nincsenek függvényargumentumok a stacktrace-ekben |
| `fatal_error_backtraces` | `0` a frissítésig (csak PHP 8.5) | átmeneti intézkedés a php.net szerint |

A `zend.exception_ignore_args` különösen értékes. Enélkül a beállítás nélkül a naplókban és hibaoldalakon lévő stacktrace-ek tartalmazhatják a függvényhívások argumentumait, tehát az éppen feldolgozott jelszavakat vagy tokeneket is.

```ini
; a webes SAPI php.ini-je
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/website-fehler.log
error_reporting = E_ALL
html_errors = Off
zend.exception_ignore_args = On
; csak PHP 8.5, átmeneti intézkedés a 8.5.12-re való frissítésig:
; fatal_error_backtraces = 0
```

Az FPM-poolban a legfontosabb értékeket ezenkívül zárolja, hogy egyetlen alkalmazás se kapcsolhassa vissza őket az `ini_set()`-tel:

```ini
; pl. /etc/php/8.3/fpm/pool.d/seite1.conf
php_admin_flag[display_errors] = off
php_admin_flag[display_startup_errors] = off
php_admin_flag[log_errors] = on
php_admin_value[error_log] = /var/log/php/seite1-fehler.log
```

Utána indítsa újra az adott PHP-szolgáltatást. Hogyan működik pontosan a zárolás, azt a [php_admin_value: beállítások zárolása a felülírás ellen](https://phpsos.de/hu/blog/php-admin-value-sperren/) cikk magyarázza. Egy teljes alapkonfigurációt a [A php.ini biztonságos beállítása](https://phpsos.de/hu/ratgeber/php-ini-sicher-konfigurieren/) útmutatóban talál.

## A második kapcsoló: az alkalmazás hibakereső módja

A PHP csak a feladat fele. A modern keretrendszerek maguk fogják el a hibákat, és saját, gyakran nagyon részletes hibaoldalakat mutatnak. Hibakereső módban forráskód-részleteket, konfigurációs értékeket és néha környezeti változókat tartalmaznak. Ezek az oldalak akkor is megjelennek, ha a `display_errors` ki van kapcsolva a PHP-ban.

Ezért minden alkalmazásnál ellenőrizze a saját kapcsolóját. A WordPressnél ez a `WP_DEBUG` és a `WP_DEBUG_DISPLAY` a `wp-config.php`-ben, a Laravelnél és a Symfonynál az `APP_DEBUG` és a környezet a `.env` fájlban, más rendszereknél a gyártói dokumentáció szerinti éles mód. Egy éles rendszeren a hibakereső módnak tartósan ki kell lennie kapcsolva, még a „csak egy pillanatra tesztelésre” is kockázat.

Hogyan kezelik tisztán a hibákat az alkalmazásban, ahelyett hogy elnyomnák őket, azt a [Hibák és kivételek a PHP-ban](https://phpsos.de/hu/php/fehler-und-exceptions/) írja le.

## Így találja meg a hibakimeneteket, mielőtt mások megteszik

Egyszeri beállítás nem elég. A hibakimenetek frissítések, költözések vagy panelmódosítások után visszatérnek. Egy rövid ellenőrzési menet segít:

1. Az érvényes értékeket webkörnyezetben ellenőrizze, ne csak a parancssorban, például egy rövid időre elhelyezett, majd azonnal törölt ellenőrző fájllal.
2. Minden alkalmazás hibakereső módját ellenőrizze annak konfigurációs fájljában.
3. A kiszolgált oldalakat kutassa át tipikus hibaszövegek után, ahogyan az alábbi kódblokk mutatja.
4. A keresőmotorban egy `site:` lekérdezéssel a domainjére keressen olyan kifejezésekre, mint a „Fatal error” vagy a „Warning”.
5. Ellenőrizze, hogy a hibanaplóba írnak-e, és hogy nincs-e a webrootban.

```bash
# A kiszolgált oldalak átkutatása PHP-hibaszövegek után (csak saját domainek)
for url in https://www.example.de/ https://www.example.de/kontakt/; do
  curl -s "$url" | grep -E -o "(Fatal error|Warning|Notice|Deprecated|Stack trace)[^<]{0,80}" | head -3
done
# Írnak a hibanaplóba?
ls -l /var/log/php/
```

> **Fontos:**
> A hibák elrejtése nem pótolja azok kijavítását. A figyelmeztetésekkel teli napló karbantartási igényre utal, egy behatolás után pedig gyakran fontos nyom. Hogy mit naplózzon eközben, és mit nem, azt a [Biztonságos naplózás: hibák naplózása adatszivárgás nélkül](https://phpsos.de/hu/blog/sicher-loggen-php/) írja le.

## Összegzés: csendes a böngészőben, bőbeszédű a naplóban

Az éles szerverekre vonatkozó szabály egyszerű: a hibák a naplóba valók, nem a weboldalra. A gyakorlatban az olyan alapértékeken bukik el, amelyek nem éles üzemre valók, az alkalmazások hibakereső kapcsolóin, és a frissítések vagy költözések után visszaeső konfigurációkon.

Aki kikapcsolja a `display_errors` és a `display_startup_errors` beállítást, zárolja az értékeket a poolban, ellenőrzi az alkalmazás hibakereső módját, és rendszeresen ellenőrzi az eredményt, az lezárja a szükségtelen információközlés egyik leggyakoribb forrását. A ráfordítás csekély, a hatás megmarad, amíg az ellenőrzés minden frissítés részét képezi.

Egy pont ne vesszen el: a hibanapló nem szemetes. Aki rendszeresen olvassa, felismeri a hibás frissítéseket, az elavult függvényeket, néha pedig egy támadás első nyomait is, jóval azelőtt, hogy az ügyfelek bármit észrevennének.

## Hogyan segít konkrétan a PHP SOS?

- **Ellenőrzés:** Kiolvassuk az érvényes hibabeállításokat weboldalanként és poolonként, és a kiszolgált oldalakat hibakimenetek után kutatjuk át.
- **Átállítás:** A PHP- és alkalmazásbeállításokat éles üzemre állítjuk, és zároljuk a felülírás ellen.
- **Naplók beállítása:** A hibanaplók a webrooton kívül vannak, rotálódnak, és a fejlesztői számára hozzáférhetők.
- **Tartós megőrzés:** A [biztonsági karbantartási szerződés](https://phpsos.de/hu/leistungen/security-wartungsvertrag/) keretében minden frissítés után újra ellenőrizzük a beállításokat.


## Gyakori kérdések

**A display_errors nincs egyébként is kikapcsolva a PHP-ban?**  
Nem automatikusan. A PHP kézikönyve szerint a display_errors beépített alapértéke 1. Csak a mellékelt php.ini-production sablon állítja Off-ra. Hogy a szervere ezt a sablont használja-e, a disztribúciótól, a paneltől vagy a konténer-image-től függ, és ellenőrizni kell.

**Elég a display_errors = Off, ha a WordPress vagy a Laravel hibakereső módban fut?**  
Nem. Sok CMS és keretrendszer saját hibaoldalakat hoz magával, amelyek a PHP-tól függetlenül részleteket jeleníthetnek meg. Ezért kapcsolja ki az alkalmazás hibakereső módját is, például a WP_DEBUG_DISPLAY-t a WordPressnél vagy az APP_DEBUG-ot a Laravelnél és a Symfonynál.

**Hová kerülnek a hibák, ha már nem jelennek meg?**  
A log_errors = On esetén a PHP abba a fájlba írja őket, amelyet az error_log megnevez, vagy az adott üzemmód naplójába, például az Apache vagy a PHP-FPM hibanaplójába. A fájlnak a webrooton kívül kell lennie, és rendszeresen rotálni kell.

**Mi köze a fatal_error_backtraces-nek a PHP2Shellhez?**  
A beállítás a PHP 8.5-től létezik, és alapértelmezetten aktív. A php.net a fatal_error_backtraces=0 beállítást az azt követő újraindítással a PHP 8.5 egyik átmeneti intézkedéseként nevezi meg, amíg a 8.5.12-re való frissítés még várat magára. A frissítést nem pótolja.

## Források

- [PHP kézikönyv: hibakezelés és naplózás](https://www.php.net/manual/en/errorfunc.configuration.php)
- [PHP kézikönyv: a konfiguráció módosítása (php_admin_flag)](https://www.php.net/manual/en/configuration.changes.php)
- [php.net: biztonsági közlemények](https://www.php.net/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)