Säkerhetschecklista för AI-byggda appar: vad du ska kontrollera före lansering

Innan riktiga personer använder en app du byggt med AI, kontrollera sju saker: varje sida och API kontrollerar vem användaren är och vad hen får göra; hemliga nycklar ligger på servern, aldrig i webbläsaren eller chatten; all indata validerras på servern; varje användare kan bara nå sina egna poster; inloggning och kostsamma endpoints är begränsade i antal anrop; beroenden är uppdaterade; och du kan återställa dina data om något går fel. Checklistan nedan gör om vart och ett av dessa till konkreta tester du kan köra utan att läsa kod.

AI-appbyggare är bra på att få funktioner att fungera. De är inte automatiskt försiktiga, eftersom ”försiktig” sällan finns med i prompten. De flesta problemen nedan kommer från saker ingen bad om, så lösningen är oftast att be om dem.

Så använder du checklistan

Gå igenom den i ordning, och gör två saker för varje punkt: be AI:n att se till att den är hanterad, och testa själv. AI:n kan skriva en behörighetskontroll; bara ett test visar att den fungerar. Punkterna är märkta:

• Måste – gör detta innan någon annan använder appen.
• Bör – gör detta innan du har riktiga användare eller riktig data.
• Senare – värt att göra när appen växer.

Har du bara en timme, gör alla Måste-punkter.

1. Autentisering: vem är det här?

Autentisering innebär att bekräfta vem någon är, vanligtvis genom inloggning. Se vad autentisering är för grunderna och hur du lägger till inloggning i din app för alternativen.

• Måste: Varje sida som visar privata data kräver inloggning. Test: logga ut och klistra in URL:en till en privat sida direkt i webbläsaren.
• Måste: Varje API-endpoint bakom de sidorna kräver också inloggning, inte bara sidan. Test: logga ut, öppna nätverksfliken i webbläsaren och gör om en förfrågan som appen gjorde när du var inloggad.
• Måste: Lösenord lagras hashade med en långsam hashalgoritm för lösenord, aldrig i klartext. OWASP:s riktlinjer för lagring av lösenord rekommenderar Argon2id först, med scrypt, bcrypt eller PBKDF2 som alternativ. Fråga: ”Hur lagras lösenorden?”
• Bör: Länkar för återställning av lösenord går ut och fungerar bara en gång.
• Bör: Sessionskakor är markerade med Secure, HttpOnly och SameSite, och utloggning avslutar sessionen på servern.
• Senare: Erbjud tvåfaktorsautentisering, eller inloggning via en leverantör som har det.

Kontrollera varje API-rutt och sida som returnerar användardata. Var och en måste avvisa förfrågningar från användare som inte är inloggade, på servern, inte bara i sidans kod. Lista de rutter du kontrollerade.

2. Auktorisering: vad får de göra?

Auktorisering är steget efter inloggningen: att avgöra vad just den här användaren får se och ändra. Det är här AI-byggda appar oftast har allvarliga hål, eftersom appen ser rätt ut. Varje användares instrumentpanel visar bara deras egna data, medan servern gärna lämnar ut vems data som helst om någon frågar direkt.

• Måste: Varje läsning, uppdatering och borttagning kontrollerar på servern att posten tillhör den inloggade användaren (eller deras team).
• Måste: Testa det: skapa två konton, A och B. Som A, öppna en av A:s poster och notera ID:t i URL:en eller nätverksförfrågan. Logga in som B och begär samma ID. B måste få ett felmeddelande, inte A:s data.
• Måste: Administratörssidor och administratörs-API-endpoints kontrollerar användarens roll på servern. Att dölja administratörslänken är inget skydd.
• Måste: Användare kan inte ändra sin egen roll, pris, saldo eller ägarfält genom att redigera förfrågan. Test: titta i nätverksfliken på vad en profiluppdatering skickar. Om den innehåller fält som role eller isAdmin, be AI:n att ignorera dem från klienten.
• Bör: ID:n i URL:er är svåra att gissa (slumpmässiga ID:n i stället för 1, 2, 3). Detta ersätter inte behörighetskontroller, men begränsar skadan när en saknas.

