Webbutveckling 1 · område 5 · guide

Säkerhet på webben

Kursplanen kräver två saker av dig i det här ämnet: att du kan "identifiera hot och sårbarheter samt hur attacker kan motverkas", och att du "hanterar lösenord och annan känslig data på ett etiskt riktigt sätt". Guiden är byggd efter det. Första halvan handlar om dig som användare – det är där nästan alla angrepp börjar. Andra halvan handlar om dig som bygger en sajt.

Myndigheterna på området har bytt namn under 2026, och det är viktigt att få rätt i Projekt 4:

• MSB finns inte längre. Sedan 1 januari 2026 heter myndigheten Myndigheten för civilt försvar, MCF. Adressen msb.se skickar vidare till mcf.se.
• CERT-SE, Sveriges nationella funktion för it-incidenter, flyttade 1 juli 2026 från MCF till FRA, Försvarets radioanstalt, och ingår nu i Nationellt cybersäkerhetscenter, NCSC.
• Råden till privatpersoner ligger på krisinformation.se, som MCF står bakom.

Källhänvisningarna är hämtade 11 september 2026.

Vad du kan efter guiden

• Räkna upp de fem vanligaste hoten mot en vanlig användare, och känna igen dem.
• Förklara varför ett långt lösenord slår ett krångligt, och varför varje tjänst ska ha sitt eget.
• Säga vad flerfaktorsautentisering skyddar mot – och vad den inte skyddar mot.
• Läsa ett misstänkt meddelande och peka på det som avslöjar det.
• Förklara vad hänglåset i adressfältet betyder, och vad det inte betyder.
• Publicera en sajt som inte läcker: HTTPS, inga hemligheter i repot, koll på tredjepartsskript.
• Veta vart du vänder dig när något hänt.

1. Hoten: fem sätt att bli av med sitt konto

Ordet hot låter som något som riktas mot storföretag. De flesta angrepp riktas mot vanliga människor, i stor skala, med automatik. De fem du kommer att möta:

Nätfiske är det största, och CERT-SE beskriver det som "social manipulation för att stjäla känslig information". Nästan alla stora intrång de senaste åren har börjat med att en enda person klickat på en enda länk.

Gemensamt för alla fem: de riktar sig mot människan, inte mot tekniken. Det är därför avsnitt 2–5 handlar om vanor, inte om programvara.

Prova själv

Sök på din egen e-postadress på en tjänst som visar kända läckor – Have I Been Pwned är den mest använda, och den drivs av en säkerhetsforskare, inte av en myndighet. Finns din adress med i en läcka har det lösenord du hade där varit ute sedan dess. Använde du samma lösenord någon annanstans?

2. Lösenord

Krisinformation.se sammanfattar MCF:s råd i två meningar: "Använd långa lösenord" och "Använd olika lösenord för olika tjänster." Allt annat är detaljer.

Långt slår krångligt

Ett lösenord knäcks genom att ett program provar. Det som avgör hur lång tid det tar är antalet möjliga kombinationer, och det växer mycket snabbare med längden än med konstigheterna. Tr0mb0n! är åtta tecken och knäcks på timmar. blå traktor äter frukost är tjugofyra tecken och tar längre tid än universum funnits.

Rådet blir: en lösenordsfras, fyra eller fler ord som du kan komma ihåg men som ingen kan gissa. Inte ett citat, inte en låttitel, inte något som står på din Instagram.

Ett per tjänst

Läckta lösenord (avsnitt 1) fungerar bara för att folk återanvänder. Har varje tjänst sitt eget lösenord är en läcka hos en tjänst en läcka hos en tjänst – inte hos alla.

Lösenordshanteraren gör det möjligt

Ingen kan minnas femtio olika långa fraser. Det är inte meningen. En lösenordshanterare är ett program som skapar, sparar och fyller i lösenorden åt dig, bakom ett enda huvudlösenord som du kan. Krisinformation.se rekommenderar det rakt ut. Webbläsarens inbyggda hanterare duger för de flesta; en fristående (Bitwarden, 1Password, KeePass) är bättre om du byter mellan enheter och webbläsare.

Det enda lösenordet du behöver kunna utantill är då huvudlösenordet – och det ska vara en lång fras.

Prova själv

Öppna lösenordshanteraren i din webbläsare. De flesta har en funktion som visar återanvända och läckta lösenord. Byt de som markeras – börja med e-posten, eftersom den som har din e-post kan återställa allt annat.

3. Flerfaktorsautentisering

