Varför WordPress inte tillåts på våra servrar

Bitware Labs driftar på dedikerade servrar, och WordPress tillåts inte på dem. Detta förvånar folk tillräckligt ofta för att det ska vara värt att förklara ordentligt, eftersom resonemanget inte är vad de flesta tror. Det handlar inte om att WordPress är dålig programvara, utan om att en driftpolicy är en säkerhetsgräns, och plugin-modellen placerar den gränsen någonstans där jag inte kan stå för den.

Vad jag faktiskt lovar

När jag driftar något för en kund ger jag ett löfte om en maskin: att den är uppdaterad, att jag vet vad som körs på den och att om den skulle komprometteras kan jag tala om exakt hur och när det hände. Det löftet är bara så starkt som min förmåga att veta vad som exekveras.

En WordPress-installation är inte ett enda program. Det är WordPress plus ett dussin plugins, var och en en oberoende kodbas med sin egen författare, sin egen uppdateringstakt, sin egen säkerhetsnivå och fulla PHP-exekveringsrättigheter inuti samma process. Att installera ett plugin är inte konfiguration, det är att driftsätta en främlings kod i produktion från en administrationspanel, utan någon kodgranskning.

Och framför allt: personen som lägger till pluginet är oftast inte personen som lovade att maskinen var säker. Sajtägaren klickar på installera. Jag bär konsekvenserna. Jag är inte beredd att garantera en säkerhetsgräns som någon annan kan flytta efter behag, direkt från en webbläsare, utan att meddela mig.

Sårbarheten finns sällan i själva WordPress. Den finns i det fjärde pluginet uppifrån, övergivet 2021, som ingen längre minns varför det installerades.

Detta är ingen retorisk överdrift, det är den återkommande verkligheten i all publicerad sårbarhetsdata år efter år. Kärnteamet bakom WordPress är mycket kompetent. Ekosystemet runt omkring består av tiotusentals plugins av extremt varierande kvalitet, och ett plugin som slutar underhållas slutar inte fungera. Det fortsätter fungera helt perfekt, vilket är precis det som är problemet.

Den driftmässiga sidan

Bortse helt från säkerheten så passar det ändå inte in i hur vi driver servrar.

Självuppdaterande kod motarbetar konfigurationshantering. WordPress uppdaterar sig självt och dess plugins uppdaterar sig själva. Filsystemet är föränderligt i drift. Det är ett utmärkt standardval för målgruppen det byggdes för, men inkompatibelt med en servermiljö där jag vill veta att det som körs är exakt det jag har lagt dit. På våra maskiner kan applikationsprocessen inte skriva till sin egen programkod.

Prestandaarbete handlar om att släcka bränder. Den vanliga optimeringsvägen för en WordPress-sajt är att installera ett cache-plugin för att kompensera för databasfrågorna som skapas av andra plugins, och sedan ett tillägg för att kompensera för skripten de injicerar. Lager på lager av programvara vars enda syfte är att motverka kostnaden av tidigare lager. Varje lager innebär mer attackyta, mer att uppdatera och mer som kan gå sönder klockan två på natten.

Felsökning blir arkeologi. När en handbyggd sajt krånglar läser jag koden. När en plugin-tung sajt krånglar handlar den första timmen om att över huvud taget ta reda på vad som körs: vilka krokar som anropas, vilket plugin som filtrerade utdatan och vilket som lade till headern. Den timmen faktureras kunden och tillför inget värde.

Avvägningen

Denna policy kostar oss uppdrag. Många bra kunder vill ha en WordPress-sajt, och vi hänvisar dem gladeligen vidare. Det finns driftleverantörer som specialiserar sig på att göra det ordentligt med isolering, skanning och uppdateringsdisciplin, och det är ett verkligt hantverk. Det är helt enkelt inte den tjänst vi erbjuder.

Vad restriktionen ger för de sajter vi faktiskt driftar:

• Allt är kod vi kan läsa. Node, PHP, statiskt, vad som än passar jobbet bäst, men skrivet eller noggrant granskat av oss. När något strular börjar felsökningen vid det verkliga felet istället för vid "vad är installerat".
• Webbprocessen kan inte skriva över sin egen kod. En hel kategori av skadlig persistens efter intrång elimineras.
• Sajterna är blixtsnabba utan tunga cache-lager. Sidan du läser just nu är en PHP-fil, en stilmall och ett skript. Det finns inget att cacha eftersom det inte finns något som är långsamt.
• Uppdateringsytan är liten nog att överblicka. Att underhålla en känd uppsättning komponenter är en uppgift. Att underhålla ett helt ekosystem är ett hopp.

Den generella principen

Detta handlar egentligen inte om WordPress. Det handlar om vem som har rätt att ändra vad som körs på en maskin, och om personen som bär risken är samma person som gör ändringen.

Alla system där driftsättning av tredjepartskod är ett tvåklicksförfarande för någon som inte ansvarar för servern har samma problematik. WordPress är helt enkelt det vanligaste exemplet.

Om ni vill ha en sajt på våra maskiner så byggs den för ändamålet. Det tar lite längre tid i starten men är betydligt tryggare och billigare att förvalta i längden, och jag kan vid varje tidpunkt på dygnet berätta exakt vad som körs på servern.