Opeenvolgende beveiligingsincidenten: 'Inbraakpreventie' en 'schadebeperkking' vereist voor websystemen

Sinds het begin van 2026, en vooral de afgelopen maanden, neemt het aantal meldingen van ongeautoriseerde toegang en gegevenslekken op websystemen van binnenlandse bedrijven toe.
Op 8 oktober maakte JPCERT/CC een waarschuwing openbaar over 'waarschuwingen voor opeenvolgende ongeautoriseerde toegang bij binnenlandse organisaties', en op 9 oktober riep IPA noodmaatregelen op in het licht van gegevenslekken door ongeautoriseerde toegang.

Bij het bezien van dergelijke incidenten richten we ons vaak op problemen met oude systemen of verouderde software.
Hoewel dit natuurlijk grote risico's zijn, is het niet zo eenvoudig dat de veiligheid verbetert wanneer u uw systeem vernieuwt.

Het is belangrijk om maatregelen ter voorkoming van inbraak zorgvuldig door te voeren, en in het geval dat zich toch een veiligheidsprobleem voordoet, een gelaagde verdedigingsontwerp dat de schade beperkt is essentieel.

Dit keer heb ik naar websecurity in de toekomst gekeken aan de hand van voorbeelden van Cloudflare, Supabase en EmDash, dat in september 2026 officieel is uitgebracht.

Ongeautoriseerde toegang richt zich niet alleen op speciale bedrijven

JPCERT/CC behandelt in deze waarschuwing niet alleen aanvallen gericht op bekende kwetsbaarheden, maar ook verkenning van configuratiebestanden en back-upbestanden, ongeautoriseerde aanvragen aan API's, misbruik van gestolen API-sleutels en inbraak naar het interne netwerk via openbare webservers als uitgangspunt. De aanvalsmethoden zijn divers.

Wat bijzonder opvalt is dat niet alleen services voor algemene gebruikers, maar ook beheersystemen en BI-hulpprogramma's voor medewerkers doelen van aanvallen zijn.
Met de ontwikkeling van AI verdwijnt het vroegere concept dat het goed is als Google het niet indexeert, en systemen die op internet zijn gepubliceerd, kunnen onmiddellijk onderhevig zijn aan geautomatiseerde verkenning en aanvallen op dagelijkse basis.

De gedachte dat 'ons kleine systeem niet doelwit wordt!' is niet meer geldig.

Leidt het gebruik van moderne technologie tot veiligheid?

Oude PHP, frameworks waarvan de ondersteuning is beëindigd, en CMS'en die jarenlang niet zijn bijgewerkt, vormen uiteraard risico's.
Is het veilig als je met Next.js of Astro bouwt en cloudservices gebruikt?

Helaas is dat niet altijd het geval. 😭

Zelfs in de nieuwste frameworks worden kwetsbaarheden ontdekt, en als er fouten zitten in de autorisatieverwerking van de API, kunnen gegevens waartoe eigenlijk geen toegang mag worden verkregen worden opgehaald.
Wanneer authenticatiegegevens of API-sleutels verkeerd worden beheerd, kan zelfs een robuuste cloudservice beschadigingen veroorzaken. Daarom is het hebben van nieuwe technologie en het hebben van een veilig systeem twee verschillende zaken.

Beveiliging voor applicaties plaatsen met Cloudflare

Cloudflare staat bekend als CDN, maar speelt ook een belangrijke rol wanneer je nadenkt over de beveiliging van webapplicaties.
Met behulp van WAF (Web Application Firewall) kun je bijvoorbeeld verdachte verzoeken detecteren en blokkeren, of grote hoeveelheden verkeer beperken via snelheidsbeperkingen. Met Cloudflare Access kun je toegang tot beheerinterfaces voor intern gebruik beperken tot geverifieerde gebruikers.

Dat gezegd hebbende, is het niet zonder meer perfect. 😭
Het feit dat beheerinterfaces die niet voor publiek gebruik bestemd zijn voor iedereen toegankelijk zijn, vormt zelf een risico.

Met WAF kun je niet alle aanvallen voorkomen. Misbruik van verzoeken in de juiste indeling en autorisatiefouten specifiek voor applicaties vereisen afzonderlijke maatregelen.
Cloudflare stelt een verdedigingsmechanisme in voor applicaties, maar garandeert niet de veiligheid van de applicatie zelf.

Toegangsbeheer ook aan de databasezijde controleren met Supabase

Wat we hier willen bespreken is RLS (Row Level Security), beschikbaar in Supabase.
RLS is een PostgreSQL-functie waarmee je de toegangsreikwijdte op rijniveau in de database kunt bepalen. In bijvoorbeeld een werktoepassing die door meerdere bedrijven wordt gebruikt, kun je regels instellen op databasezijde zodat gebruikers van bedrijf A alleen gegevens van bedrijf A kunnen bekijken.
Zelfs wanneer er fouten in de autorisatieverwerking aan toepassingszijde voorkomen, fungeert correct geconfigureerde RLS als extra verdediging.