Flerfaktorsautentisering, MFA, betyder att inloggningen kräver mer än en sak: något du vet (lösenordet) plus något du har (telefonen, en säkerhetsnyckel) eller något du är (fingeravtryck, ansikte). Kallas också tvåstegsverifiering eller 2FA.

Poängen: ett läckt lösenord räcker inte längre. Angriparen som köpt ditt lösenord i en lista har inte din telefon. Krisinformation.se, CERT-SE och MCF säger alla samma sak – slå på det överallt där det går.

Tre sorter, olika starka

CERT-SE kallar den sista sorten "phishing resistant MFA" och rekommenderar den för allt känsligt. Erbjuder tjänsten passkeys – GitHub, Google, Apple och Microsoft gör det – välj det.

Vad MFA inte skyddar mot

Att du själv godkänner något. Om du får en push-notis "Godkänn inloggning?" när du inte försöker logga in, är svaret nej. Angriparen har ditt lösenord och hoppas att du trycker ja av vana. Det kallas MFA-trötthet och fungerar oroväckande ofta.

Prova själv

Slå på flerfaktorsautentisering på ditt GitHub-konto, om du inte redan gjort det. GitHub kräver det för de flesta konton sedan 2023. Välj passkey om din telefon stöder det.

4. Känn igen nätfisket

Nätfiske går att känna igen. Det tar tio sekunder, och de tio sekunderna är hela skyddet.

Sex tecken

1. Avsändaradressen, inte namnet. CERT-SE: "titta på avsändaradressen och inte bara namnet i misstänkt e-post". Namnet kan vara "Skatteverket". Adressen är noreply@skatteverket-info.xyz.
2. Brådska. "Ditt konto stängs inom 24 timmar." "Paketet returneras i dag." Riktiga tjänster ger dig tid.
3. En länk du ska klicka på för att logga in. Håll muspekaren över länken utan att klicka – adressen visas längst ner i webbläsaren. Är den inte den du väntade dig, stäng meddelandet.
4. Betalning eller kod. "Betala 19 kr i tull." "Ange koden vi skickade." Små belopp gör att du inte tänker efter.
5. Bilagor och QR-koder. En QR-kod är en länk du inte kan läsa. CERT-SE varnar särskilt för dem.
6. Något stämmer inte. Fel språk, konstiga tecken, en tjänst du inte har konto på. Krisinformation.se: "Kontrollera meddelandet noga – ser det ut som det ska?"

Det enda säkra sättet att logga in

Gå själv till tjänsten – skriv adressen, använd bokmärket eller appen. Aldrig via en länk i ett meddelande som säger att du måste. Är det något riktigt ser du det när du loggat in.

Realistiskt exempel

Ett sms: "Hej! Ditt paket kunde inte levereras. Betala 25 kr i avgift för ny leverans: [länk]". Avsändaren är ett vanligt mobilnummer. Länken går till en adress med ett postföretags namn i, men med .top i slutet. Sidan ser exakt ut som postföretagets, och ber om kortuppgifter. Kortet töms samma kväll.

Tecken 2, 3, 4 och 1 – alla fyra på tre rader.

Prova själv

Gå igenom skräppostmappen i din e-post. Ta tre meddelanden och pricka av mot de sex tecknen. Vilka tecken hittade du i varje? Det är en övning som passar som konkret exempel i Projekt 4, med skärmbild där du strukit över allt personligt.

5. Uppdateringar och säkerhetskopior

Två vanor som skyddar mot skadlig kod, och som inte kräver att du känner igen något.

Uppdatera

Skadlig kod tar sig in genom sårbarheter – fel i program som någon hittat och lärt sig utnyttja. När felet blir känt släpper tillverkaren en rättelse, och från det ögonblicket är alla som inte uppdaterat lätta mål: angriparna vet exakt vilket fel de ska leta efter. MCF:s råd: håll "datorer, mobiler och wifi-routrar uppdaterade". Slå på automatiska uppdateringar på allt. Routern glöms oftast.

Säkerhetskopiera

Ransomware krypterar dina filer och kräver pengar för nyckeln. Skyddet är att inte behöva nyckeln: en kopia som angriparen inte når. Krisinformation.se: "Säkerhetskopiera ofta – då minskar du risken att din säkerhetskopia smittas av virus." MCF lägger till att kopian ska hållas "frånkopplad från datorn och internet".

Din kod på GitHub är en säkerhetskopia. Dina bilder, dina dokument och din Figma-fil är det inte, om de bara finns på en dator.

