Sikkerhedstjekliste til AI-byggede apps: Hvad du skal tjekke før lancering

Før rigtige mennesker bruger en app, du har bygget med AI, skal du tjekke syv ting: hver side og hver API kontrollerer, hvem brugeren er, og hvad vedkommende må; hemmelige nøgler ligger på serveren, aldrig i browseren eller chatten; al input valideres på serveren; hver bruger kan kun nå sine egne poster; login og dyre endpoints har rate limits; afhængigheder er opdaterede; og du kan gendanne dine data, hvis noget går galt. Tjeklisten nedenfor omsætter hvert punkt til konkrete tests, du kan køre uden at læse kode.

AI-app-builders er gode til at få funktioner til at virke. De er ikke automatisk forsigtige, for »forsigtig« står sjældent i prompten. De fleste problemer nedenfor opstår af ting, ingen bad om, så løsningen er typisk at spørge.

Sådan bruger du tjeklisten

Gennemgå den i rækkefølge, og gør to ting for hvert punkt: spørg AI'en for at sikre, at det er håndteret, og test det selv. AI'en kan skrive et rettighedstjek; kun en test viser dig, at det virker. Punkterne er markeret således:

• Skal — gør dette, før andre bruger appen.
• Bør — gør dette, før du har rigtige brugere eller rigtige data.
• Senere — værd at gøre, efterhånden som appen vokser.

Har du kun en time, så gør alle Skal-punkterne.

1. Autentificering: hvem er det?

Autentificering betyder at bekræfte, hvem nogen er — typisk login. Se hvad autentificering er for det grundlæggende og sådan tilføjer du login til din app for mulighederne.

• Skal: Hver side, der viser private data, kræver login. Test: log ud, og indsæt URL'en til en privat side direkte i browseren.
• Skal: Hvert API-endpoint bag disse sider kræver også login — ikke kun siden. Test: log ud, åbn browserens netværksfane, og gentag en forespørgsel, appen lavede, mens du var logget ind.
• Skal: Adgangskoder gemmes hashede med en langsom algoritme til adgangskodehashing, aldrig i klartekst. OWASPs vejledning om lagring af adgangskoder anbefaler Argon2id først, med scrypt, bcrypt eller PBKDF2 som alternativer. Spørg: »Hvordan gemmes adgangskoderne?«
• Bør: Links til nulstilling af adgangskode udløber og virker kun én gang.
• Bør: Sessionscookies er markeret med Secure, HttpOnly og SameSite, og log ud afslutter sessionen på serveren.
• Senere: Tilbyd tofaktorautentificering, eller log ind via en udbyder, der har det.

Kontrollér hver API-rute og side, der returnerer brugerdata. Hver af dem skal afvise forespørgsler fra brugere, der ikke er logget ind, på serveren, ikke kun i sidens kode. List de ruter, du tjekkede.

2. Autorisation: hvad må de?

Autorisation er trinnet efter login: at afgøre, hvad netop denne bruger må se og ændre. Her har AI-byggede apps oftest alvorlige huller, fordi appen ser rigtig ud — hver brugers dashboard viser kun deres egne data — mens serveren gerne udleverer alles data, hvis man beder direkte om det.

