# Statikus elemzés: PHPStan és Psalm > PHPStan és Psalm érthetően: szintek, baseline, taint-elemzés, és hogy mit tud, mit nem tud nyújtani a statikus elemzés biztonságos PHP-alkalmazásokhoz. Forrás: https://phpsos.de/hu/php/statische-analyse/ Á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:** A statikus elemzés a PHP-kódot a futtatása nélkül ellenőrzi, és így típushibákat, nem definiált változókat, halott kódot és esetleg üres értékeken végzett hívásokat talál. A két elterjedt eszköz a PHPStan (0-tól 10-ig terjedő szabályszintek) és a Psalm (1-től 8-ig terjedő hibaszintek, emellett taint-elemzés a nem biztonságos adatfolyamokhoz). Az Ön alkalmazásában találnak hibákat, nem a PHP-értelmezőben; az olyan rések ellen, mint a PHP2Shell, csak a PHP-frissítés segít. ## Mi a statikus elemzés? Egy teszt kódot futtat, és összeveti az eredményt. A statikus elemzés ezzel szemben úgy olvassa a kódot, mint egy nagyon alapos ellenőr, és a típusokból, visszatérési értékekből és hívásokból következtet arra, hol sülhet el valami rosszul. Olyan ágakban is talál hibákat, amelyeket egyetlen teszt sem ér el. A döntéshozók számára a haszon egyszerű: az élesítés előtt megtalált hibák a töredékébe kerülnek azoknak, amelyeket az ügyfelek vesznek észre. A fejlesztők számára állandó társ, amely a fejlesztőkörnyezetben és a CI-folyamatban is együtt fut. Ha az elemzés egy módosításnál riaszt, a módosítás nem kerül átvételre, amíg a hibát ki nem javítják. Így nem nő új régi teher, miközben a meglévőt fokozatosan lebontják. A [PHPUnittal és Pesttel végzett tesztekkel](https://phpsos.de/hu/php/php-testen/) együtt ez a kódminőség alapja. ## PHPStan: szabályszintek 0-tól 10-ig A PHPStant fejlesztési függőségként telepítik, és a futtatásához a PHP 7.4-es vagy újabb verziója kell: ```bash composer require --dev phpstan/phpstan vendor/bin/phpstan analyse src tests ``` További megadás nélkül a PHPStan csak a legszükségesebbet ellenőrzi. A szigort tizenegy szinttel szabályozhatja, mindegyik magában foglalja az alatta lévőket: | Szint | Mit ellenőriz még (válogatás) | |---|---| | 0 | ismeretlen osztályok és függvények, hibás számú argumentum, mindig nem definiált változók | | 3 | visszatérési típusok és a tulajdonságokhoz rendelt típusok | | 5 | az argumentumok típusai függvény- és metódushívásoknál | | 6 | hiányzó típusmegadások | | 8 | metódushívások és tulajdonság-hozzáférések olyan értékeken, amelyek null lehetnek | | 10 | a `mixed` legszigorúbb kezelése, hiányzó típusoknál is | A `--level max` mindig a legmagasabb szinten fut. A dokumentáció azonban figyelmeztet, hogy a PHPStan frissítése ilyenkor sok új üzenetet hozhat. Egy tipikus lelet a 8. szinttől: ```php name(); // PHPStan: hívás egy olyan értéken, amely null lehet } ``` ## A PHPStan bevezetése hibaáradat nélkül: a baseline A kinőtt projektekben a PHPStan magas szinten gyakran több száz helyet jelez. A baseline megoldja a problémát: az összes meglévő üzenetet egy fájlban tárolja, és a PHPStan attól kezdve csak az új hibákat jelzi. ```bash vendor/bin/phpstan analyse --level 6 src tests --generate-baseline ``` A létrehozott `phpstan-baseline.neon` fájlt építse be a konfigurációba: ```neon includes: - phpstan-baseline.neon parameters: level: 6 paths: - src - tests ``` Így a régi állomány láthatóan dokumentált marad, míg az új kódnak az elejétől fogva tisztának kell lennie. ## A Psalm és a taint-elemzés A Psalm a PHPStanhoz hasonló célokat követ. A szintek fordítva futnak: az 1 a legszigorúbb, a 8 a legelnézőbb, az alapértelmezés a 2. A Psalmhoz a PHP 8.2-es vagy újabb verziója kell, és így állítják be: ```bash composer require --dev vimeo/psalm ./vendor/bin/psalm --init ./vendor/bin/psalm --taint-analysis ``` A taint-elemzés a biztonság szempontjából különösen érdekes. A „taint” szennyeződést jelent: a Psalm megjelöli azokat az adatokat, amelyek olyan forrásból származnak, amelyet egy támadó irányíthat, például `$_GET`, `$_POST`, `$_COOKIE`, `$_REQUEST` vagy `php://input`. Aztán követi, hogy ezek az adatok védelem nélkül érkeznek-e veszélyes helyekre, az úgynevezett nyelőkbe (sink): `echo`-val történő kimenet, `include`, `header` vagy SQL-lekérdezések. A beépített kategóriák közé tartozik többek között az `sql`, `html`, `shell`, `include`, `eval`, `ssrf` és `unserialize`. ```php