WordPress Säkerhetsrevision: Vad du ska kontrollera innan lansering

Innan någon PAGEnza-genererad plugin når en användares WordPress-installation genomgår den tre automatiserade säkerhetskontroller. Det här inlägget förklarar vad dessa kontroller letar efter — och varför var och en är viktig.

Varför AI-genererad kod behöver granskas

Stora språkmodeller är förvånansvärt bra på att skriva WordPress-plugins. De känner till hook-namn, förstår WP:s kodningsstandarder, producerar läsbar PHP. Men de gör också förutsägbara misstag — och dessa misstag är säkerhetsbrister.

De vanligaste vi ser:

• Användning av $_GET eller $_POST utan sanering
• Saknad nonce-verifiering vid formulärinlämningar
• Direkta databasfrågor utan $wpdb->prepare()
• Användning av eval() eller exec() för dynamiskt beteende
• Utdata av användardata utan esc_html() eller esc_attr()

Detta är inga exotiska specialfall. De dyker upp regelbundet i LLM-utdata — även från de bästa modellerna.

Steg 1: Promptvalidering

Innan AI:n skriver en enda rad analyserar vi användarens beskrivning. Detta steg fångar två kategorier av problem:

Manipulationsförsök — prompter som försöker få AI:n att producera avsiktligt skadlig kod. Saker som "ignorera tidigare instruktioner" eller "skapa en bakdörr för testning".

Vaga eller ogenomförbara beskrivningar — prompter som är för korta eller för tvetydiga för att producera användbar kod. "Skapa en plugin" genererar skräp; "Skapa ett kontaktformulär som skickar inlägg till en e-postadress med spamfilter" genererar något verkligt.

Om en prompt misslyckas med denna kontroll ser användaren ett specifikt felmeddelande som förklarar varför — inte ett generiskt avslag.

Steg 2: PHP linting i en isolerad container

När AI:n har producerat PHP-kod körs den via php -l i en Docker-container som är helt isolerad från allt annat. Detta fångar syntaxfel innan pluginen ens når en WordPress-installation.

Men vi går längre: om lintingen misslyckas, avvisar systemet inte bara utdatan. Det skickar felet tillbaka till AI:n med en korrigeringsprompt — det vi kallar healing. AI:n ser sitt eget fel och försöker igen, upp till tre gånger.

Detta innebär att användare nästan aldrig ser ett meddelande om "generering misslyckades". De ser en något längre genereringstid — och fungerande kod.

Steg 3: Kodssäkerhetsskanning

Detta är det viktigaste steget. Vi kör en statisk analys som kontrollerar:

Farliga funktioner: eval(), exec(), system(), shell_exec(), passthru() — var och en av dessa blockerar pluginens utgivning.

SQL-injektionsvektorer: råa $wpdb->query()-anrop med interpolerade variabler, saknad $wpdb->prepare(), direkt användning av mysql_query().

Saknade behörighetskontroller: AJAX-hanterare som inte anropar current_user_can() innan de utför privilegierade åtgärder.

Saknad nonce-verifiering: formulärprocessorer som inte anropar wp_verify_nonce() eller check_ajax_referer().

Oescapad utdata: echo $_GET[...], echo $user_input utan escaping-funktioner.

Om något av detta hittas blockeras pluginen. Användaren ser en rapport som exakt listar vilka funktioner som utlöste blockeringen och varför — inte bara "säkerhetskontroll misslyckades".

Hur revisionsrapporten ser ut

Varje genererad plugin levereras med en säkerhetsrevisionsrapport på vanligt språk. Den listar:

• Vilka kontroller som klarades (grönt)
• Vilka kontroller som utlöste varningar (gul) — problem som inte är blockeringar men förtjänar uppmärksamhet
• Eventuella korrigeringar som automatiskt tillämpades under healing

Rapporten genereras automatiskt och bifogas pluginens nedladdning. Den är användbar både för din egen säkerhet och för att visa kunder att du tog säkerheten på allvar.

Steg 4: Validering vid sparande

Detta är inte en del av den initiala genereringen — det gäller när användare manuellt redigerar plugin-kod i PAGEnza-editorn.

Varje gång du sparar körs samma lint + säkerhetsskanning igen. Om du introducerar en kritisk sårbarhet under redigering blockeras sparandet tills du åtgärdar det. Detta förhindrar det vanliga scenariot där en utvecklare gör en snabb "temporär" ändring som finns kvar i produktion i två år.

Begränsningarna med automatiserad granskning

Automatisk skanning fångar en specifik klass av problem bra. Den fångar inte allt.

Logiska fel, trasig affärslogik och subtila problem med behörighetsexponering som inte involverar kända farliga mönster kräver fortfarande mänsklig granskning. Vi är transparenta om detta i dokumentationen — revisionen är inte en ersättning för en säkerhetsgranskning, det är en grundnivå som garanterar en minimistandard.

För produktionsplugins som hanterar betalningar eller känsliga data rekommenderar vi en manuell granskning utöver de automatiserade kontrollerna. Revisionsrapporten ger en mänsklig granskare en bra utgångspunkt.