Een verlopen pluginlicentie verbergt ontbrekende updates

Bij veel betaalde plugins is de licentie gekoppeld aan toegang tot updates en support, niet aan het kunnen blijven draaien van de plugin. Na afloop blijft de plugin meestal werken, maar je beheerscherm toont mogelijk geen nieuwe versie meer of geeft geen downloadlink. Hoe dit precies werkt, verschilt per leverancier en per plugin. Lees dus de licentievoorwaarden en de documentatie van jouw leverancier in plaats van aan te nemen dat het overal zo gaat.

Het gevaarlijke effect is dat het gebrek aan melding op een veilige toestand lijkt. De pluginlijst toont geen update, dus je concludeert dat alles actueel is. In werkelijkheid kan de leverancier al een beveiligingsupdate hebben uitgebracht die je niet ontvangt. MDN beschrijft in zijn overzicht van webbeveiliging op https://developer.mozilla.org/en-US/docs/Web/Security dat goede operationele praktijk onder meer inhoudt dat je je afhankelijkheden onder controle houdt. Een plugin waarvan je het updatepad niet kunt zien of gebruiken, maakt het lastig om die afhankelijkheid onder controle te houden. Dat is onze eigen redactionele conclusie, geen uitspraak van MDN.

Maak voor elke betaalde plugin één rij in een inventaris. Doorloop deze stappen:

1. Noteer de geïnstalleerde versie zoals die in je beheeromgeving of pluginbestand staat, met datum van controle.
2. Zoek de laatste door de leverancier gepubliceerde versie op de officiële site, in de changelog of op de productpagina. Vergelijk die met je geïnstalleerde versie.
3. Noteer het updatepad: automatisch via het beheerscherm, handmatig via een downloadaccount, of via een externe partij. Controleer ook of het pad nog werkt met de huidige licentiestatus.
4. Leg de licentiestatus vast: einddatum, wie de licentie beheert, op welk account ze staat en welk e-mailadres de herinneringen krijgt.
5. Noteer de laatste bekende beveiligingsmelding in de changelog of aankondigingen van de leverancier en of die in jouw versie al is verwerkt.

Het verschil tussen stap 1 en stap 2 is je updatekloof. Een kloof betekent niet automatisch dat je kwetsbaar bent, maar je moet in de changelog nagaan wat tussen die versies is gewijzigd. Twijfel je over de inhoud van een wijziging, vraag dan je webbouwer of de leverancier om een duiding.

Een betaalde factuur zegt niets over of jij ook daadwerkelijk kunt updaten. Beoordeel daarom twee zaken los van elkaar:

• Financiële status: staat de licentie op de naam van je bedrijf, is ze betaald, wanneer eindigt ze en wie keurt de verlenging goed?
• Technische toegang: kan iemand uit je team of van je bureau nu inloggen op het leveranciersaccount, een update downloaden of een licentiesleutel opnieuw activeren?

Het komt voor dat een licentie op het persoonlijke account van een vertrokken medewerker of op het account van een vroegere bouwer staat. De factuur is betaald, maar niemand heeft nog toegang om een update op te halen. Controleer daarom ook wie recht heeft op de licentie en of je account beveiligd is. Google beschrijft op https://support.google.com/accounts/answer/185839 hoe je tweestapsverificatie aanzet voor een Google-account. De Google-pagina gaat alleen over Google-accounts. Controleer voor leveranciersaccounts los daarvan in de documentatie van de leverancier of tweestapsverificatie beschikbaar is, en zet die aan als dat kan. Beheer je een account via werk of school, dan kunnen instellingen door een beheerder bepaald zijn.

Gebruik dit overzicht per plugin, nadat je de inventaris hebt ingevuld.

Maak voor het verwijderen van een plugin eerst een back-up en test op een kopie van je site. Bij een bevestigd of sterk vermoed beveiligingsrisico wacht je met tijdelijk deactiveren niet op die test: maak wel een back-up en controleer daarna of de site nog werkt. Sommige plugins bewaren gegevens die bij verwijdering verloren gaan.

Een fictieve dienstverlener gebruikt een betaalde formulierplugin. Invoer: geïnstalleerde versie 4.2, licentie verlopen vorige maand, beheerscherm toont geen updatemelding. Het team volgt de procedure.

Stap 2 toont op de leverancierssite een recentere versie met in de changelog een vermelding van een beveiligingsfix. Stap 3: het updatepad liep via het beheerscherm en vraagt een actieve licentie. Stap 4: de licentie staat op het e-mailadres van een voormalige freelancer. Verwachte controles: (1) versieverschil bevestigd, (2) leveranciersaccount heeft nog een geldige eigenaar, (3) na herstel en verlenging laat de updatefunctie weer de nieuwste versie zien.

Beslisblad: plugin is belangrijk en de leverancier is actief, dus eerst eigendom herstellen en daarna verlengen en updaten. Tot die tijd beoordeelt de beheerder of de plugin tijdelijk uitgeschakeld kan worden en plant een test op een kopie van de site. Of beperkte toegang tot de formulierpagina's voldoende beschermt, is niet aangetoond. Het logboek bevat versie voor en na, datum van verlenging en de naam van de nieuwe licentiehouder. Geen enkel getal over risico of schade wordt hier aangenomen: het voorbeeld toont enkel welke gegevens je vastlegt en welke controles je uitvoert.

Plan een vaste frequentie voor je inventaris, bijvoorbeeld elke maand of na elke grote site-aanpassing. Zet de einddatum van elke licentie in een gedeelde agenda, met een herinnering ruim voor afloop. Wijs één verantwoordelijke aan voor de inventaris en één plaatsvervanger.

Houd rekening met de grenzen. Deze procedure helpt je risico's zichtbaar te maken, maar bewijst niet dat een versie veilig of onveilig is. Of een specifieke kwetsbaarheid jouw site raakt, hangt af van je configuratie en moet je beheerder of de leverancier beoordelen. Schermnamen, licentiemodellen en accountopties kunnen wijzigen; controleer ze bij je leverancier of webbeheerder. Deze gids is geen juridisch advies over licentieovereenkomsten.

Wil je zien welke zichtbare signalen je website uitstraalt over vertrouwen en onderhoud, bekijk die dan via Marketing Scan. Die publieke scan bekijkt wat van buitenaf zichtbaar is en voert niet alle controles uit die in deze gids staan.