Prova själv

Ta reda på när din dator, din telefon och hemmets router senast uppdaterades. Hitta inställningen för automatisk uppdatering på var och en och slå på den.

6. HTTPS och hänglåset

Den här är viktig för att nästan alla har fått den förklarad fel.

HTTP är det protokoll webbläsaren och servern pratar med varandra genom (område 1). HTTPS är samma sak med kryptering: allt som skickas mellan din webbläsare och servern är oläsligt för den som sitter emellan – på kaféets wifi, hos internetleverantören, på vägen. Krypteringen bygger på ett certifikat som servern visar upp, och som webbläsaren kontrollerar mot en lista över betrodda utfärdare.

Hänglåset i adressfältet betyder ett enda: förbindelsen är krypterad, och certifikatet stämmer med adressen du ser.

Det betyder inte att sajten är ärlig. Certifikat är gratis sedan flera år, och nätfiskesajter har hänglås precis som alla andra. Ett hänglås på skatteverket-info.xyz säger att din förbindelse till bedragaren är säker.

Läs alltså adressen, inte hänglåset.

Din sajt ska ha HTTPS

GitHub Pages ger din sajt ett certifikat automatiskt. Kontrollera att Enforce HTTPS är förkryssat under repots Settings → Pages – då skickas den som skriver http:// vidare till https://. Google Sites har HTTPS alltid, utan inställning.

En sajt utan HTTPS får en varning i webbläsaren, och sökmotorerna rankar den lägre. Det finns inget skäl att sakna det 2026.

http://exempel.se      → varning: "Inte säker". Trafiken går i klartext.
https://exempel.se     → hänglås. Trafiken är krypterad.

Prova själv

Klicka på hänglåset på din egen sajt. Webbläsaren visar certifikatet: vem som utfärdat det, för vilken adress, och hur länge det gäller. Gör samma sak på en banks sajt och jämför.

7. Din sajt: vad som kan gå fel

En statisk sajt – HTML, CSS och bilder, som din på GitHub Pages – har en liten angreppsyta. Det finns ingen databas att stjäla, ingen inloggning att knäcka, ingen kod som körs på servern. Det är en av de största fördelarna med att bygga så.

Men liten är inte noll. Fyra saker att ha koll på:

Formuläret

Ett formulär utan action skickar ingenting. Kopplar du det till en tjänst som tar emot svaren – Formspree, Netlify Forms, ett Google-formulär – är det den tjänsten som lagrar det besökaren skriver. Då gäller GDPR-guidens avsnitt 6, och du ska veta vilken tjänst det är, var den lagrar och hur länge.

Tredjepartsskript

Varje <script src="https://någon-annans-server/…"> du lägger in är kod du inte skrivit, som körs hos varje besökare med full tillgång till sidan. Blir den servern hackad – det har hänt flera stora leverantörer – körs angriparens kod på din sajt.

<!-- Kod från någon annans server, som körs hos alla dina besökare -->
<script src="https://cdn.exempel.net/widget.js"></script>

Regeln: bara skript du behöver, från leverantörer du har skäl att lita på. Och helst en kopia i ditt eget repo i stället för en länk till deras server – då ändras koden inte utan att du ser det. Kursens moduler i område 6 ligger i ditt repo av det skälet.

Inbäddningar

En iframe med YouTube, en karta, ett inlägg från sociala medier. De är säkrare än skript – innehållet är inlåst i sin ruta – men de skickar besökarens IP-adress till leverantören och sätter ofta kakor. Det är en GDPR-fråga mer än en säkerhetsfråga, men den hör hemma i samma lista.

Det du skriver in själv

Har du JavaScript som tar text från besökaren – ett sökfält, ett formulär vars svar visas på sidan – och lägger in den i sidan med innerHTML, kan besökaren skriva HTML och skript i stället för text. Det kallas XSS (cross-site scripting), och det är det vanligaste säkerhetsfelet på webben. Skyddet: använd textContent när det är text, och lita aldrig på det som kommer utifrån. Det här blir konkret i område 6.

8. Hemligheter och repot

Ditt repo är publikt. Det är ett krav i kursen, och det är rätt – men det betyder att allt du någonsin lagt i det kan läsas av vem som helst, inklusive det du sedan tagit bort. Git glömmer inte. Historiken finns kvar.

Vad som aldrig ska in i ett repo

• Lösenord, i någon form
• API-nycklar och tokens – de långa strängarna en tjänst ger dig för att få anropa den
• Personuppgifter om andra
• Filer med hemligheter, ofta .env eller config med känsligt innehåll

