Waarom een statische site veiliger is dan een WordPress-site

Beveiliging is zelden de eerste vraag bij een nieuwe website, tot er iets misgaat. Een gehackte site kost je vertrouwen, vindbaarheid en vaak een dure opkuis. Bij content-gerichte sites is er een structureel verschil tussen een WordPress-aanpak en een statische of edge-gerenderde Astro-site. Het draait allemaal om aanvalsoppervlak: hoeveel verschillende plekken er zijn waarlangs iemand binnen kan.

Waar zitten de risico’s echt?

De WordPress-kern zelf is relatief goed bewaakt. Het probleem zit in het ecosysteem eromheen. Volgens het State of WordPress Security-rapport van Patchstack werden er in 2024 7.966 nieuwe kwetsbaarheden in het WordPress-ecosysteem gevonden. De uitsplitsing is veelzeggend: 7.633 (96%) zaten in plugins van derden, 326 in thema’s en slechts 7 in WordPress zelf (via SecurityWeek). Het gevaar komt dus niet van WordPress, maar van wat je erbovenop installeert.

Dat is logisch: elke plugin is code van iemand anders, met eigen kwaliteit en eigen updateritme. Een gemiddelde WordPress-site draait al snel tien tot twintig plugins. Elke daarvan is een potentiële ingang, en elke daarvan moet onderhouden blijven.

Waarom zijn plugins zo’n zwak punt?

Plugins zijn precies wat WordPress zo populair maakt, en tegelijk de achilleshiel. Een paar terugkerende problemen:

• Verlaten plugins. Een ontwikkelaar stopt met onderhouden, maar de plugin draait door op duizenden sites, kwetsbaarheden incluis.
• Trage updates. Een lek wordt gepatcht, maar veel sites updaten pas weken later, of nooit.
• Te ruime rechten. Een plugin krijgt vaak meer toegang dan nodig, dus een lek in een klein onderdeel kan de hele site raken.
• Stapeling. Hoe meer plugins, hoe groter de kans dat er minstens één kwetsbaar is op een gegeven moment.

Minder bewegende delen

Een statische Astro-site bestaat uit vooraf gebouwde HTML, CSS en wat JavaScript voor de interactieve eilanden. Er is geen publieke database, geen admin-login op die database, en geen plugin-laag die bij elk bezoek code uitvoert.

Minder bewegende delen betekent minder dingen die kapot of misbruikt kunnen worden. Het verschil in aanvalsoppervlak is reeel:

	Statische Astro-site	Typische WordPress-site
Publieke database	Geen	Ja
Admin-login op de site	Geen (of apart beveiligd)	Ja, publiek bereikbaar
Plugins van derden	Geen verplichte laag	Vaak 10 tot 20+
Code uitgevoerd bij elk bezoek	Minimaal	PHP en plugins
Verplichte patchrondes	Dependencies, beperkt	Core, thema’s en alle plugins

Wat een statische site niet wegneemt

Eerlijk blijven hoort erbij. Een statische aanpak verkleint het risico, maar lost niet alles op. Deze punten blijven jouw verantwoordelijkheid:

• Hosting en DNS moeten correct geconfigureerd en beveiligd zijn.
• Externe scripts (analytics, embeds, chatwidgets) brengen hun eigen risico mee.
• Je dependencies kunnen kwetsbaarheden bevatten; houd ze up-to-date.
• Formulieren en endpoints moeten validatie en bescherming tegen misbruik hebben.

De winst is dat je de grootste en meest voorkomende categorie WordPress-incidenten, kwetsbare plugins, gewoon niet hebt. De OWASP Top 10 blijft een nuttige checklist voor wat er wel overblijft.

En als je toch dynamiek nodig hebt?

Een site is zelden volledig statisch. Een contactformulier, een zoekfunctie of een persoonlijk stukje hoort er vaak bij. De aanpak verschilt van die van een altijd-draaiende CMS-laag:

• Formulieren verwerk je via een server-side endpoint (bijvoorbeeld Astro Actions) met validatie, rate-limiting en een honeypot tegen bots.
• Persoonlijke of live delen render je via server islands, apart van de statische hoofdcontent.
• Geheimen zoals API-sleutels blijven server-side, nooit in de browser.

Zo voeg je dynamiek gericht toe, op de plekken waar het moet, in plaats van een volledige CMS-laag permanent te laten draaien.

Onderhoud als beveiliging

Veel beveiligingsincidenten komen niet door geavanceerde aanvallen, maar door uitgestelde updates. Een WordPress-site met tientallen plugins vraagt de discipline van wekelijks patchen, en die discipline ontbreekt vaak. Een statische site verkleint die last: minder afhankelijkheden die publiek draaien, minder dringende patchrondes, minder kans dat een vergeten update een gat openlaat.

Een checklist voor een veilige Astro-site

• Houd je dependencies up-to-date en verwijder wat je niet gebruikt.
• Verwerk formulieren server-side, met validatie en rate-limiting.
• Bewaar geheimen in de serveromgeving, nooit in clientcode.
• Beperk en controleer externe scripts van derden.
• Zet beveiligingsheaders (zoals een Content Security Policy) goed op.
• Gebruik HTTPS en een correcte hosting- en DNS-configuratie.

Conclusie

Veiligheid is geen functie die je achteraf aanzet, het is een gevolg van architectuur. Door geen publieke database en geen permanente plugin-laag te draaien, vermijdt een statische of edge-gerenderde Astro-site een groot deel van de risico’s die WordPress-sites het vaakst treffen. Geen enkele site is honderd procent onkwetsbaar, maar voor een marketingsite, blog of bedrijfssite is een klein aanvalsoppervlak een sterk en concreet argument. Meer over de afweging lees je in Astro vs WordPress.