# Statinės svetainės: mažiau PHP, mažesnis atakos paviršius

> Statinė svetainė ir saugumas: kas išnyksta be PHP serveryje, kurios rizikos lieka ir kurioms įmonėms perėjimas tikrai apsimoka.

Šaltinis: https://phpsos.de/lt/blog/statische-website-alternative/  
Būsena: 2026-10-25  
Teikėjas: PHP SOS, PHP avarinė pagalba ir serverio sauga. Skubi pagalba per „WhatsApp“: https://wa.me/491736494914?text=Sveiki%2C%20PHP%20SOS%2C%20mums%20reikia%20pagalbos%20su%20m%C5%ABs%C5%B3%20PHP%20serveriu.%20%C4%AEmon%C4%97%3A%20%E2%80%A6%20Svetain%C4%97%3A%20%E2%80%A6

**Trumpai:** statinę svetainę sudaro paruošti HTML, CSS ir paveikslėlių failai, kuriuos žiniatinklio serveris tik pateikia. Kadangi serveryje neveikia nei PHP, nei duomenų bazė, tokios spragos kaip PHP2Shell, SQL injekcija ar įterpti žiniatinklio apvalkalai kaip rizika iš esmės atkrinta. Statinės svetainės saugumui svarbūs kiti dalykai: apsaugotos prieigos prie hostingo, domeno ir kūrimo įrankių, prižiūrimos priklausomybės ir kruopščiai parinkti išoriniai servisai. Ji tinka visų pirma svetainėms, kurios retai keičiamos ir kurioms nereikia klientų paskyrų.

## Kodėl klausimas keliamas būtent dabar

PHP2Shell daugeliui įmonių parodė, kiek priklauso nuo vieno komponento. Įmonės svetainė su dešimt puslapių, atnaujinama kartą per ketvirtį, veikė su tuo pačiu PHP kaip didelė internetinė parduotuvė ir todėl buvo veikiama tos pačios kritinės spragos. Pasak žiniasklaidos pranešimų, net institucijos ir savivaldybės atsargumo sumetimais išjungė svetaines.