Maar... RLS is ook niet altijd een wondermiddel als je het eenmaal configureert. 😭

De secret key van Supabase of traditionele service_role-sleutel hebben sterke rechten die RLS kunnen omzeilen afhankelijk van hoe ze worden gebruikt, dus als het beheer foutief is, biedt RLS geen bescherming.
Het configureren van tabelrechten en het testen van beleid zijn onmisbaar.

Het belangrijkste is de autorisatie niet alleen aan de applicatie over te laten, maar ook onafhankelijke controle in de database in te stellen.

EmDash vertrouwt standaard plug-ins niet

Op 28 september 2026 werd "EmDash 1.0", een CMS dat wordt ontwikkeld met ondersteuning van Cloudflare, uitgebracht, en werd ook het officiële pluginregister gepubliceerd!
Wij volgen het sinds de release en hebben al sites ermee geïmplementeerd, dus het is erg emotioneel voor ons.

Een meertalige blog maken met EmDash ~ hoe je API-kosten voor vertalingen bij SSR verlaagt
Van microCMS naar EmDash + Cloudflare migreren

Wat interessant is aan EmDash, is het beveiligingsmodel van plug-ins.
Bij traditionele CMS-systemen kunnen plug-ins worden uitgevoerd met rechten die dicht bij die van de CMS-kern liggen, waardoor beveiligingsproblemen in plug-ins het hele systeem kunnen beïnvloeden, maar plug-ins uit het officiële EmDash-register worden uitgevoerd in een sandbox.
Door de functies en bronnen die plug-ins kunnen gebruiken te beperken en vereiste rechten duidelijk aan te geven, wordt de impact beperkt.

Natuurlijk bestaan er in EmDash ook native plug-ins die geen sandbox gebruiken, en niet alle plug-ins zijn veilig, en EmDash zelf is een relatief nieuw CMS, dus we moeten de toekomstige operationele resultaten en beveiligingsrespons blijven volgen.

Toch plug-ins niet van meet af aan volledig vertrouwen is een ontwerpfilosofie die de aandacht verdient wanneer we nadenken over toekomstige CMS-systemen.

Wat ze gemeen hebben, is het denkpatroon "vertrouw niet alles"

Cloudflare, Supabase en EmDash zijn services met verschillende rollen, maar vanuit beveiligingsperspectief zien we een gemeenschappelijke benadering.

• Cloudflare: Verdacht verkeer blokkeren voor de applicatie
• Supabase: Toegangsrechten beheren aan de databasezijde, ook voor verzoeken vanuit de applicatie
• EmDash: De uitvoeringsomgeving isoleren door plugins niet meer rechten te geven dan nodig

Al deze benaderingen vertrouwen niet op één enkel mechanisme voor veiligheid, maar beperken het bereik van vertrouwen – een gedachte die aansluit bij zero trust en het principe van minimale privileges, niet waar?

• Zelfs als authenticatie wordt omzeild, zijn niet alle bewerkingen toegestaan.
• Zelfs als de API gebreken heeft, zijn niet alle gegevens toegankelijk.
• Zelfs als een plugin een beveiligingslek heeft, kan het hele systeem niet worden gemanipuleerd.

Door deze grenzen in te stellen, verkleinen we het risico dat één probleem tot schade in het hele systeem leidt.

Samenvatting: Indringers buiten houden en schade minimaliseren

React ingevoerd! Next.js ingevoerd! Naar de cloud gemigreerd!
Deze technische updates hebben hun waarde, maar (hoewel het inmiddels voelt als een oud verhaal), het vervangen van frameworks en infrastructuur is nog niet voldoende voor echte modernisering. Het is belangrijk om authenticatie, autorisatie, API, database en externe services goed in kaart te brengen – de verantwoordelijkheden en rechten duidelijk af te stemmen en een structuur te creëren waarin één beveiligingsinbreuk niet gemakkelijk naar andere gebieden verspreidt.

Er bestaat geen absoluut in beveiliging.
Daarom is het essentieel meerdere verdedigingslagen in te stellen om inbraken te voorkomen, en zelfs wanneer problemen ontstaan, moet het systeem zo ontworpen zijn dat schade kan worden beperkt.

Cloudflare, Supabase en EmDash zijn niet alomvattend, maar deze technologieën hebben mechanismen ingebouwd om alleen de benodigde machtigingen te verlenen en grenzen tussen rollen in te stellen.

Bij Liberogic richten we ons bij de bouw van websystemen niet alleen op het toepassen van nieuwe technologieën, maar besteden we grote aandacht aan verantwoordelijkheidscheiding en verdedigingslagen.

Nu beveiligingsincidenten elkaar opvolgen, is het bij het moderniseren van websystemen belangrijk om niet alleen aandacht te besteden aan "welke technologie we gebruiken", maar ook aan "hoe ver het ontwerp erop vertrouwt".