• Skal: Hver læsning, opdatering og sletning kontrollerer, at posten tilhører den aktuelle bruger (eller deres team), på serveren.
• Skal: Test det: opret to konti, A og B. Som A åbner du en af A's poster og noterer ID'et i URL'en eller netværksforespørgslen. Log ind som B og anmod om samme ID. B skal få en fejl, ikke A's data.
• Skal: Admin-sider og admin-API-endpoints kontrollerer brugerens rolle på serveren. At skjule admin-linket er ikke beskyttelse.
• Skal: Brugere kan ikke ændre deres egen rolle, pris, saldo eller ejerfelter ved at redigere forespørgslen. Test: se i netværksfanen, hvad en profilopdatering sender. Hvis den indeholder felter som role eller isAdmin, så bed AI'en om at ignorere dem fra klienten.
• Bør: ID'er i URL'er er svære at gætte (tilfældige ID'er frem for 1, 2, 3). Det erstatter ikke rettighedstjek, men begrænser skaden, når et mangler.

For hvert endpoint, der læser eller ændrer en post, skal du kontrollere på serveren, at den indloggede bruger ejer den eller har adgang til den. Returnér 404, hvis ikke. Vis mig derefter, hvordan du ville teste det med to konti.

3. Række-niveau-adgang i databasen

"Række-niveau-adgang" betyder, at hver række i en tabel (én booking, én faktura) kun er synlig for de brugere, den tilhører. Der er to almindelige måder at håndhæve det på:

Begge dele kan gøres godt. Det, der betyder noget:

• Skal: Hvis browseren taler direkte med databasen (nogle hostede databaseprodukter tillader det), er række-niveau-regler slået til for hver tabel. Uden dem kan enhver med den offentlige nøgle læse hele tabellen.
• Skal: Forespørgsler filtrerer på den aktuelle bruger eller team, ikke på et ID browseren sender.
• Bør: Delte data (et teams projekter) har en klar regel for, hvem der er i teamet, håndhævet ét sted.

4. Hemmeligheder og API-nøgler

En API-nøgle er en adgangskode til en tjeneste. Stripe, e-mail og AI-udbydere bruger dem alle. For baggrund, se hvad miljøvariabler og hemmeligheder er.

• Skal: Nøgler gemmes i projektets miljøvariabler eller hemmeligheder, aldrig skrevet ind i koden.
• Skal: Nøgler, der kan bruge penge eller læse private data, bruges kun på serveren. Test: åbn dit live-site, se sidens kilde og JavaScript-filerne i devtools, og søg efter starten på din nøgle (fx sk_). Den må ikke forekomme.
• Skal: Nøgler er aldrig blevet indsat i chatten, et offentligt repository eller et skærmbillede. Hvis de er, så roter nøglen hos udbyderen (opret en ny, slet den gamle).
• Bør: Brug begrænsede eller afgrænsede nøgler, hvor udbyderen tilbyder dem. Stripe anbefaler for eksempel begrænsede nøgler, der kun har de rettigheder, din integration har brug for.
• Bør: Test- og live-nøgler er adskilt, og live-appen bruger kun live-nøgler, når du er klar.

Nogle nøgler er designet til at være offentlige — Stripes publicerbare nøgle (pk_…) eller en kortnøgle begrænset til dit domæne. Reglen handler om nøgler, der giver magt, ikke om alle strenge, der ligner nøgler.

5. Inputvalidering

Alt, en bruger sender — formularfelter, filuploads, URL-parametre — kan være hvad som helst, ikke kun det, din formular tillader.

• Skal: Validering sker på serveren, ikke kun i browseren. Kontroller i browseren er til bekvemmelighed; alle kan springe dem over.
• Skal: Databaseforespørgsler bruger parametre, ikke tekst sammensat af brugerinput (det forhindrer SQL-injektion). Bed AI'en bekræfte det.
• Skal: Tekst, brugere indtaster, vises som tekst, ikke kører som HTML. Test: indtast <b>hej</b> som dit navn. Du skal se tags, ikke fed tekst.
• Bør: Filuploads kontrollerer type og størrelse, og uploadede filer serveres ikke fra appens hoveddomæne som kørbare sider.
• Bør: Fejl vist til brugere er enkle (»Noget gik galt«); detaljerede fejl går kun til serverlogs.
• Bør: Webhooks fra tjenester som Stripe verificerer udbyderens signatur, før de handler. Se hvad en webhook er.

Tilføj serverside-validering til hver formular og API-endpoint: påkrævede felter, længder, formater og tilladte værdier. Afvis alt andet med en tydelig besked. Vis ikke interne fejldetaljer til brugere.

6. Rate limits og misbrug

En rate limit begrænser, hvor mange forespørgsler nogen kan sende i en periode. Uden dem kan hvem som helst gætte adgangskoder hele dagen, oversvømme din tilmeldingsformular eller løbe din regning op på en betalt API.

• Skal: Login, tilmelding og nulstilling af adgangskode har rate limits pr. IP-adresse og pr. konto.
• Skal: Alt, der koster dig penge pr. kald — AI-modelforespørgsler, SMS, e-mail — har en grænse pr. bruger og kræver login.
• Bør: Offentlige formularer (kontakt, venteliste) har spambeskyttelse: en rate limit, et skjult honeypot-felt eller et CAPTCHA.
• Bør: Sæt forbrugslofter eller advarsler hos dine betalte udbydere, så en fejl eller en angriber ikke kan skabe en ubegrænset regning.

7. Afhængigheder

Apps bygges af open source-pakker, og pakker har nogle gange kendte sårbarheder.

• Bør: Bed AI'en tjekke for kendte sårbarheder (for JavaScript-projekter, npm audit eller det tilsvarende for din pakkehåndtering) og opdatere det, der er berørt.
• Bør: Fjern pakker, appen ikke længere bruger.
• Bør: Vær forsigtig med pakker med meget få brugere eller navne, der ligner tastefejl af populære.
• Senere: Tjek igen hver eller to måned, eller slå automatiske advarsler til, hvis din kode ligger på GitHub.

8. Backups og gendannelse

Sikkerhed omfatter også at kunne komme tilbage efter fejl — dine egne, AI'ens eller en angribers.

• Skal: Vid, hvor dine data ligger, og om de er sikkerhedskopieret. Gæt ikke; tjek din hostings dokumentation.
• Bør: Behold din egen periodiske eksport af vigtige data (fx en CSV-eksportfunktion eller et database-dump), gemt et andet sted.
• Bør: Behold din kode i versionsstyring, så enhver version kan gendannes.
• Bør: Ødelæggende handlinger (slet konto, slet projekt) beder om bekræftelse, og overvej en »blød sletning«, der kan fortrydes i et stykke tid.
• Senere: Test faktisk en gendannelse én gang. En backup, du aldrig har gendannet, er et håb, ikke en plan.

9. Før lancering

• Skal: Live-sitet bruger HTTPS overalt.
• Skal: Eksempeldata, testkonti og debugsider fra udviklingen er fjernet.
• Bør: En privatlivspolitik siger, hvilke data du indsamler og hvorfor — det er påkrævet mange steder, hvis du indsamler personoplysninger. Påstå ikke certificeringer (SOC 2, HIPAA), du ikke har.
• Bør: Du har en måde, folk kan kontakte dig om sikkerhedsproblemer på, og du ved, hvordan du hurtigt roterer alle nøgler.

Til en bredere gennemgang før lancering ud over sikkerhed, se sådan tager du en AI-prototype til produktion.

Hvornår du bør få en professionel gennemgang

En tjekliste fanger almindelige fejl; den erstatter ikke en ekspert. Overvej at betale for en gennemgang, hvis du selv behandler kortnumre i stedet for gennem et hostet checkout, opbevarer sundheds-, finans- eller børnedata, sælger til virksomheder, der stiller sikkerhedsspørgeskemaer, eller ville blive alvorligt skadet af et datalæk. At din kode kan eksporteres, gør en sådan gennemgang meget lettere.

Sikkerhed når du bygger på Mythex

Mythex har ikke et sikkerhedsscanningspanel, så tjeklisten ovenfor er processen, du skal følge. Nogle ting hjælper:

• Projekthemmeligheder. Gem nøgler under projektindstillinger → Secrets, eller via hemmelighedskortet agenten viser i chatten, så de holdes ude af din kode og dine beskeder. Efter du har ændret en hemmelighed for en live-app, så publicer igen.
• Plan- og Ask-tilstande. Bed agenten gennemgå rettigheder uden at redigere: »I Ask-tilstand, list hver API-rute og hvilket rettighedstjek den laver.«
• /test får agenten til at klikke sig gennem din preview som en bruger — nyttigt til to-konto-testen i afsnit 2.
• Checkpoints lader dig rulle en ændring tilbage, der har ødelagt noget.

Se Sikkerhed for apps du bygger og Miljøvariabler og hemmeligheder i dokumentationen. Hvis du tilføjer brugerkonti næste gang, så læs sådan tilføjer du login til din app.

Spørgsmål