<ForrigeUke uke="20" år="2026" />
Mens vi lada opp til 17. mai, var frontendverdenen preget av sikkerhetspatching, kompromitterte npm-pakker og supply chain-drama. Vi ser på hva som skjedde - og hva vi kan lære av det - i ukas ForrigeUke.
Dette var uka for mimring og halting - og 3713 andre ting i frontendverdenen!
«<ForrigeUke /> er en artikkelserie som oppsummerer hva som skjedde i frontend-verden i uka som var.»
Sikkerhetspatching i Next.js
For å ta Next.js først: Next.js slapp en stor koordinert sikkerhetsoppdatering med fikser for blant annet denial of service, cache poisoning og XSS. Om du er på versjon 16.2.6 skal du være trygg. Om du er på andre major-versjoner kan du se i bloggposten for hvilken versjon du bør være på:
Next.js May 2026 security release - Vercel
Next.js 15.5.18 and 16.2.6 patch 13 security advisories covering middleware bypass, denial of service, SSRF, cache poisoning, and cross-site ...
Nytt supply-chain-angrep i TanStack Router
Det har ikke vært enkelt å ha pakker som er åpne for eksterne bidrag, og denne gang ble TanStack Router truffet:
Hardening TanStack After the npm Compromise | TanStack Blog
A companion to our incident postmortem: what we're changing across the org so the May 11 supply-chain attack can't happen the same way again.
Angrepet var ganske sneaky. En angriper opprettet først en pull request i en fork av prosjektet. Derfra klarte angriperen å forgifte en delt GitHub Actions-cache med ondsinnet kode. Når en legitim workflow senere kjørte i main og brukte samme cache, kunne angriperen hente ut publiseringstokens og publisere kompromitterte versjoner av TanStack Router-pakker.
Teamet har allerede gjort tiltak, som å bruke en installerings-cooldown - altså å vente litt før nye pakkeversjoner automatisk installeres, slik at mistenkelige publiseringer rekker å bli oppdaget. De jobber også med andre tiltak, som å ikke skrive til cachen med mindre innstillingen er eksplisitt satt.
Hvordan ha åpne bidrag og hindre ondsinnede aktører?
Supply chain-angrep setter også open source-miljøet i en vanskelig situasjon: Hvordan tilrettelegge for bidrag, men samtidig beskytte både konsumere og bidragsytere?
TanStack-teamet ønsker ikke å gå closed source, men de vurderer å gå fra "åpent for PR-er fra alle" til "issues og diskusjoner er åpne for alle, men PR-er kommer først ved invitasjon".
Det er ikke en selvfølge at biblioteker holder seg åpne for bidrag. Etter angrepet valgte nuqs-bibliotek-forfatter Francois Best å lukke for eksterne bidrag, for å beskytte brukerne sine. Han savner flere tiltak fra økosystemet; fra Microsoft, GitHub og npm.
Hvilke tiltak kan vi gjøre?
I incident-followupen lister TanStack-teamet en rekke tiltak de har gjort og har under arbeid. Flere av tiltakene retter seg mot bibliotek-forfattere og CI/CD-oppsett.
For en vanlig utvikler som konsumerer pakkene finnes det også flere tiltak du kan gjøre selv. Et eksempel er å bruke pnpm, som isolerer avhengigheter strengere. Et annet tiltak er å bruke cooldown før installering, som nevnt over.
GitHub - lirantal/npm-security-best-practices: Collection of npm package manager Security Best Practices
Collection of npm package manager Security Best Practices - lirantal/npm-security-best-practices
Når det kommer til generell sikkerhet i frontend har Aurora Scharff nylig skrevet en post om vanlige feil og tiltak for sikkerhet i React-applikasjoner. Nå som vi bruker rammeverk som også er server-baserte, er det flere sårbarheter vi må ta hensyn til:
Security in React Applications
Learn how to secure React apps: prevent XSS with DOMPurify, store tokens safely in HttpOnly cookies, validate server inputs with Zod, and ...
Det var alt for denne gang. Ha en trygg uke! 👋
