# Statikus weboldalak: kevesebb PHP, kisebb támadási felület

> Statikus weboldal és biztonság: mi esik ki PHP nélkül a szerveren, mely kockázatok maradnak, és mely vállalkozásoknak éri meg valóban az átállás.

Forrás: https://phpsos.de/hu/blog/statische-website-alternative/  
Á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 statikus weboldal kész HTML-, CSS- és képfájlokból áll, amelyeket a webszerver csak kiszolgál. Mivel a szerveren nem fut PHP és adatbázis, az olyan rések, mint a PHP2Shell, az SQL-injection vagy a bejuttatott webshellek kockázata nagyrészt kiesik. Egy statikus weboldal biztonságánál ezért más dolgok számítanak: a tárhely, a domain és a build-eszközök védett hozzáférései, a gondozott függőségek és gondosan kiválasztott külső szolgáltatások. Főként olyan weboldalaknak való, amelyeket ritkán módosítanak, és nincs szükségük ügyfélfiókokra.

## Miért teszik fel ezt a kérdést éppen most

A PHP2Shell sok vállalkozásnak megmutatta, mennyi minden függ egyetlen komponenstől. Egy tíz oldalas cégweboldal, amelyet negyedévente frissítenek, ugyanazon a PHP-n futott, mint egy nagy webshop, és így ugyanannak a kritikus résnek volt kitéve. A médiajelentések szerint még hatóságok és települések is elővigyázatosságból lekapcsolták a weboldalaikat.