Natūralu paklausti: ar mūsų svetainei apskritai reikia PHP serveryje? Daugeliui mažų ir vidutinių įmonių sąžiningas atsakymas: pateikimui dažnai ne. PHP kiekvieną kartą atidarius puslapį sukuria jį iš naujo, nors turinys jau savaites nesikeitė. Kaip tai techniškai vyksta, aprašo [Kaip PHP sukuria tinklalapį](https://phpsos.de/lt/php/wie-php-funktioniert/). Ką pati spraga reiškia, paaiškina [Kas yra PHP2Shell?](https://phpsos.de/lt/php2shell/was-ist-php2shell/).

## Kaip veikia statinė svetainė

Statinėje svetainėje puslapis kuriamas ne lankant, o iš anksto. Statinių puslapių generatorius, pavyzdžiui, Hugo, Jekyll ar Eleventy, paima tekstus, paveikslėlius ir šablonus ir iš jų sukuria paruoštus failus. Šie failai keliami į paprastą žiniatinklio serverį arba turinio pristatymo tinklą (Content Delivery Network), tai yra paskirstytą pateikimo tinklą.

Redaktoriams prieš tai gali stovėti redagavimo įrankis, kuris priima pakeitimus ir paleidžia perkūrimą. Kartais tam naudojamas vadinamasis Headless CMS, kuris tik tvarko turinį ir pats neprivalo būti viešai pasiekiamas. Lankytojas nieko to nemato; jis gauna tik paruoštus failus.

## Statinė svetainė ir saugumas palyginime

| Kriterijus | Dinaminis PHP CMS | Statinė svetainė |
|---|---|---|
| Programinė logika viešame serveryje | Taip, kiekvieną kartą atidarius | Ne |
| Rizika dėl spragų PHP interpretatoriuje | Taip, kaip esant PHP2Shell | Pateikimo serveryje atkrinta |
| Viešai prijungta duomenų bazė | Taip | Ne |
| Tipinės įėjimo durys | Papildiniai, administratoriaus prisijungimas, įkėlimai, serveris | Prieigos prie hostingo, domeno, kūrimo sistemos, išoriniai servisai |
| Formos, paieška, kliento paskyra | Įmontuota | Tik per išorinius servisus ar atskiras funkcijas |
| Redaktorių priežiūros darbas | Mažas, įprasta sąsaja | Priklauso nuo redagavimo įrankio |
| Priežiūra | Reguliarūs CMS, papildinių ir PHP atnaujinimai | Kūrimo įrankių ir priklausomybių atnaujinimai |
| Tinkamumas | Parduotuvės, portalai, daug redaktorių, dažni pakeitimai | Įmonių svetainės, nukreipimo puslapiai, dokumentacija |

Lentelė rodo: atakos paviršius pasislenka, bet neišnyksta. Vietoj viešai pasiekiamo PHP serverio turite apsaugoti paskyrą pas hostingo teikėją, domeną, kūrimo konvejerį ir, jei yra, redagavimo įrankį.

## Kurios rizikos statinėse svetainėse lieka

Pirma, **prieigos**. Kas perima hostingo paskyrą, domeno prieigą ar kodo saugyklą, gali pakeisti svetainę visai be PHP. Todėl dviejų veiksnių prisijungimas ir asmeninės paskyros yra privalomi.

Antra, **priklausomybės**. Generatoriai ir šablonai dažnai atsineša daug paketų, pavyzdžiui, iš npm. Juos reikia laikyti aktualius, nes kompromituota priklausomybė kūrimo metu gali įrašyti kenkėjišką kodą į paruoštus failus. Kaip tai organizuoti, aprašo [Priklausomybių atnaujinimas](https://phpsos.de/lt/blog/abhaengigkeiten-aktuell-halten/).

Trečia, **išoriniai servisai**. Formų paslaugos, paieškos funkcijos, analizės įrankiai ir įtraukti skriptai veikia lankytojų naršyklėje arba svetimuose serveriuose. Kiekvienas toks servisas yra pasitikėjimo santykis, taip pat ir duomenų apsaugos požiūriu.

Ketvirta, **naršyklės pusė**. Net statinis puslapis turėtų nustatyti saugumo antraštes (headers), pavyzdžiui, Content-Security-Policy, kuri nustato, kokius skriptus leidžiama įkelti. Pagrindai pateikti skyriuje [Saugumo antraštės svetainėms](https://phpsos.de/lt/ratgeber/sicherheits-header/).

> **Patarimas:**
> Prieš pereidami patikrinkite, kokias funkcijas jūsų svetainė iš tikrųjų naudoja. Dažnai jų mažiau nei manoma: puslapiai, paveikslėliai, kontaktų forma. Tada kelias į statinę svetainę trumpesnis nei iš pradžių atrodo.

## Kam perėjimas apsimoka ir kam ne

Statinė svetainė gerai tinka kompaktiškoms įmonių svetainėms, kampanijų nukreipimo puslapiams, produktų dokumentacijai ir karjeros puslapiams. Perėjimas ypač apsimoka, jei dabartinė svetainė veikia su sena PHP versija ir atnaujinimas vis tiek būtų reikalingas.

Mažiau tinka internetinėms parduotuvėms, klientų portalams, rezervacijos sistemoms ir svetainėms su daug redaktorių, kurie kasdien skelbia turinį. Čia prasmingas lieka dinaminis sistema. Gali padėti mišri forma: parduotuvė lieka dinaminė ir gerai sustiprinta, patarimai ir įmonės puslapiai pateikiami statiškai.

Dažnai nuvertinamas pranašumas išryškėja kritiniu atveju. Kadangi paruošti failai bet kada gali būti perkurti iš šablonų ir turinio, manipuliuotą svetainę galima greitai grąžinti į žinomą, švarią būseną. Sąlyga: turinys ir šablonai laikomi apsaugotoje saugykloje, pakeitimai atsekamai registruojami ir niekas netaiso failų tiesiogiai serveryje.

Saugumo paslaugų teikėjo perėjimui nebūtinai reikia; tai gali atlikti agentūra ar kūrėjas. Tačiau jei ankstesnė svetainė buvo kompromituota, turinį prieš perimant reikėtų patikrinti. Tai aptaria [Po įsilaužimo keisti CMS?](https://phpsos.de/lt/blog/cms-wechsel-nach-hack/).

## Kaip PHP SOS padeda konkrečiai?

- Tikriname, kokių funkcijų jūsų svetainei iš tikrųjų reikia, ir atvirai pasakome, ar tinka statinis sprendimas.
- Keičiant apsaugome prieigas prie hostingo, domeno ir kūrimo sistemos dviejų veiksnių prisijungimu ir asmeninėmis paskyromis.
- Tikriname išorinius servisus ir nustatome saugumo antraštes, kad nauja svetainė būtų gerai apsaugota ir naršyklėje.
- Likusioms PHP sistemoms perimame atnaujinimus ir stebėseną per [saugumo priežiūros sutartį](https://phpsos.de/lt/leistungen/security-wartungsvertrag/).

## Išvada

Statinė svetainė nėra panacėja, bet daugeliui įmonių svetainių paprasčiausias būdas atsikratyti visos rizikų klasės. Kur neveikia PHP, PHP2Shell nieko negali padaryti. Tačiau įgytas saugumas išlieka tik tuo atveju, jei prieigos, priklausomybės ir išoriniai servisai vertinami taip pat rimtai, kaip anksčiau serveris.


## Dažni klausimai

**Ar statinę svetainę vis tiek galima nulaužti?**  
Taip. Išnyksta serverio programinė logika ir kartu didelė atakų klasė. Tačiau pažeidžiamos lieka prieigos prie hostingo, domeno ir kūrimo (build) sistemos, įtraukti išoriniai servisai ir įrankiai, kuriais svetainė generuojama.

**Ar statinė svetainė gali turėti kontaktų formas?**  
Taip, per išorinę formų paslaugą arba mažą, atskirai eksploatuojamą funkciją. Tada duomenų apdorojimas yra tos paslaugos reikalas. Prieš ją įtraukdami išsiaiškinkite duomenų apsaugą ir duomenų tvarkymo sutartį.

**Ar redaktoriai gali patys prižiūrėti statinę svetainę?**  
Su tinkamu redagavimo įrankiu taip. Daug sprendimų siūlo redagavimo sąsają, iš kurios svetainė paskui sukuriama iš naujo. Komandoms, kurios kasdien keičia daug turinio, klasikinis CMS dažnai patogesnis.

**Ar perėjimas apsimoka internetinei parduotuvei?**  
Dažniausiai ne visiškai. Krepšeliui, kliento paskyrai ir apmokėjimui reikia serverio logikos. Galima dalis, pavyzdžiui, patarimus ar įmonės puslapius, pateikti statiškai, o parduotuvę eksploatuoti atskirai.

## Šaltiniai

- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [php.net: saugumo pranešimai](https://www.php.net/)