För varje endpoint som läser eller ändrar en post, kontrollera på servern att den inloggade användaren äger den eller får komma åt den. Returnera 404 om inte. Visa sedan hur du skulle testa detta med två konton.

3. Radnivååtkomst i databasen

”Radnivååtkomst” innebär att varje rad i en tabell (en bokning, en faktura) bara är synlig för de användare den tillhör. Det finns två vanliga sätt att säkerställa det:

Endera kan göras bra. Det som betyder något:

• Måste: Om webbläsaren pratar direkt med databasen (vissa hostade databastjänster tillåter det), är radregler påslagna för varje tabell. Utan dem kan vem som helst med den publika nyckeln läsa hela tabellen.
• Måste: Frågor filtrerar på den aktuella användaren eller teamet, inte på ett ID som webbläsaren skickar.
• Bör: Delad data (ett teams projekt) har en tydlig regel för vem som ingår i teamet, och den tillämpas på ett ställe.

4. Hemligheter och API-nycklar

En API-nyckel är ett lösenord till en tjänst. Stripe, e-post och AI-leverantörer använder alla sådana. För bakgrund, se vad miljövariabler och hemligheter är.

• Måste: Nycklar lagras i projektets miljövariabler eller hemligheter, aldrig skrivna i koden.
• Måste: Nycklar som kan spendera pengar eller läsa privat data används endast på servern. Test: öppna din live-sajt, visa sidans källkod och JavaScript-filerna i utvecklarverktygen och sök efter början på din nyckel (till exempel sk_). Den får inte finnas där.
• Måste: Nycklar har aldrig klistrats in i chatten, ett publikt repo eller en skärmbild. Om en har det, rotera den hos leverantören (skapa en ny, ta bort den gamla).
• Bör: Använd begränsade eller avgränsade nycklar där leverantören erbjuder dem. Stripe rekommenderar till exempel begränsade nycklar som bara har de behörigheter din integration behöver.
• Bör: Test- och live-nycklar är separata, och live-appen använder bara live-nycklar när du är redo.

Vissa nycklar är avsedda att vara publika, till exempel Stripes publicerbara nyckel (pk_…) eller en kartnyckel begränsad till din domän. Regeln gäller nycklar som ger makt, inte varje sträng som ser ut som en nyckel.

5. Indatavalidering

Allt en användare skickar in (formulärfält, filuppladdningar, URL-parametrar) kan vara vad som helst, inte bara det ditt formulär tillåter.

• Måste: Validering sker på servern, inte bara i webbläsaren. Kontroller i webbläsaren är till för bekvämlighet; vem som helst kan hoppa över dem.
• Måste: Databasfrågor använder parametrar, inte text som limmats ihop av användarindata (detta förhindrar SQL-injektion). Be AI:n bekräfta det.
• Måste: Text som användare skriver visas som text, inte körs som HTML. Test: skriv <b>hello</b> som ditt namn. Du ska se taggarna, inte fet text.
• Bör: Filuppladdningar kontrollerar typ och storlek, och uppladdade filer serveras inte från appens huvuddomän som körbara sidor.
• Bör: Felmeddelanden som visas för användare är enkla (”Något gick fel”); detaljerade fel går bara till serverloggarna.
• Bör: Webhooks från tjänster som Stripe verifierar leverantörens signatur innan de agerar. Se vad en webhook är.

Lägg till validering på servern för varje formulär och API-endpoint: obligatoriska fält, längder, format och tillåtna värden. Avvisa allt annat med ett tydligt meddelande. Visa inga interna feldetaljer för användare.

6. Begränsningar och missbruk

En gräns för anrop begränsar hur många förfrågningar någon kan göra under en period. Utan den kan vem som helst gissa lösenord hela dagen, översvämma ditt registreringsformulär eller köra upp din räkning på ett betalt API.

