Sikkerhed på et offentligt site: det I faktisk skal have styr på

Et offentligt site er interessant for angribere, fordi det er let. Ikke fordi I er interessante. Automatiske scans kigger efter kendte plugin-huller, standard-admin-stier, åbne .git-mapper og nøgler, nogen commitede for to år siden. De behøver ikke kende jer. De behøver et site, der stadig kører det, alle andre har patchet.

Når det går galt på et marketing-site, er det sjældent en filmagtig indbrudsscene. Det er en spam-side i jeres CMS, en redirect til en shop I ikke ejer, eller et skript i et tema-header, der stjæler formularer. SEO dør bagefter — Google er hurtig til at mærke et kompromitteret site, og langsom til at glemme det. Det er også derfor sikkerhed og SEO hænger sammen her, uden at de er det samme.

Teams overreagerer eller underreagerer. Over: et WAF-abonnement, tre plugins og en følelse af at emnet er taget af bordet. Under: "vi er jo bare en brochure." Brochuren har et login, et kontaktformular-endpoint og ofte et preview, der viser næste kampagne. Det er nok. I behøver ikke være en bank for at have en dør, nogen vil prøve.

Det her er ikke en pentest-rapport og ikke et løfte om at I er "sikre". Det er den ingeniørsamtale, I skal have, før I køber det næste plugin: hvad kan en fremmed gøre ved det her site på en eftermiddag, og hvad har I sat i vejen?

I skal ikke starte med nation-state. I skal starte med det, der sker for sites som jeres. Én: kendte sårbarheder i CMS, tema og plugins — især WordPress, især ting I ikke længere bruger, men ikke har slået fra. To: credential stuffing mod /wp-admin, /login, /studio eller det CMS, I glemte at sætte 2FA på. Tre: hemmeligheder i git, i et screenshot, i en Vercel-log, i en gammel .env på en medarbejderlaptop.

Fire: åbne previews og staging med rigtige data og svag auth. Fem: et kontaktformular-endpoint uden rate-limit, der bliver til en spam-kanon eller et sted at prøve injection. Seks: et åbent redirect eller et gammelt subdomain, der peger på en bucket, I ikke længere ejer. Det er listen. Den er kedelig. Den er også den, der tager sites.

Det I typisk ikke skal starte med: at skrive en 40-siders policy, at købe et overlay der lover "malware scan", eller at bede om en fuld pentest af en brochure, før I har slået ubrugte plugins fra. Pentest er rigtigt, når I har noget at teste — et login, et checkout, et API. Først: luk de døre, I selv kan se.

GDPR-samtalen er en anden. Den handler om hvad I sender, og om brugeren sagde ja. Den her handler om hvad en fremmed kan gøre, uanset samtykke. Et site kan have et pænt cookie-banner og stadig et åbent admin. De to tjeklister skal ikke blandes. De skal begge gøres.

HTTPS er gulvet. HSTS fortæller browseren, at den ikke må gå tilbage til HTTP. Uden HSTS kan et netværk, I ikke styrer, stadig prøve at nedgradere det første hop. Sæt det, når I er sikre på, at I ikke har et ældre HTTP-kun-endpoint, I er afhængige af. Det er et ét-linjes header-valg, ikke et projekt.

Content-Security-Policy er det, der begrænser, hvilke scripts og embeds siden må loade. En ærlig CSP er stram og går i stykker, når nogen smider et nyt pixel ind. Det er meningen. En CSP med 'unsafe-inline' og et dusin wildcard-domains er et badge. Start med default-src 'self', tillad det I faktisk bruger, og brug Report-Only en uge, før I håndhæver. Hvis I ikke kan liste jeres script-domains, har I et andet problem — det samme inventar, GDPR-posten beder om.

Referrer-Policy, X-Content-Type-Options, Permissions-Policy og en frame-ancestors der ikke tillader, at I bliver iframet på et fremmed site, er de næste. Ingen af dem gør jer interessante på en konference. Alle sammen fjerner en hel klasse af "nogen indlejrede os og stjal et klik". På Next.js sætter I dem i next.config eller i jeres edge. På Cloudflare kan I sætte dem dér. På WordPress skal temaet eller serveren gøre det — et plugin der lover "alle headers" er fint, hvis I tjekker, at de faktisk sendes.

TLS-certifikatet skal fornyes af sig selv. Hvis et menneske skal huske det, vil det udløbe en lørdag. Let's Encrypt via jeres host, eller den cert-styring jeres edge allerede har, er det rigtige svar. Et screenshot af et hængelås-ikon i et slide er det forkerte.

På WordPress er den typiske brudflade plugin- og tema-overfladen. I har et økosystem, der er nemt at udvide og nemt at glemme. Sikkerhed her er hygiejne: færre plugins, automatiske opdateringer I faktisk overvåger, et tema I kan forklare, og et admin der ikke er åbent for hele internettets credential-lists. Et "security plugin" kan hjælpe med at skjule /wp-admin og blokere nogle paths. Det kan ikke redde et tema, der ikke længere får patches.

På Next.js og et hosted CMS er den typiske brudflade hemmeligheder og preview. En NEXT_PUBLIC_-variabel der ikke skulle have været public. En preview-URL uden auth. En server action der stoler på det, browseren sender. Deploy-nøgler i et GitHub-action-log. I har færre plugins og flere steder, hvor I selv er platformen. Det er ikke sikrere af sig selv. Det er sikrere, hvis I behandler env og preview som produktion.

Begge stakke skylder jer det samme udadtil: HTTPS, headers, et formular-endpoint der ikke er en åben slange, og et admin I kan forsvare. Begge kan sidde bag Cloudflare og få WAF og bot-værn. WAF'en er et net. Den er nyttig. Den er ikke en undskyldning for at køre et CMS, I ikke opdaterer, eller en preview, I deler i Slack uden login.

Hvis I overvejer at skifte fra WordPress til Next.js af sikkerhedsgrunde alene, så vær ærlige: I skifter sted, de kedelige fejl kan sidde. I fjerner plugin-overfladen. I får env- og pipeline-overfladen. Skift hvis I også har andre grunde — redaktion, performance, SEO-kontrol. Skift ikke fordi et slide sagde, at Jamstack er sikkert. Statiske filer er svære at inficere. Jeres build og jeres CMS er det ikke.