WordPress Sikkerhedsrevision: Hvad du skal tjekke før livegang

Før et PAGEnza-genereret plugin når en brugers WordPress-installation, gennemgår det tre automatiserede sikkerhedstjek. Dette indlæg forklarer, hvad disse tjek leder efter — og hvorfor hvert enkelt er vigtigt.

Hvorfor AI-genereret kode kræver revision

Store sprogmodeller er overraskende gode til at skrive WordPress-plugins. De kender hook-navne, forstår WP's kodningsstandarder, producerer læsbar PHP. Men de begår også forudsigelige fejl — og disse fejl er sikkerhedssårbarheder.

De mest almindelige, vi ser:

• Brug af $_GET eller $_POST uden sanering
• Manglende nonce-verifikation ved formularindsendelser
• Direkte databaseforespørgsler uden $wpdb->prepare()
• Brug af eval() eller exec() til dynamisk adfærd
• Output af brugerdata uden esc_html() eller esc_attr()

Dette er ikke eksotiske specialtilfælde. De dukker regelmæssigt op i LLM-output — selv fra de bedste modeller.

Trin 1: Promptvalidering

Før AI'en skriver en eneste linje, analyserer vi brugerens beskrivelse. Dette trin fanger to kategorier af problemer:

Manipulationsforsøg — prompter, der forsøger at få AI'en til at producere bevidst skadelig kode. Ting som "ignorer tidligere instruktioner" eller "opret en bagdør til testning".

Vage eller urealistiske beskrivelser — prompter, der er for korte eller for tvetydige til at producere brugbar kode. "Lav et plugin" genererer skrald; "Opret en kontaktformular, der sender indsendelser til en e-mailadresse med spamfiltrering" genererer noget reelt.

Hvis en prompt fejler dette tjek, ser brugeren en specifik fejlmeddelelse, der forklarer hvorfor — ikke en generisk afvisning.

Trin 2: PHP linting i en isoleret container

Når AI'en har produceret PHP-kode, udføres den via php -l i en Docker-container, der er fuldstændig isoleret fra alt andet. Dette fanger syntaksfejl, før pluginet overhovedet når en WordPress-installation.

Men vi går videre: hvis lintingen fejler, afviser systemet ikke bare outputtet. Det sender fejlen tilbage til AI'en med en korrigeringsprompt — det, vi kalder healing. AI'en ser sin egen fejl og prøver igen, op til tre gange.

Dette betyder, at brugere næsten aldrig ser en "generering mislykkedes"-besked. De ser en lidt længere genereringstid — og fungerende kode.

Trin 3: Kodsikkerhedsscanning

Dette er det vigtigste trin. Vi kører en statisk analyse, der tjekker for:

Farlige funktioner: eval(), exec(), system(), shell_exec(), passthru() — enhver af disse blokerer frigivelsen af pluginet.

SQL-injektionsvektorer: rå $wpdb->query()-kald med interpolerede variabler, manglende $wpdb->prepare(), direkte brug af mysql_query().

Manglende tilladelseskontroller: AJAX-handlere, der ikke kalder current_user_can() før de udfører privilegerede handlinger.

Manglende nonce-verifikation: formularprocessorer, der ikke kalder wp_verify_nonce() eller check_ajax_referer().

Uescaped output: echo $_GET[...], echo $user_input uden escaping-funktioner.

Hvis nogen af disse findes, blokeres pluginet. Brugeren ser en rapport, der præcist angiver, hvilke funktioner der udløste blokeringen og hvorfor — ikke bare "sikkerhedstjek mislykkedes".

Hvordan revisionsrapporten ser ud

Hvert genereret plugin leveres med en sikkerhedsrevisionsrapport på almindeligt sprog. Den angiver:

• Hvilke tjek der bestod (grøn)
• Hvilke tjek der udløste advarsler (gul) — problemer, der ikke er blokeringer, men som fortjener opmærksomhed
• Eventuelle rettelser, der blev automatisk anvendt under healing

Rapporten genereres automatisk og vedhæftes plugin-downloaden. Den er nyttig både for din egen tryghed og for at vise kunder, at du tog sikkerhed alvorligt.

Trin 4: Validering ved lagring

Dette er ikke en del af den indledende generering — det gælder, når brugere manuelt redigerer plugin-kode i PAGEnza-editoren.

Hver gang du gemmer, køres den samme lint + sikkerhedsscanning igen. Hvis du introducerer en kritisk sårbarhed under redigering, blokeres lagringen, indtil du har rettet den. Dette forhindrer det almindelige scenarie, hvor en udvikler foretager en hurtig "midlertidig" ændring, der forbliver i produktion i to år.

Begrænsningerne ved automatiseret revision

Automatisk scanning fanger en specifik klasse af problemer godt. Den fanger ikke alt.

Logiske fejl, brudt forretningslogik og subtile problemer med tilladelsesk eskalering, der ikke involverer kendte farlige mønstre, kræver stadig menneskelig gennemgang. Vi er gennemsigtige omkring dette i dokumentationen — revisionen er ikke en erstatning for en sikkerhedsanmeldelse, det er et minimum, der garanterer en minimumsstandard.

For produktionsplugins, der håndterer betalinger eller følsomme data, anbefaler vi en manuel gennemgang ud over de automatiserede tjek. Revisionsrapporten giver en menneskelig anmelder et godt udgangspunkt.