| Pluginnaam | WordPress Aankoopknop Voor Affiliate Link plugin |
|---|---|
| Type kwetsbaarheid | CSRF |
| CVE-nummer | CVE-2026-1073 |
| Urgentie | Laag |
| CVE-publicatiedatum | 2026-03-07 |
| Bron-URL | CVE-2026-1073 |
CVE-2026-1073: CSRF in “Aankoopknop Voor Affiliate Link” (≤ 1.0.2) — Wat nu te doen
Een kwetsbaarheid voor Cross-Site Request Forgery (CSRF) van lage ernst is gerapporteerd in de WordPress-plugin “Aankoopknop Voor Affiliate Link” die versies tot en met 1.0.2 (CVE-2026-1073) beïnvloedt. Hoewel de openbare samenvatting deze kwestie een lage ernst toekent (CVSS 4.3) en aangeeft dat succesvolle uitbuiting gebruikersinteractie van een bevoegde gebruiker vereist, verdient het nog steeds onmiddellijke aandacht van site-eigenaren en beheerders omdat het ongeauthenticeerde aanvallers in staat stelt om te proberen plugin-instellingen bij te werken via vervalste verzoeken.
In deze post zullen we:
- Leg uit wat de kwetsbaarheid in praktische termen betekent.
- Loop door de waarschijnlijke technische oorzaak en realistische impact.
- Geef detectie- en incidentresponsstappen.
- Geef aanbevelingen voor verhoging van de beveiliging en ontwikkelaars om CSRF te voorkomen.
- Leg uit hoe een applicatie-firewall en virtuele patching het risico vandaag kunnen verminderen.
- Geef een korte, vriendelijke uitnodiging om de gratis bescherming van WP-Firewall voor WordPress-sites uit te proberen.
Deze richtlijn is geschreven vanuit het perspectief van professionele WordPress-beveiligingspraktijk. De toon is praktisch en procedureel — zodat je snel en vol vertrouwen kunt handelen.
Korte samenvatting (TL;DR)
- Beïnvloedde plugin: Aankoopknop Voor Affiliate Link
- Kwetsbare versies: ≤ 1.0.2
- Kwetsbaarheidstype: Cross-Site Request Forgery (CSRF) — instellingen bijwerken
- CVE: CVE-2026-1073
- Ernst: Laag (CVSS 4.3) — gebruikersinteractie vereist (een bevoegde gebruiker moet worden misleid)
- Impact: De aanvaller kan mogelijk plugin-instellingen wijzigen als een bevoegde gebruiker (bijv. een admin) wordt verleid om een kwaadaardige pagina te bezoeken of op een vervalste link te klikken.
- Onmiddellijke acties: Controleer je site op de plugin, deactiveer of verwijder deze als deze niet nodig is; anders toepassen van mitigatielaag (WAF-regels, admin-versterking, 2FA) en zorgvuldig monitoren.
Wat is CSRF en waarom is dit belangrijk voor WordPress-plugins
Cross-Site Request Forgery (CSRF) vindt plaats wanneer een aanvaller de browser van een geauthenticeerde gebruiker misleidt om een ongewenst verzoek te doen aan een webapplicatie waar de gebruiker is geauthenticeerd. Wanneer dat verzoek statuswijzigingen uitvoert (instellingen bijwerken, inhoud creëren, gegevens verwijderen), veroorzaakt de aanvaller indirect dat die wijzigingen plaatsvinden met de privileges van het slachtoffer.
In WordPress moeten plugins die admin-acties of instellingen-eindpunten blootstellen, valideren dat verzoeken afkomstig zijn van een legitieme bron - meestal met behulp van nonces (wp_nonce_field + check_admin_referer) of capaciteitscontroles (current_user_can(…)). Als ze dat niet doen, kan een aanvaller een HTML-formulier, afbeeldings-tag of script maken dat op een ander domein is gehost en dat, wanneer het door een admin wordt bezocht, de browser van die admin een POST-indiening veroorzaakt die de instellingen van de plugin wijzigt.
Zelfs als de kwetsbaarheid als laag risico wordt geclassificeerd, kunnen de gevolgen in de praktijk aanzienlijk zijn. Instellingupdates kunnen affiliate-links omleiden naar door de aanvaller gecontroleerde bestemmingen, tracking-ID's wijzigen, kwaadaardige payloads inschakelen (afhankelijk van welke instellingen er zijn) of verwarring en reputatieschade veroorzaken. Omdat de exploit sociale engineering vereist (een admin laten klikken of bezoeken), zijn veel exploitketens opportunistisch maar niet onmogelijk.
Waarschijnlijke technische oorzaak (wat de plugin waarschijnlijk verkeerd doet)
De openbare waarschuwing geeft een CSRF-kwetsbaarheid aan die instellingenupdates toestaat. In de meeste vergelijkbare gevallen zijn de oorzaken:
- Ontbrekende nonce-verificatie: het instellingen-eindpunt dat POST-instellingen verwerkt, roept check_admin_referer() / check_ajax_referer() niet aan of verifieert op een andere manier geen geldige WordPress nonce voordat opties worden bijgewerkt.
- Ontbrekende capaciteitscontrole: de handler valideert current_user_can(‘manage_options’) (of een geschikte capaciteit) niet om ervoor te zorgen dat de huidige gebruiker is toegestaan om die instellingen te wijzigen.
- Instellingen toegankelijk vanaf niet-geauthenticeerde eindpunten: de plugin blootstelt een publiek bereikbare URL of actienaam die POST-gegevens accepteert en opties bijwerkt zonder voldoende authenticatie of validatie.
- Gebruik van GET in plaats van POST voor operaties die de status wijzigen (vandaag minder gebruikelijk maar nog steeds gezien).
Een van de bovenstaande, of een combinatie, kan de deur openen voor CSRF.
Realistische impactscenario's
Het begrijpen van praktisch risico helpt bij het prioriteren van de reactie.
- Omgeleide affiliate-inkomsten:
- Als de plugin de bestemmings-URL's of affiliate-ID's in instellingen opslaat, kan een aanvaller deze wijzigen om naar aanvallers-tracking te wijzen, waardoor verwijzingen of commissies worden gestolen.
- Inhoudsintegriteit of UX-wijzigingen:
- Gewijzigde instellingen kunnen knoppen breken, naar ongepaste inhoud wijzen of de site er onbetrouwbaar uit laten zien - wat resulteert in verloren conversies en reputatieschade.
- Pivot naar verdere exploitatie (beperkt maar mogelijk):
- Hoewel deze bug op zichzelf een vector voor instellingenupdates is, kunnen in sommige configuraties gewijzigde instellingen leiden tot nieuwe XSS-vectoren (bijvoorbeeld als plugininstellingen ongeëscapete HTML accepteren en de site deze zonder sanitization uitvoert). Neem altijd aan dat er ketenrisico's bestaan totdat ze zijn uitgesloten.
- Laag onmiddellijke destructieve capaciteit:
- Omdat exploitatie vereist dat een bevoorrechte gebruiker wordt overtuigd om een verzoek te activeren, is massale geautomatiseerde exploitatie moeilijker. Echter, gerichte sociale-engineeringaanvallen tegen drukke admins (e-mail, gecompromitteerde derde-partijpagina's) kunnen effectief zijn.
Kortom: de kwetsbaarheid is laag op de standaard schaal, maar de zakelijke impact - vooral voor eCommerce/affiliate-sites - kan aanzienlijk zijn.
Hoe te controleren of je bent getroffen (checklist voor site-eigenaren)
- Inventariseer uw plugins:
- Log in op WordPress en controleer of “Purchase Button For Affiliate Link” is geïnstalleerd en controleer de versie. Als het niet is geïnstalleerd, wordt u niet direct getroffen door de kwetsbaarheid van deze plugin.
- Als het is geïnstalleerd, bepaal de versie:
- Bezoek het Plugins-scherm en controleer de versie. De waarschuwing vermeldt versies ≤ 1.0.2 als kwetsbaar.
- Als kwetsbaar, overweeg onmiddellijke verwijdering:
- Als u de plugin niet actief gebruikt, deactiveer en verwijder deze dan onmiddellijk.
- Als je het moet behouden:
- Isolateer admin-activiteit en versterk (zie mitigaties hieronder). Behandel de plugin als “ongeloofwaardige code” totdat deze is gepatcht.
- Zoek naar tekenen van manipulatie:
- Vergelijk de waarden van de plugininstellingen met verwachte waarden - in het bijzonder eventuele URL's, ID's of omleidingsdoelen.
- Controleer de opties tabel op onverwachte vermeldingen:
- Gebruik WP‑CLI of een databaseclient om recent gewijzigde opties te bekijken.
- Voorbeeld (WP-CLI):
wp optie lijst --formaat=tafel | grep aankoop - Controleer op verdachte waarden in opties die verwijzen naar externe URL's of onbekende domeinen.
- Bekijk de admin-activiteitslogboeken:
- Als u auditlogging hebt ingeschakeld (aanbevolen), bekijk dan recente wijzigingen in opties en plugininstellingen. Noteer tijd, gebruiker en IP. Als een wijziging verschijnt zonder een bijbehorende admin-actie, beschouw het dan als verdacht.
- Zoek in webserverlogboeken:
- Inspecteer POST-verzoeken die pluginopties hebben gewijzigd of de admin-eindpunten van de plugin hebben aangeraakt tijdens de zorgwekkende tijdsperiode. Focus op verzoeken zonder legitieme admin-verwijzingen.
- Controleer op nieuwe achterdeurtjes of accounts:
- Als er enige aanwijzing is van compromittering buiten de instellingen, bekijk dan gebruikers, geplande taken (cron) en plugin/thema-bestanden op onverwachte code.
Onmiddellijke mitigaties (wat te doen in de eerste 24 uur)
- Deactiveer/verwijder de plugin als je deze niet nodig hebt:
- Dit is de snelste manier om het directe aanvalsvlak te elimineren.
- Als je het moet behouden, beperk dan de toegang voor beheerders:
- Beperk wie toegang heeft tot het beheerdersgebied (via IP-toegangslijst, VPN, of door het beheerdersgebied achter HTTP basisauthenticatie te plaatsen).
- Handhaaf sterke wachtwoorden en schakel multi-factor authenticatie (MFA) in voor alle beheerders.
- Versterk beheerderssessies en cookies:
- Zorg ervoor dat WordPress-cookies waar mogelijk SameSite=Lax/Strict gebruiken (dit wordt op serverniveau of via plugins geconfigureerd).
- Verkort de sessietijd voor bevoegde gebruikers.
- Pas WAF / virtuele patching toe:
- Configureer je site-niveau WAF om verdachte CSRF-patronen en externe POST-verzoeken die gericht zijn op beheerders-eindpunten te blokkeren. Zie de WAF-richtlijnen hieronder.
- Controleer en roteer inloggegevens:
- Als je vermoedt dat een beheerder is misleid om actie te ondernemen, roteer dan SSO/API-tokens, reset beheerderswachtwoorden en maak open sessies ongeldig (Tools → Sessies of gebruik plugins/WP-CLI om sessies te beëindigen).
- Houd nauwlettend toezicht:
- Verhoog de monitoring van logs en stel waarschuwingen in voor wijzigingsinstellingen, nieuw aangemaakte beheerdersgebruikers of uitgaande verbindingen naar onbekende domeinen.
- Plan een onderhoudsvenster:
- Plan om de plugin bij te werken wanneer een gepatchte versie beschikbaar is, en test updates eerst in een staging-omgeving.
Hoe een applicatiefirewall (WAF) helpt — praktische WAF-strategieën
Een goed geconfigureerde WAF biedt een bijna onmiddellijke mitigatie (virtuele patch) terwijl je wacht op de leverancier om een officiële oplossing vrij te geven. Aanbevolen WAF-interventies:
- Blokkeer niet-geauthenticeerde verzoeken die proberen te schrijven naar plugin-beheerders-eindpunten:
- Veel CSRF-vectoren zullen POST-verzoeken zijn naar beheerders-URL's die geen geldige WordPress-nonces hebben. Maak regels die geldige nonce-tokens vereisen voor statusveranderende POST's; als een geldig token ontbreekt, blokkeer of daag het verzoek uit.
- Handhaaf referer- en oorsprongbeleid:
- Blokkeer cross-origin POST's naar beheerders-eindpunten waar de verzoekorigine / referer niet overeenkomt met jouw site of bekende beheerders-hostnamen. Opmerking: referer-controles kunnen in sommige gevallen worden omzeild en mogen niet je enige verdediging zijn.
- Beperk en blokkeer verdachte geautomatiseerde verkeer:
- Als een aanvalspoging geautomatiseerd is, zal rate limiting het vertragen of stoppen.
- Inline inhoudinspectie om formulierindieningen te detecteren die gericht zijn op bekende plugin-actienamen:
- Veel plugins gebruiken specifieke actienamen (admin_post, admin_ajax of aangepaste acties). Maak regels die deze actienamen in combinatie met ontbrekende nonce-velden monitoren en blokkeer dienovereenkomstig.
- Virtuele patching-handtekening:
- Als de kwetsbare plugin een kenmerkend URL-patroon of formulier veldnamen gebruikt, kan een conservatieve WAF-handtekening POST-verzoeken die gericht zijn op dat patroon van externe verwijzers blokkeren.
- Logging en waarschuwingen:
- Log alle geblokkeerde pogingen en configureer waarschuwingen naar het admin-e-mailadres of Slack. Dit helpt om gebeurtenissen te correleren met andere tekenen van inbraak.
Belangrijk: WAF-regels moeten worden getest om te voorkomen dat legitieme admin-werkstromen worden verbroken. Implementeer blokkades eerst in detectiemodus, bekijk valse positieven en schakel vervolgens over naar actieve blokkering.
Ontwikkelaarsrichtlijnen — hoe plugin-auteurs dit moeten oplossen
Als je de plugin-ontwikkelaar bent of met de auteur werkt, implementeer deze wijzigingen onmiddellijk:
- Vereis nonces voor alle statusveranderende verzoeken:
- Geef een nonce in het instellingenformulier weer met
wp_nonce_field('purchase_button_save_settings', 'purchase_button_nonce'). - Valideer met
check_admin_referer('purchase_button_save_settings', 'purchase_button_nonce')voordat je het verzoek verwerkt.
- Geef een nonce in het instellingenformulier weer met
- Controleer gebruikerscapaciteiten:
- Voordat je opties wijzigt, roep
huidige_gebruiker_kan('opties_beheren')(of een andere geschikte bevoegdheid) aan om ervoor te zorgen dat alleen geautoriseerde gebruikers instellingen kunnen wijzigen.
- Voordat je opties wijzigt, roep
- Gebruik POST voor statuswijzigingen en valideer invoer:
- Zorg ervoor dat instellingenupdates alleen POST accepteren en valideer/sanitiseer alle binnenkomende waarden (esc_url_raw voor URL's, sanitize_text_field, intval voor numerieke ID's, enz.).
- Geef de voorkeur aan de Settings API:
- Gebruik de WordPress Settings API om opties te registreren en op te slaan, wat nonce- en bevoegdheidshandhaving vereenvoudigt.
- Verhard eindpunten:
- Vermijd het blootstellen van openbare eindpunten die instellingen wijzigen. Als je openbare eindpunten nodig hebt (bijv. REST API), implementeer dan de juiste machtigingscallbacks.
- Sanitize output:
- Bij het weergeven van instellingen op de pagina, ontsnap ze correct (esc_attr, esc_url, esc_html) om opgeslagen XSS te voorkomen als slechte invoer op de een of andere manier is opgeslagen.
- Eenheid/Integratietests:
- Voeg geautomatiseerde tests toe die ervoor zorgen dat instellingen niet kunnen worden bijgewerkt wanneer nonces ongeldig zijn of wanneer gebruikers geen rechten hebben.
Deze wijzigingen zijn eenvoudige codering hygiëne en moeten worden geïmplementeerd, zelfs voor kleine plugins.
Detectie recepten en auditopdrachten
Hieronder staan veilige, onderzoeker-gerichte controles om te helpen bepalen of plugininstellingen zijn gewijzigd of dat uw site is doelwit. Dit zijn onderzoeksstappen, geen exploit-instructies.
- Doorzoek de database naar waarschijnlijke optienamen:
SELECT option_name, option_value FROM wp_options WHERE option_name LIKE '%purchase%' OF option_value LIKE '%purchase%';
Of gebruik WP‑CLI:
wp optie lijst --format=json | jq '.[] | select(.option_name|test("purchase";"i"))' - Bekijk recente wijzigingen in pluginbestanden:
- Vergelijk pluginbestanden met een schone kopie (download de plugin zip en controleer de verschillen).
- Controleer de tijdstempels van bestandswijzigingen:
find wp-content/plugins/purchase-button -type f -printf "%TY-%Tm-%Td %TT %p
- Inspecteer serverlogs op verdachte POST's naar admin-eindpunten:
- Zoek naar POST-verzoeken naar
/wp-beheerder/*ofadmin-ajax.phpofadmin-post.phpmet ongebruikelijke verwijzers of met actie-waarden die plugin opslaatroutines activeren.
- Zoek naar POST-verzoeken naar
- Controleer gebruikers en rollen:
wp user list --role=administrator --format=table
Controleer de laatste inlogtijden als uw setup ze logt.
- Controleer geplande taken:
wp cron-gebeurtenislijst
Zoek naar vermeldingen die zijn gekoppeld aan de plugin of onbekende taken.
Als u onverwachte wijzigingen vindt, bewaar dan logs en bewijs en volg uw incidentresponsplan.
Checklist voor incidentrespons (als u misbruik vermoedt)
- Isoleren:
- Als het mogelijk is, zet de site in onderhoudsmodus of blokkeer openbare toegang terwijl u onderzoekt.
- Bewijs bewaren:
- Verzamel logs (web, PHP, database), een kopie van wp_options en pluginbestanden voor latere forensische analyse.
- Intrekken en roteren:
- Reset adminwachtwoorden, intrek API-sleutels en beëindig sessies.
- Verwijder de aanvalsvector:
- Deactiveer de kwetsbare plugin, of pas gerichte WAF-blokken toe die verdere exploitatie voorkomen.
- Herstel en reinig:
- Als er wijzigingen zijn aangebracht in instellingen of bestanden, overweeg dan om te herstellen vanaf een bekende goede back-up en pas noodzakelijke, veilige configuratiewijzigingen opnieuw toe.
- Post-incident:
- Hardening checklist (schakel MFA in voor admins, implementeer WAF, schakel auditlogging in, beperk admin-toegang, controleer plugins en thema's).
- Melden:
- Informeer belanghebbenden, en als de aanval betrokken was bij gegevensblootstelling, volg dan de toepasselijke meldingsverplichtingen.
Langdurige preventie - aanbevelingen voor site-eigenaren
- Behoud een minimale plugin-voetafdruk:
- Installeer alleen plugins die je actief gebruikt en houd ze up-to-date. Controleer plugins maandelijks.
- Gebruik rol met de minste privileges:
- Wijs site-rollen zorgvuldig toe. Vermijd het gebruik van admin-accounts voor routinetaken zoals inhoudsbeheer.
- Handhaaf sterke authenticatie:
- Schakel MFA in voor administratieve accounts; gebruik gecentraliseerde SSO waar mogelijk.
- Schakel auditlogging in:
- Registreer admin-acties, optie-wijzigingen, inlogpogingen en bestandsbewerkingen om anomalieën eerder te detecteren.
- Houd back-ups bij:
- Regelmatige, geautomatiseerde off-site back-ups stellen je in staat om snel te herstellen als instellingen of bestanden worden aangetast.
- Implementeer gefaseerde updates:
- Test updates op een staging-site voordat je ze op productie toepast.
- Houd kwetsbaarheden in de gaten:
- Gebruik kwetsbaarheidsinformatie en update-nieuwsbrieven om te weten wanneer plugins die je gebruikt als kwetsbaar worden gerapporteerd.
Voorbeeld WAF-regeloverzicht (conceptueel, niet-uitvoerbaar)
Hieronder staan hoog-niveau regelideeën die geschikt zijn als uitgangspunt voor een WAF of beveiligingsteam om te implementeren. Deze zijn opzettelijk conceptueel zodat ze kunnen worden aangepast aan uw omgeving:
- Regel: Blokkeer POST-verzoeken naar admin-instellingen eindpunt zonder geldige nonce
- Voorwaarde: HTTP-methode == POST EN Verzoekspad komt overeen met plugin-instellingen URL-patroon EN POST-lichaam bevat geen bekende nonce-parameter EN Referer komt niet overeen met domein van de site
- Actie: Uitdaging (CAPTCHA) of Blokkeren
- Regel: Vereis Origin/Referer voor admin-schrijfacties
- Voorwaarde: HTTP-methode == POST EN verzoekspad onder /wp-admin/ EN Origin/Referer komt niet overeen met domein van de site
- Actie: Blokkeer of daag uit
- Regel: Beperk het aantal verdachte POST-verzoeken naar admin-eindpunten van dezelfde bron
- Voorwaarde: > X POST-verzoeken per minuut naar /wp-admin/ of admin-ajax.php voor anonieme sessies
- Actie: Tijdelijke blokkade
- Regel: Waarschuw bij wijzigingen in bekende plugin-optiesleutels
- Voorwaarde: Uitgaand verzoek of backend-gebeurtenis die optiesleutels bijwerkt (gecontroleerd via applicatielogs of bestandsintegriteit)
- Actie: Waarschuw het beveiligingsteam
Werk samen met uw WAF-provider of uw hostingteam om regels zorgvuldig te implementeren en te testen om valse positieven te voorkomen.
Ontwikkelaarschecklist om een veilige patch uit te brengen
Als u de plugin onderhoudt, publiceer dan een fix die omvat:
- Nonce-bescherming voor instellingenformulieren.
- Capaciteitscontroles op alle admin-acties.
- Sanitizing en escaping van invoer en uitvoer.
- Eenheid/integratietests die ervoor zorgen dat ongeautoriseerde verzoeken instellingen niet kunnen wijzigen.
- Duidelijke changelog en upgrade-instructies voor gebruikers.
- Een verantwoordelijke openbaarmaking notitie die wijzigingen beschrijft.
Informeer gebruikers duidelijk over de urgentie en geef handmatige mitigatiestappen in de release-opmerkingen.
Bescherm uw WordPress-site in enkele minuten met WP‑Firewall — gratis plan beschikbaar
Als u een WordPress-site beheert en onmiddellijke, praktische bescherming wilt tegen plug-in kwetsbaarheden zoals deze CSRF, probeer dan het WP‑Firewall Basic (Gratis) plan. Onze gratis laag omvat een beheerde applicatiefirewall, een actief onderhouden Web Application Firewall (WAF) regelset, onbeperkte bandbreedte voor filtering en een malware-scanner — alles wat u nodig heeft om OWASP Top 10 risico's te mitigeren en de blootstelling te verminderen terwijl u permanente oplossingen toepast. Voor sites die meer nodig hebben, voegen onze Standaard en Pro plannen automatische malwareverwijdering, allowlist/blacklist-controles, virtuele patches, maandelijkse beveiligingsrapporten en beheerde diensten toe. Begin nu met uw gratis bescherming: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Laatste woorden — praktische prioriteiten voor site-eigenaren op dit moment
- Controleer of de “Purchase Button For Affiliate Link” plug-in is geïnstalleerd en welke versie u gebruikt.
- Als u de plug-in niet nodig heeft — deactiveer en verwijder deze nu.
- Als u deze moet gebruiken, verstevig dan het beheerdersgebied (MFA, sterke wachtwoorden, IP-beperkingen), implementeer een WAF-regel om verdachte admin POST's te blokkeren en monitor logs nauwlettend.
- Werk samen met de plug-in auteur om een gepatchte release te verkrijgen; als u de ontwikkelaar bent, volg dan de ontwikkelaarschecklist hierboven en publiceer een duidelijke, urgente update.
- Overweeg om een beveiligingsplan en een regelmatig audit-schema bij te houden: onderhoud een plug-in inventaris, test updates op staging, schakel logging en back-ups in.
Beveiliging is gelaagd. CSRF is een klassiek te voorkomen probleem; het verminderen van blootstelling vereist zowel ontwikkelaarsoplossingen als operationele controles. Als u een snelle, laagdrempelige verdedigingslaag wilt terwijl oplossingen worden geïmplementeerd, zijn een beheerde WAF plus administratieve versteviging uw beste eerste stappen.
Als u op maat gemaakte begeleiding nodig heeft voor een specifieke site of hulp bij het implementeren van WAF-regels en virtuele patches, kan ons WP‑Firewall-team helpen. Begin met ons gratis plan op: https://my.wp-firewall.com/buy/wp-firewall-free-plan/ en we helpen u om onmiddellijke bescherming te realiseren.
— WP‑Firewall Beveiligingsteam
Referenties en verder lezen
- CVE‑2026‑1073 advies (openbaar gemaakte kwetsbaarheid)
- WordPress Ontwikkelaarsbronnen: Nonces en Beveiligings-API
- OWASP: Cross-Site Request Forgery Preventie Cheat Sheet
(Als u sites voor klanten beheert, deel deze post met hen — het is een korte set stappen die een echt verschil kan maken.)
