Modellen bygger vad du ber om, inte vad som är säkert. Den invänder inte, eftersom den inte vet om appen ska ligga på din egen dator eller ta emot tusen anmälningar. Säkerheten är därför inte något du kan beställa fram med ett ord — den är fyra frågor du ställer själv innan du delar länken.
Hål 1: nyckeln i webbläsaren
Det vanligaste och allvarligaste. Appen behöver prata med en tjänst — en modell, en databas, en mejlutskickare — och den behöver en nyckel för att få göra det. Modellen lägger nyckeln där den är enklast att använda: i koden som skickas ut till besökarens webbläsare.
Där kan vem som helst läsa den. Inte teoretiskt, utan med två klick. Och en läckt nyckel används inte för att förstöra din app — den används för att köra upp en räkning i ditt namn.
Finns det någon API-nyckel, något lösenord eller någon annan hemlig sträng i den kod som skickas till besökarens webbläsare?
Svara ja eller nej, och visa i så fall exakt var. Räkna även med det som ligger i konfigurationsfiler som byggs in i sidan.
Är svaret ja är lösningen alltid densamma: anropet ska göras från serversidan, och nyckeln ska ligga i en inställning på servern som aldrig skickas ut. Beställ det som ett eget steg. Och byt nyckeln efteråt — den gamla ska betraktas som läckt så snart den legat publikt.
Hål 2: kontrollen som ligger på fel sida
En app som visar olika saker för olika användare måste bestämma vem som får se vad. Om beslutet fattas i webbläsaren är det inget beslut — det är en rekommendation som besökaren kan strunta i.
Symptomet är lätt att känna igen: appen "gömmer" en knapp eller en sida för användare som inte ska se den. Att gömma är inte att skydda.
Var avgörs vem som får se administratörssidan — i webbläsaren eller på servern?
Om jag skriver in adressen direkt, utan att gå via menyn, blir jag då stoppad? Visa var kontrollen sker.
Hål 3: allt går att skicka in
Ett formulärfält som säger "e-post" tar emot vad som helst. Att fältet har rätt typ i webbläsaren hjälper mot slarv, inte mot avsiktligt missbruk.
- Kontroll på servern, inte bara i formuläret. Frågan att ställa: "Kontrolleras fälten även när någon skickar in data utan att använda formuläret?"
- Gräns för hur mycket som kan skickas. Utan gräns kan någon skicka in en text på tio megabyte, eller tiotusen anmälningar på en minut.
- Hantering av text som visas vidare. Om någon skriver in kod i namnfältet och det syns i listan för andra — då körs deras text i din app. Fråga: "Vad händer om någon skriver in HTML eller skript i ett textfält?"
Hål 4: allas data för alla
Det subtilaste av de fyra. Inloggningen fungerar, alla har eget konto — men när man kommit in ser man allas uppgifter, för ingen har begränsat vad varje användare får läsa.
Kontrollen är enkel om appen har fler än en användare: skapa två konton, logga in som den ena, och försök nå den andras data genom att byta ett nummer i adressen. Om det går har du hittat hålet.
Om användare A är inloggad och byter ut sitt eget id mot användare B:s i adressen — får A då se B:s uppgifter?
Visa raden som avgör det. Om ingen sådan kontroll finns, säg det rakt ut.
Personuppgifter: vad som faktiskt krävs
Så snart appen tar emot ett namn, en mejladress eller ett telefonnummer behandlar du personuppgifter, och då gäller GDPR. Det låter tyngre än det är för en anmälningslista, men fyra saker måste finnas på plats.
- Var data lagras geografiskt. Använder appen en tjänst som lagrar data utanför EU tillkommer krav. Fråga verktyget var databasen ligger — svaret ska gå att verifiera på leverantörens egen sida.
- Vad du skickar in i modellen. Om appen skickar användarnas texter vidare till en språkmodell lämnar personuppgifterna huset. Det ska stå i informationstexten, och det bör vara ett medvetet val.
Den här guiden är inte juridisk rådgivning. För en anmälningslista i en förening räcker punkterna ovan långt. Handlar appen om hälsa, ekonomi eller barn är kraven högre och då är det värt att fråga någon som kan området.
Behöver du reda ut ord som personuppgiftsansvarig, biträde, AI-system eller promptinjektion finns korta svenska förklaringar i AI på svenskas ordlista. Använd definitionerna som orientering, inte som ersättning för juridisk bedömning.
Källor och kontrolltid
Fem primärkällor lästes den 9 september 2026. De fyra IMY-sidorna stödjer kraven i avsnittet om personuppgifter — vad som räknas som en personuppgift, principerna om ändamål och lagringstid, den registrerades rätt till information och radering, samt vad som tillkommer när data lagras utanför EU. OWASP-sidan stödjer varför en nyckel inte hör hemma i webbläsaren. Hålen, provordningen och exemplen är den här guidens egna.
- IMY: Personuppgifter – att ett namn, en mejladress eller ett telefonnummer är personuppgifter, och att GDPR därmed gäller.
- IMY: Grundläggande principer – ändamålsbegränsning, uppgiftsminimering och lagringsminimering, alltså skälet att samla in och gränsen för hur länge.
- IMY: De registrerades rättigheter – rätten till information vid insamlingen och rätten till radering.
- IMY: Överföring till tredje land – vad som tillkommer när uppgifterna hamnar utanför EU/EES.
- OWASP: Secrets Management Cheat Sheet – varför hemligheter inte ska ligga i klienten och hur de i stället hanteras.
Nästa kontroll senast den 9 december 2026, eller tidigare om IMY ändrar sin vägledning eller om reglerna för överföring till tredje land ändras. Guiden är inte juridisk rådgivning; källorna är myndighetens egen vägledning, inte en bedömning av just din app.
Nästa steg
Sista guiden i serien handlar om verktygen: vad de tre sorterna är bra på, vad de kostar, och hur du undviker att låsa in projektet hos en leverantör du inte valt medvetet.