CSRF: SameSite-cookies og tokens
Forstå hvordan Cross-Site Request Forgery utnytter cookies, bruk SameSite=Strict/Lax for å hindre det, og legg til synkroniseringstokener for ekstra beskyttelse.
CSRF: SameSite-cookies og tokens er en gratis leksjon i Frontend Academy på CoddyKit. Dette er leksjon 2 av 4. Du kan lese hele leksjonen gratis nedenfor – og deretter øve praktisk i nettleseren med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Frontend Academy, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Frontend Academy inneholder totalt 4 leksjoner.
Hva er CSRF?
Cross-Site Request Forgery: En angriper lurer nettleseren til en autentisert bruker til å sende en forespørsel til nettstedet Deres. Nettleseren legger automatisk ved brukerens informasjonskapsler – serveren tror derfor at forespørselen er legitim og kommer fra brukeren.
Et klassisk CSRF-angrep
Brukeren er logget inn på bank.com. Brukeren besøker evil.com. evil.com sender inn et skjult skjema til bank.com/transfer med angriperens kontonummer. Nettleseren sender automatisk øktinformasjonskapselen for bank.com. Serveren overfører pengene.
Tillitproblemet
CSRF fungerer fordi nettlesere automatisk inkluderer informasjonskapsler i forespørsler på tvers av opphav. Serveren kan ikke se at forespørselen kom fra et ondsinnet nettsted uten ekstra beskyttelse.
SameSite-informasjonskapsler – den moderne løsningen
SameSite-attributtet for informasjonskapsler styrer når informasjonskapsler sendes i forespørsler på tvers av opphav. Strict: sendes aldri på tvers av opphav. Lax (standard i Chrome): sendes bare ved navigering på øverste nivå med GET. None: sendes alltid (må også være Secure).
Set-Cookie: session=abc; HttpOnly; Secure; SameSite=LaxSameSite=Lax som standard
Chrome setter alle informasjonskapsler til Lax som standard hvis SameSite ikke er angitt. Dette blokkerer de fleste CSRF-angrep – men De bør angi verdien eksplisitt uansett.
SameSite=Strict for maksimal sikkerhet
Bruk Strict for de mest sensitive informasjonskapslene (administratørøkter og banktransaksjoner). Ulempen er at brukeren ser ut til å være logget ut når vedkommende kommer via en lenke fra et annet nettsted.
CSRF-tokener (synkroniseringsmønsteret)
For støtte for eldre nettlesere eller ekstra sikkerhet bør De bruke CSRF-tokener. Serveren genererer et tilfeldig token, bygger det inn i siden og krever det i alle forespørsler som endrer tilstand.
// Server embeds token in HTML or sets it as a non-HttpOnly cookie:
<meta name="csrf-token" content="a1b2c3...">
// Client reads token and sends in header:
const token = document.querySelector('meta[name=csrf-token]').content;
fetch('/transfer', {
method: 'POST',
headers: { 'X-CSRF-Token': token },
body: JSON.stringify({ amount: 100 })
});
// Server verifies the X-CSRF-Token header matches the user's sessionDouble-Submit Cookie
Serveren setter en CSRF-informasjonskapsel (ikke HttpOnly, slik at JavaScript kan lese den). Klienten leser den og sender verdien i en header. Serveren kontrollerer at informasjonskapselen samsvarer med headeren. En angriper kan ikke lese informasjonskapselen på tvers av opphav og kan derfor ikke gjenskape headeren.
Hvorfor det fungerer
Angriperens evil.com kan ikke lese informasjonskapsler fra bank.com (Same-Origin Policy). Derfor kan angriperen ikke angi X-CSRF-Token-headeren. Forespørselen mislykkes i tokenkontrollen på serveren.
CSRF i SPA-er med bearer-tokener
Hvis De autentiserer med Authorization: Bearer <jwt> lagret i minnet (ikke i en informasjonskapsel), gjelder ikke CSRF – nettlesere sender ikke headere automatisk. Avveiningen er at løsningen er mer sårbar for XSS, siden JavaScript-tilgjengelige tokener kan stjeles.
Trikset med en egendefinert header
For API-er som bare godtar JSON med en egendefinert header (for eksempel X-Requested-With) sender nettlesere en forhåndsforespørsel med OPTIONS – og inkluderer ikke informasjonskapsler i forhåndsforespørselen. Dette blokkerer i praksis enkel skjemabasert CSRF.
Idempotente kontra muterende endepunkter
CSRF rammer hovedsakelig forespørsler som endrer tilstand (POST, PUT, DELETE). GET-endepunkter bør være idempotente – de skal ikke ha bivirkninger – slik at en forfalsket GET ikke kan gjøre skade.
Hurtigsjekk
Hvilken SameSite-verdi for informasjonskapsler hindrer som standard at informasjonskapsler sendes i de fleste forespørsler på tvers av nettsteder i moderne nettlesere?
Oppsummering: Forebygging av CSRF
Angi SameSite=Lax (eller Strict) for øktinformasjonskapsler – dette blokkerer de fleste CSRF-angrep. Legg til HttpOnly + Secure. Bruk CSRF-tokener (synkroniseringsmønster eller Double-Submit Cookie) for ekstra beskyttelse. Bearer-tokener i headere unngår CSRF, men øker XSS-risikoen. Trikset med en egendefinert header tvinger frem en forhåndsforespørsel. Gjør GET-forespørsler idempotente.
Lær deg HTML med en AI-veileder – gratis
Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.
- Kurs
- 41
- Leksjoner
- 163
Ofte stilte spørsmål
Er leksjonen «CSRF: SameSite-cookies og tokens» gratis?
Ja – hele teksten i «CSRF: SameSite-cookies og tokens» er gratis å lese her på nettet. For å øve interaktivt med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt, og for å låse opp resten av Frontend Academy-kurset, kan du oppgradere til CoddyKit PRO. Kurset i Frontend Academy inneholder totalt 4 leksjoner.
Hva lærer jeg i «CSRF: SameSite-cookies og tokens»?
Forstå hvordan Cross-Site Request Forgery utnytter cookies, bruk SameSite=Strict/Lax for å hindre det, og legg til synkroniseringstokener for ekstra beskyttelse. Du øver på Frontend Academy med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.
Trenger jeg erfaring for å begynne med Frontend Academy?
Ingen tidligere erfaring er nødvendig. Frontend Academy på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 2 av 4.
Hvor lang tid tar leksjonen «CSRF: SameSite-cookies og tokens»?
De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.
Kan jeg skrive og kjøre kode i denne Frontend Academy-leksjonen?
Ja. Alle Frontend Academy-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.
Alle leksjonene i dette kurset
- XSS-forebygging: output-koding og CSP
- CSRF: SameSite-cookies og tokens
- Content Security Policy: nonce og hash
- OAuth-flyter fra frontend