Det låter självklart tills du bygger något som behöver en nyckel – en kart-API, en formulärtjänst – och det enklaste är att skriva in den i koden. Automatiska program söker igenom GitHub dygnet runt efter just sådana nycklar, och en nyckel som läckt används inom minuter. GitHub varnar dig om de känner igen mönstret, men inte för allt.

.gitignore

Filen .gitignore i repots rot säger åt git vilka filer som inte ska följa med. En rad räcker:

.env

Filen finns kvar på din dator och i Codespace, men pushas aldrig.

När det redan hänt

Har du råkat pusha en nyckel hjälper det inte att ta bort den i nästa commit – den finns kvar i historiken. Det som hjälper är att byta ut nyckeln hos tjänsten som gav dig den, så att den läckta blir värdelös. Gör det direkt, städa sedan.

Prova själv

Gå igenom ditt repo på GitHub. Sök på password, token, key och @ i koden. Hittar du något som inte hör hemma där? Tänk också på README.md – det är lätt att skriva in sin mejladress där utan att tänka på att den blir publik.

9. Lösenord och känslig data – det etiska kravet

Kursplanen säger att du ska hantera "lösenord och annan känslig data på ett etiskt riktigt sätt". Det är ett krav på ditt omdöme, inte bara din teknik. Fyra regler:

1. Ett lösenord är personligt. Du lånar inte ut ditt, och du ber inte om någon annans. Inte till en kompis, inte "bara den här gången". Den som delar sitt konto kan inte längre säga vem som gjorde vad.
2. Det du får se är inte ditt att sprida. Sitter du vid någons upplåsta dator, får du ett mejl som inte var till dig, ser du en lista i ett delat dokument – du har sett det, och där stannar det.
3. Lagra aldrig lösenord i klartext. Bygger du något som tar emot lösenord – det gör du inte i den här kursen, men principen ska sitta – sparas de aldrig som de är. De hashas: körs genom en envägsfunktion, så att systemet kan kontrollera ett lösenord utan att kunna läsa det. En tjänst som kan mejla dig ditt gamla lösenord i klartext lagrar det fel.
4. Samla inte in det du inte behöver. Uppgiftsminimeringen från GDPR-guiden, tillämpad på säkerhet: det du inte har kan inte läcka.

Det finns en femte, som inte står i kursplanen men som varje person som arbetar med säkerhet lever efter: hittar du ett hål, säger du till – du använder det inte. Att testa om man kommer in på någon annans konto, sajt eller system utan lov är ett brott (dataintrång, brottsbalken 4 kap. 9 c §), även om avsikten var god.

10. När något hänt

Krisinformation.se sammanfattar: polisanmäl bedrägerier och kontakta din bank om du blivit drabbad. Skäms inte – de som arbetar med detta ser samma sak varje dag, och det enda som gör det värre är att vänta.

11. Ta det längre

Testa din egen sajt

Öppna din sajt, tryck F12 och gå till Network. Ladda om. Lista varje anrop som inte går till din egen adress. För varje rad: vad är det, varför finns det, kan det tas bort eller flyttas in i repot? Skriv upp resultatet på Projekt 4-sajten som ett eget exempel. Det är en riktig säkerhetsgranskning i miniatyr.

Subresource Integrity

Måste du hämta ett skript från någon annans server finns ett skydd: attributet integrity på <script>-taggen innehåller ett kontrollvärde, och webbläsaren vägrar köra filen om den ändrats. Ta reda på hur det fungerar och hur man räknar fram värdet. Det är A-spårets sätt att använda tredjepartskod.

Passkeys – vad som faktiskt händer

Ta reda på hur en passkey fungerar tekniskt: vad som lagras var, varför den inte går att fiska, och varför den bara fungerar på rätt adress. Förklara det på sajten med en egen figur. Den som kan det förstår också varför sms-koder inte räcker.

Ett aktuellt intrång

CERT-SE publicerar veckobrev och varningar. Välj en händelse från det senaste halvåret, läs vad som hände och koppla den till hoten i avsnitt 1. Vilken sårbarhet utnyttjades, och vilken av motåtgärderna i guiden hade stoppat det?

12. Felsökning

13. Snabbreferens

14. Ordlista

15. Källor

Alla hämtade 11 september 2026. Myndigheterna på området har omorganiserats under 2026, så kontrollera att sidan fortfarande finns innan du hänvisar till den, och ange datumet du läste.