Kézenfekvő a kérdés: kell-e nekünk egyáltalán PHP a szerveren a weboldalunkhoz? Sok kis- és középvállalkozásnál az őszinte válasz: a kiszolgáláshoz gyakran nem. A PHP minden híváskor újra előállítja az oldalt, noha a tartalom hetek óta nem változott. Hogyan zajlik ez műszakilag, azt a [Hogyan állítja elő a PHP a weboldalt](https://phpsos.de/hu/php/wie-php-funktioniert/) írja le. Hogy mit jelent maga a rés, azt a [Mi a PHP2Shell?](https://phpsos.de/hu/php2shell/was-ist-php2shell/) magyarázza el.

## Hogyan működik egy statikus weboldal

Egy statikus weboldalnál az oldalt nem a látogatáskor, hanem előtte állítják elő. A statikus oldalak generátora, például a Hugo, a Jekyll vagy az Eleventy, szövegeket, képeket és sablonokat vesz, és kész fájlokat épít belőlük. Ezeket a fájlokat egy egyszerű webszerverre vagy egy tartalomszolgáltató hálózatra (Content-Delivery-Network), vagyis elosztott kiszolgáló hálózatra töltik fel.

A szerkesztők számára elé kerülhet egy szerkesztőeszköz, amely fogadja a módosításokat, és elindítja az újraépítést. Részben ehhez úgynevezett headless CMS-t használnak, amely csak a tartalmakat kezeli, és maga nem kell, hogy nyilvánosan elérhető legyen. A látogató ebből semmit sem lát; csak a kész fájlokat kapja.

## Statikus weboldal és biztonság összehasonlításban

| Szempont | Dinamikus PHP-s CMS | Statikus weboldal |
|---|---|---|
| Programlogika a nyilvános szerveren | Igen, minden híváskor | Nem |
| Kockázat a PHP-értelmező hibáiból | Igen, mint a PHP2Shellnél | Kiesik a kiszolgáló szerveren |
| Nyilvánosan csatlakoztatott adatbázis | Igen | Nem |
| Tipikus belépési pontok | Bővítmények, admin-bejelentkezés, feltöltések, szerver | A tárhely, a domain, a build-rendszer hozzáférései, külső szolgáltatások |
| Űrlapok, keresés, ügyfélfiók | Beépítve | Csak külső szolgáltatásokon vagy külön funkciókon keresztül |
| Gondozási ráfordítás a szerkesztőknek | Alacsony, megszokott felület | A szerkesztőeszköztől függ |
| Karbantartás | A CMS, a bővítmények és a PHP rendszeres frissítései | A build-eszközök és a függőségek frissítései |
| Alkalmasság | Webshopok, portálok, sok szerkesztő, gyakori módosítások | Cégweboldalak, céloldalak, dokumentáció |

A táblázat megmutatja: a támadási felület eltolódik, nem tűnik el. Egy nyilvánosan elérhető PHP-szerver helyett a tárhelyszolgáltatónál lévő fiókot, a domaint, a build-pipeline-t és adott esetben a szerkesztőeszközt kell védenie.

## Mely kockázatok maradnak a statikus weboldalaknál

Először a **hozzáférések**. Aki átveszi a tárhelyfiókot, a domain-hozzáférést vagy a kód-repositoryt, PHP nélkül is módosíthatja a weboldalt. A kétfaktoros bejelentkezés és a személyes fiókok ezért kötelezők.

Másodszor a **függőségek**. A generátorok és a sablonok gyakran sok csomagot hoznak magukkal, például az npm-ből. Ezeket naprakészen kell tartani, mert egy kompromittált függőség az építésnél kártékony kódot írhat a kész fájlokba. Hogyan szervezheti ezt, azt a [Függőségek naprakészen tartása](https://phpsos.de/hu/blog/abhaengigkeiten-aktuell-halten/) írja le.

Harmadszor a **külső szolgáltatások**. Az űrlapszolgáltatások, keresőfunkciók, elemzőeszközök és beágyazott szkriptek a látogatók böngészőjében vagy idegen szervereken futnak. Mindegyik szolgáltatás bizalmi viszony, adatvédelmi szempontból is.

Negyedszer a **böngészőoldal**. Egy statikus oldalnak is be kell állítania biztonsági fejléceket, például egy Content-Security-Policy-t, amely meghatározza, mely szkripteket szabad betölteni. Az alapokat a [Biztonsági fejlécek weboldalakhoz](https://phpsos.de/hu/ratgeber/sicherheits-header/) tartalmazza.

> **Tipp:**
> Az átállás előtt ellenőrizze, mely funkciókat használja valójában a weboldala. Gyakran kevesebbet, mint gondolná: oldalakat, képeket, egy kapcsolatfelvételi űrlapot. Ilyenkor a statikus weboldalhoz vezető út rövidebb, mint elsőre látszik.

## Kinek éri meg az átállás, és kinek nem

Jól megfelel egy statikus weboldal áttekinthető terjedelmű vállalati oldalaknak, kampányok céloldalainak, termékdokumentációknak és karrieroldalaknak. Az átállás különösen akkor éri meg, ha a korábbi weboldal régi PHP-verzión fut, és a verzióváltás amúgy is esedékes lenne.

Kevésbé alkalmas webshopokhoz, ügyfélportálokhoz, foglalási rendszerekhez és sok, naponta publikáló szerkesztővel rendelkező weboldalakhoz. Itt egy dinamikus rendszer marad az értelmes. Segíthet egy vegyes forma: a webshop dinamikus marad és jól keményített, az útmutatókat és a vállalati oldalakat statikusan szolgálják ki.

Egy gyakran alábecsült előny éles helyzetben mutatkozik meg. Mivel a kész fájlokat bármikor újra lehet építeni sablonokból és tartalmakból, egy manipulált weboldal gyorsan visszaállítható egy ismert, tiszta állapotra. Előfeltétel, hogy a tartalmak és a sablonok egy védett repositoryban legyenek, a módosításokat követhetően naplózzák, és senki se szerkessze közvetlenül a fájlokat a szerveren.

Az átálláshoz nem feltétlenül szükséges biztonsági szolgáltató; ezt egy ügynökség vagy egy fejlesztő is elvégezheti. Ha a korábbi weboldal kompromittált volt, a tartalmakat azonban az átvétel előtt ellenőrizni kell. Erre tér ki a [Feltörés után CMS-t váltani?](https://phpsos.de/hu/blog/cms-wechsel-nach-hack/).

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

- Megvizsgáljuk, mely funkciókra van valójában szüksége a weboldalának, és nyíltan megmondjuk, hogy alkalmas-e egy statikus megoldás.
- Átállásnál kétfaktoros bejelentkezéssel és személyes fiókokkal biztosítjuk a tárhely, a domain és a build-rendszer hozzáféréseit.
- Ellenőrizzük a külső szolgáltatásokat, és biztonsági fejléceket állítunk be, hogy az új weboldal a böngészőben is jól védett legyen.
- A megmaradó PHP-rendszerekhez a frissítéseket és a felügyeletet a [biztonsági karbantartási szerződés](https://phpsos.de/hu/leistungen/security-wartungsvertrag/) keretében vesszük át.

## Összegzés

A statikus weboldal nem csodaszer, de sok vállalati oldalnál a legegyszerűbb módja annak, hogy megszabaduljon a kockázatok egy egész osztályától. Ahol nem fut PHP, ott a PHP2Shell nem tud semmit elérni. A nyert biztonság azonban csak akkor tart, ha a hozzáféréseket, a függőségeket és a külső szolgáltatásokat ugyanolyan komolyan veszik, mint korábban a szervert.


## Gyakori kérdések

**Fel lehet törni egy statikus weboldalt is?**  
Igen. A szerveroldali programlogika kiesik, és vele a támadások egy nagy osztálya. Támadhatók maradnak azonban a tárhely, a domain és a build-rendszer hozzáférései, a beépített külső szolgáltatások és az eszközök, amelyekkel az oldalt előállítják.

**Lehetnek egy statikus weboldalon kapcsolatfelvételi űrlapok?**  
Igen, egy külső űrlapszolgáltatáson vagy egy kis, külön üzemeltetett funkción keresztül. Ilyenkor az adatok feldolgozása ennél a szolgáltatásnál van. Beépítése előtt tisztázza az adatvédelmet és az adatfeldolgozást.

**Gondozhatják a szerkesztők maguk a statikus weboldalt?**  
Megfelelő szerkesztői eszközzel igen. Sok megoldás kínál szerkesztőfelületet, amelyből az oldalt utána újragenerálják. Azoknak a csapatoknak, amelyek naponta sok tartalmat módosítanak, egy klasszikus CMS azonban gyakran kényelmesebb.

**Megéri az átállás egy webshopnak?**  
Többnyire nem teljesen. A kosár, az ügyfélfiók és a fizetés szerveroldali logikát igényel. Lehetséges egyes részeket, például útmutatókat vagy vállalati oldalakat statikusan kiszolgálni, és a webshopot külön üzemeltetni.

## Források

- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [php.net: biztonsági közlemények](https://www.php.net/)