WordPress Sikkerhetsrevisjon: Hva du skal sjekke før lansering

Før et PAGEnza-generert plugin når en brukers WordPress-installasjon, går det gjennom tre automatiserte sikkerhetssjekker. Dette innlegget forklarer hva disse sjekkene ser etter — og hvorfor hver enkelt er viktig.

Hvorfor AI-generert kode trenger revisjon

Store språkmodeller er overraskende gode til å skrive WordPress-plugins. De kjenner hook-navn, forstår WP's kodestandarder, produserer lesbar PHP. Men de gjør også forutsigbare feil — og disse feilene er sikkerhetssårbarheter.

De vanligste vi ser:

• Bruk av $_GET eller $_POST uten sanering
• Manglende nonce-verifisering ved innsending av skjemaer
• Direkte databaseforespørsler uten $wpdb->prepare()
• Bruk av eval() eller exec() for dynamisk atferd
• Utdata av brukerdata uten esc_html() eller esc_attr()

Dette er ikke eksotiske spesialtilfeller. De dukker opp jevnlig i LLM-utdata — selv fra de beste modellene.

Trinn 1: Promptvalidering

Før AI-en skriver en eneste linje, analyserer vi brukerens beskrivelse. Dette trinnet fanger opp to kategorier av problemer:

Manipulasjonsforsøk — prompter som prøver å få AI-en til å produsere bevisst skadelig kode. Ting som "ignorer tidligere instruksjoner" eller "opprett en bakdør for testing".

Vage eller urealistiske beskrivelser — prompter som er for korte eller for tvetydige til å produsere nyttig kode. "Lag en plugin" genererer søppel; "Opprett et kontaktskjema som sender innsendinger til en e-postadresse med spamfiltrering" genererer noe reelt.

Hvis en prompt feiler denne sjekken, ser brukeren en spesifikk feilmelding som forklarer hvorfor — ikke et generisk avslag.

Trinn 2: PHP linting i en isolert container

Når AI-en har produsert PHP-kode, kjøres den via php -l i en Docker-container som er fullstendig isolert fra alt annet. Dette fanger opp syntaksfeil før pluginet i det hele tatt når en WordPress-installasjon.

Men vi går lenger: hvis lintingen feiler, avviser systemet ikke bare utdataene. Det sender feilen tilbake til AI-en med en korrigeringsprompt — det vi kaller healing. AI-en ser sin egen feil og prøver igjen, opptil tre ganger.

Dette betyr at brukere nesten aldri ser en "generering mislyktes"-melding. De ser en litt lengre genereringstid — og fungerende kode.

Trinn 3: Kodsikkerhetsskanning

Dette er det viktigste trinnet. Vi kjører en statisk analyse som sjekker for:

Farlige funksjoner: eval(), exec(), system(), shell_exec(), passthru() — enhver av disse blokkerer utgivelsen av pluginet.

SQL-injeksjonsvektorer: rå $wpdb->query()-kall med interpolerte variabler, manglende $wpdb->prepare(), direkte bruk av mysql_query().

Manglende tillatelsessjekker: AJAX-handlere som ikke kaller current_user_can() før de utfører privilegerte handlinger.

Manglende nonce-verifisering: skjema-prosessorer som ikke kaller wp_verify_nonce() eller check_ajax_referer().

Uescaped output: echo $_GET[...], echo $user_input uten escaping-funksjoner.

Hvis noen av disse blir funnet, blir pluginet blokkert. Brukeren ser en rapport som nøyaktig lister hvilke funksjoner som utløste blokeringen og hvorfor — ikke bare "sikkerhetssjekk mislyktes".

Hvordan revisjonsrapporten ser ut

Hvert generert plugin leveres med en sikkerhetsrevisjonsrapport på enkelt språk. Den lister opp:

• Hvilke sjekker som besto (grønn)
• Hvilke sjekker som utløste advarsler (gul) — problemer som ikke er blokkerende, men som fortjener oppmerksomhet
• Eventuelle korrigeringer som ble automatisk brukt under healing

Rapporten genereres automatisk og legges ved plugin-nedlastingen. Den er nyttig både for din egen trygghet og for å vise kunder at du tok sikkerhet på alvor.

Trinn 4: Validering ved lagring

Dette er ikke en del av den innledende genereringen — det gjelder når brukere manuelt redigerer plugin-kode i PAGEnza-editoren.

Hver gang du lagrer, kjøres den samme lint + sikkerhetsskanningen igjen. Hvis du introduserer en kritisk sårbarhet under redigering, blir lagringen blokkert til du har fikset den. Dette forhindrer det vanlige scenarioet der en utvikler gjør en rask "midlertidig" endring som forblir i produksjon i to år.

Begrensningene ved automatisert revisjon

Automatisk skanning fanger en spesifikk klasse av problemer godt. Den fanger ikke alt.

Logiske feil, ødelagt forretningslogikk og subtile problemer med tillatelseseskalering som ikke involverer kjente farlige mønstre, krever fortsatt menneskelig gjennomgang. Vi er transparente om dette i dokumentasjonen — revisjonen er ikke en erstatning for en sikkerhetsgjennomgang, det er et gulv som garanterer en minimumsstandard.

For produksjonsplugins som håndterer betalinger eller sensitive data, anbefaler vi en manuell gjennomgang i tillegg til de automatiserte sjekkene. Revisjonsrapporten gir en menneskelig anmelder et godt utgangspunkt.