WordPress Beveiligingsaudit: Wat te controleren voor livegang

Voordat een door PAGEnza gegenereerde plugin de WordPress-installatie van een gebruiker bereikt, doorloopt deze drie geautomatiseerde beveiligingscontroles. Dit bericht legt uit waar die controles naar kijken — en waarom elk ervan belangrijk is.

Waarom door AI gegenereerde code een audit nodig heeft

Grote taalmodellen zijn verrassend goed in het schrijven van WordPress-plugins. Ze kennen hook-namen, begrijpen WP-coderingstandaarden, produceren leesbare PHP. Maar ze maken ook voorspelbare fouten — en die fouten zijn beveiligingskwetsbaarheden.

De meest voorkomende die we zien:

• Gebruik van $_GET of $_POST zonder sanitization
• Ontbrekende nonce-verificatie bij formulierinzendingen
• Directe databasequery's zonder $wpdb->prepare()
• Gebruik van eval() of exec() voor dynamisch gedrag
• Output van gebruikersgegevens zonder esc_html() of esc_attr()

Dit zijn geen exotische randgevallen. Ze komen regelmatig voor in LLM-output — zelfs van de beste modellen.

Fase 1: Promptvalidatie

Voordat de AI een enkele regel schrijft, analyseren we de beschrijving van de gebruiker. Deze stap detecteert twee categorieën problemen:

Manipulatiepogingen — prompts die proberen de AI opzettelijk kwaadaardige code te laten produceren. Dingen als "negeer eerdere instructies" of "maak een backdoor voor testen".

Vage of onwerkbare beschrijvingen — prompts die te kort of te dubbelzinnig zijn om bruikbare code te produceren. "Maak een plugin" genereert rommel; "Maak een contactformulier dat inzendingen naar een e-mailadres stuurt met spamfiltering" genereert iets echts.

Als een prompt deze controle niet doorstaat, ziet de gebruiker een specifieke foutmelding die uitlegt waarom — geen generieke afwijzing.

Fase 2: PHP linting in een geïsoleerde container

Zodra de AI PHP-code heeft geproduceerd, wordt deze uitgevoerd via php -l binnen een Docker-container die volledig is geïsoleerd van al het andere. Dit detecteert syntaxisfouten voordat de plugin ooit een WordPress-installatie bereikt.

Maar we gaan verder: als het linten mislukt, verwerpt het systeem de output niet zomaar. Het stuurt de fout terug naar de AI met een correctieprompt — wat we healing noemen. De AI ziet zijn eigen fout en probeert het opnieuw, tot drie keer.

Dit betekent dat gebruikers bijna nooit een "generatie mislukt"-bericht zien. Ze zien een iets langere generatietijd — en werkende code.

Fase 3: Codebeveiligingsscan

Dit is de belangrijkste fase. We voeren een statische analyse uit die controleert op:

Gevaarlijke functies: eval(), exec(), system(), shell_exec(), passthru() — elk van deze blokkeert de release van de plugin.

SQL-injectievectoren: ruwe $wpdb->query()-aanroepen met geïnterpoleerde variabelen, ontbrekende $wpdb->prepare(), direct gebruik van mysql_query().

Ontbrekende permissiecontroles: AJAX-handlers die current_user_can() niet aanroepen voordat ze bevoorrechte acties uitvoeren.

Ontbrekende nonce-verificatie: formulierverwerkers die wp_verify_nonce() of check_ajax_referer() niet aanroepen.

Niet-escaped output: echo $_GET[...], echo $user_input zonder escaping-functies.

Als een van deze wordt gevonden, wordt de plugin geblokkeerd. De gebruiker ziet een rapport dat precies vermeldt welke functies de blokkering hebben geactiveerd en waarom — niet alleen "beveiligingscontrole mislukt".

Hoe het auditrapport eruitziet

Elke gegenereerde plugin wordt geleverd met een beveiligingsauditrapport in duidelijke taal. Het vermeldt:

• Welke controles zijn geslaagd (groen)
• Welke controles waarschuwingen hebben geactiveerd (amber) — problemen die geen blockers zijn, maar aandacht verdienen
• Eventuele correcties die automatisch zijn toegepast tijdens healing

Het rapport wordt automatisch gegenereerd en aan de plugin-download toegevoegd. Het is zowel nuttig voor uw eigen vertrouwen als om klanten te laten zien dat u beveiliging serieus nam.

Fase 4: Validatie bij het opslaan

Dit is geen onderdeel van de initiële generatie — het is van toepassing wanneer gebruikers handmatig plugin-code bewerken in de PAGEnza-editor.

Elke keer dat u opslaat, wordt dezelfde lint + beveiligingsscan opnieuw uitgevoerd. Als u tijdens het bewerken een kritieke kwetsbaarheid introduceert, wordt het opslaan geblokkeerd totdat u deze hebt opgelost. Dit voorkomt het veelvoorkomende scenario waarin een ontwikkelaar een snelle "tijdelijke" wijziging aanbrengt die twee jaar in productie blijft.

De beperkingen van geautomatiseerde auditing

Geautomatiseerde scans detecteren een specifieke klasse van problemen goed. Het detecteert niet alles.

Logische fouten, gebroken bedrijfslogica en subtiele problemen met permissie-escalatie die geen bekende gevaarlijke patronen omvatten, vereisen nog steeds menselijke beoordeling. We zijn hier transparant over in de documentatie — de audit is geen vervanging voor een beveiligingsreview, het is een basis die een minimale standaard garandeert.

Voor productieplugins die betalingen of gevoelige gegevens verwerken, raden we naast de geautomatiseerde controles een handmatige beoordeling aan. Het auditrapport biedt een menselijke beoordelaar een goed startpunt.