• Måste: Inloggning, registrering och återställning av lösenord har gränser per IP-adress och per konto.
• Måste: Allt som kostar dig pengar per anrop (AI-modellförfrågningar, SMS, e-post) har en gräns per användare och kräver inloggning.
• Bör: Publika formulär (kontakt, väntelista) har spamskydd: en gräns för anrop, ett dolt fält (honeypot) eller en CAPTCHA.
• Bör: Ange utgiftstak eller larm hos dina betalda leverantörer, så att en bugg eller en angripare inte kan ge en obegränsad räkning.

7. Beroenden

Appar byggs av paket med öppen källkod, och paket har ibland kända sårbarheter.

• Bör: Be AI:n kontrollera kända sårbarheter (för JavaScript-projekt, npm audit eller motsvarande för din pakethanterare) och uppdatera det som påverkas.
• Bör: Ta bort paket som appen inte längre använder.
• Bör: Var försiktig med paket som har väldigt få användare eller namn som liknar stavfel av populära paket.
• Senare: Kontrollera igen varje eller varannan månad, eller slå på automatiska larm om din kod ligger på GitHub.

8. Säkerhetskopior och återställning

Säkerhet inkluderar att kunna återhämta sig från misstag, dina egna, AI:ns eller en angripares.

• Måste: Veta var dina data finns och om de säkerhetskopieras. Anta inte; kontrollera din hostings dokumentation.
• Bör: Behåll en egen periodisk export av viktiga data (till exempel en CSV-exportfunktion eller en databasdump), lagrad på ett separat ställe.
• Bör: Behåll din kod i versionshantering, så att vilken version som helst kan återställas.
• Bör: Förstörande åtgärder (ta bort konto, ta bort projekt) kräver bekräftelse, och överväg en ”mjuk borttagning” som kan ångras under en tid.
• Senare: Testa faktiskt en återställning en gång. En säkerhetskopia du aldrig återställt är ett hopp, inte en plan.

9. Före lansering

• Måste: Den live-publicerade sajten använder HTTPS överallt.
• Måste: Exempeldata, testkonton och felsökningssidor från utvecklingen är borttagna.
• Bör: En integritetspolicy anger vilka data du samlar in och varför – krävs på många platser om du samlar in personuppgifter. Påstå inte certifieringar (SOC 2, HIPAA) du inte har.
• Bör: Du har ett sätt att bli kontaktad om säkerhetsproblem, och du vet hur du snabbt roterar varje nyckel.

För en bredare genomgång före lansering utöver säkerhet, se hur du tar en AI-prototyp till produktion.

När du bör få en professionell granskning

En checklista fångar vanliga misstag; den ersätter inte en expert. Överväg att betala för en granskning om du behandlar kortnummer själv i stället för via en hostad betalningssida, lagrar hälso-, finans- eller barnuppgifter, säljer till företag som ställer säkerhetsfrågeformulär eller skulle skadas allvarligt av ett läckage. Att din kod kan exporteras gör granskningen mycket enklare.

Säkerhet när du bygger på Mythex

Mythex har ingen säkerhetsskanningspanel, så checklistan ovan är processen att följa. Några saker som hjälper:

• Projekthemligheter. Lagra nycklar under projektinställningar → Hemligheter, eller via hemlighetskortet agenten visar i chatten, så att de hålls borta från din kod och dina meddelanden. Publicera igen efter att du ändrat en hemlighet för en live-app.
• Plan- och Ask-lägen. Be agenten granska behörigheter utan att redigera: ”I Ask-läge, lista varje API-rutt och vilken behörighetskontroll den gör.”
• /test låter agenten klicka runt i din förhandsvisning som en användare, användbart för tvåkontotestet i avsnitt 2.
• Checkpoints låter dig backa en ändring som förstörde något.

Se Säkerhet för appar du bygger och Miljövariabler och hemligheter i dokumentationen. Om du lägger till användarkonton härnäst, läs hur du lägger till inloggning i din app.

Frågor