Kort gezegd: Een statische website bestaat uit kant-en-klare HTML-, CSS- en beeldbestanden die de webserver alleen uitlevert. Omdat er op de server geen PHP en geen database draaien, vallen lekken zoals PHP2Shell, SQL-injectie of ingebrachte webshells als risico grotendeels weg. Voor de beveiliging van een statische website tellen dan andere dingen: beveiligde toegangen tot hosting, domein en buildtools, onderhouden afhankelijkheden en zorgvuldig gekozen externe diensten. Ze is vooral geschikt voor websites die zelden wijzigen en geen klantaccounts nodig hebben.
Waarom de vraag juist nu wordt gesteld
PHP2Shell heeft veel bedrijven laten zien hoeveel aan één enkele component hangt. Een bedrijfswebsite met tien pagina's die eens per kwartaal wordt bijgewerkt, draaide op dezelfde PHP als een grote webshop en was daarmee aan hetzelfde kritieke lek blootgesteld. Volgens mediaberichten hebben zelfs overheden en gemeenten websites preventief uitgeschakeld.
Dan ligt de vraag voor de hand: hebben we voor onze website eigenlijk PHP op de server nodig? Bij veel kleine en middelgrote bedrijven luidt het eerlijke antwoord: voor de uitlevering vaak niet. PHP genereert bij elke oproep de pagina opnieuw, hoewel de inhoud al weken niet is veranderd. Hoe dat technisch verloopt, beschrijft Hoe PHP een webpagina genereert. Wat het lek zelf betekent, legt Wat is PHP2Shell? uit.
Hoe een statische website werkt
Bij een statische website wordt de pagina niet bij het bezoek gegenereerd, maar vooraf. Een generator voor statische pagina's, zoals Hugo, Jekyll of Eleventy, neemt teksten, afbeeldingen en sjablonen en bouwt daar kant-en-klare bestanden van. Deze bestanden worden op een eenvoudige webserver of een contentdeliverynetwerk, dus een verspreid uitleveringsnetwerk, geplaatst.
Voor redacteuren kan een bewerkingshulpmiddel ervoor staan dat wijzigingen aanneemt en de nieuwe opbouw start. Soms wordt daarvoor een zogeheten headless CMS gebruikt, dat alleen inhoud beheert en zelf niet openbaar bereikbaar hoeft te zijn. De bezoeker merkt daar niets van; hij ontvangt alleen de kant-en-klare bestanden.
Statische website en beveiliging vergeleken
| Criterium | Dynamisch PHP-CMS | Statische website |
|---|---|---|
| Programmalogica op de openbare server | Ja, bij elke oproep | Nee |
| Risico door lekken in de PHP-interpreter | Ja, zoals bij PHP2Shell | Vervalt op de uitleveringsserver |
| Database openbaar gekoppeld | Ja | Nee |
| Typische toegangspoorten | Plug-ins, beheerderslogin, uploads, server | Toegangen tot hosting, domein, buildsysteem, externe diensten |
| Formulieren, zoeken, klantaccount | Ingebouwd | Alleen via externe diensten of afzonderlijke functies |
| Onderhoudsinspanning voor redacteuren | Laag, vertrouwde omgeving | Afhankelijk van het redactiehulpmiddel |
| Onderhoud | Regelmatige updates van CMS, plug-ins en PHP | Updates van buildtools en afhankelijkheden |
| Geschiktheid | Shops, portalen, veel redacteuren, vaak wijzigende inhoud | Bedrijfswebsites, landingspagina's, documentatie |
De tabel laat zien: het aanvalsoppervlak verschuift, het verdwijnt niet. In plaats van een openbaar bereikbare PHP-server moet u het account bij de hoster, het domein, de buildpipeline en eventueel het redactiehulpmiddel beveiligen.
Welke risico's bij statische websites blijven
Ten eerste de toegangen. Wie het hostingaccount, de domeintoegang of de coderepository overneemt, kan de website wijzigen, zonder PHP. Tweefactorauthenticatie en persoonlijke accounts zijn daarom verplicht.
Ten tweede de afhankelijkheden. Generatoren en sjablonen brengen vaak veel pakketten mee, bijvoorbeeld uit npm. Die moeten actueel worden gehouden, omdat een gecompromitteerde afhankelijkheid bij het bouwen schadelijke code in de kant-en-klare bestanden kan schrijven. Hoe u dat organiseert, beschrijft Afhankelijkheden actueel houden.
Ten derde de externe diensten. Formulierdiensten, zoekfuncties, analysetools en ingebonden scripts draaien in de browser van de bezoekers of op vreemde servers. Elk van deze diensten is een vertrouwensrelatie, ook in het kader van gegevensbescherming.
Ten vierde de browserzijde. Ook een statische pagina moet beveiligingsheaders instellen, bijvoorbeeld een Content-Security-Policy die bepaalt welke scripts mogen worden geladen. De basis staat onder Beveiligingsheaders voor websites.
Controleer vóór een overstap welke functies uw website werkelijk gebruikt. Vaak zijn het er minder dan gedacht: pagina's, afbeeldingen, een contactformulier. Dan is de weg naar de statische website korter dan het eerst lijkt.
Voor wie de overstap loont en voor wie niet
Goed geschikt is een statische website voor bedrijfspagina's van overzichtelijke omvang, landingspagina's voor campagnes, productdocumentatie en carrièrepagina's. De overstap loont vooral als de bestaande website op een oude PHP-versie draait en een upgrade toch aan de orde was.
Minder geschikt is ze voor webshops, klantportalen, boekingssystemen en websites met veel redacteuren die dagelijks publiceren. Hier blijft een dynamisch systeem zinvol. Een mengvorm kan helpen: de shop blijft dynamisch en wordt goed verhard, adviespagina's en bedrijfspagina's worden statisch uitgeleverd.
Een vaak onderschat voordeel toont zich in een noodgeval. Omdat de kant-en-klare bestanden altijd opnieuw uit sjablonen en inhoud kunnen worden gebouwd, is een gemanipuleerde website snel terug te zetten naar een bekende, schone stand. Voorwaarde is dat inhoud en sjablonen in een beveiligde repository staan, wijzigingen navolgbaar worden gelogd en niemand de bestanden rechtstreeks op de server bewerkt.
Voor de overstap hebt u niet per se een beveiligingsdienstverlener nodig; dat kan een bureau of ontwikkelaar overnemen. Was de bestaande website gecompromitteerd, dan moet de inhoud vóór overname wel worden gecontroleerd. Daarop gaat Na de hack het CMS wisselen? in.
Hoe helpt PHP SOS concreet?
- Wij controleren welke functies uw website werkelijk nodig heeft en zeggen openlijk of een statische oplossing geschikt is.
- Wij beveiligen bij een overstap de toegangen tot hosting, domein en buildsysteem met tweefactorauthenticatie en persoonlijke accounts.
- Wij controleren externe diensten en stellen beveiligingsheaders in, zodat de nieuwe website ook in de browser goed is beschermd.
- Voor blijvende PHP-systemen nemen wij updates en bewaking over in het beveiligingsonderhoudscontract.
Conclusie
Een statische website is geen wondermiddel, maar voor veel bedrijfspagina's de eenvoudigste manier om een hele klasse risico's kwijt te raken. Waar geen PHP draait, kan PHP2Shell niets uitrichten. De gewonnen veiligheid houdt echter alleen stand als toegangen, afhankelijkheden en externe diensten even serieus worden genomen als vroeger de server.
Veelgestelde vragen
Kan een statische website toch worden gehackt?
Ja. De programmalogica aan serverzijde vervalt, en daarmee een grote klasse van aanvallen. Kwetsbaar blijven echter toegangen tot hosting, domein en buildsysteem, ingebonden externe diensten en de hulpmiddelen waarmee de site wordt gegenereerd.
Kan een statische website contactformulieren hebben?
Ja, via een externe formulierdienst of een kleine, afzonderlijk beheerde functie. Dan ligt de verwerking van de gegevens bij die dienst. Regel gegevensbescherming en verwerkersovereenkomst voordat u haar inbindt.
Kunnen redacteuren een statische website zelf onderhouden?
Met een passend redactiehulpmiddel wel. Veel oplossingen bieden een omgeving voor bewerken, waaruit de site daarna opnieuw wordt gegenereerd. Voor teams die dagelijks veel inhoud wijzigen, is een klassiek CMS echter vaak gemakkelijker.
Loont de overstap voor een webshop?
Meestal niet volledig. Winkelwagen, klantaccount en betaling vragen logica aan serverzijde. Mogelijk is delen zoals adviespagina's of bedrijfspagina's statisch uit te leveren en de shop afzonderlijk te beheren.