Sikkerhetssjekkliste for apper bygget med AI: Hva du bør sjekke før lansering

Før ekte mennesker bruker en app du har bygget med AI, sjekk sju ting: hver side og API sjekker hvem brukeren er og hva vedkommende har lov til; hemmelige nøkler ligger på serveren, aldri i nettleseren eller chatten; all input valideres på serveren; hver bruker kan bare nå sine egne poster; innlogging og kostbare endepunkter har hastighetsgrenser; avhengigheter er oppdaterte; og du kan gjenopprette dataene dine hvis noe går galt. Sjekklisten under gjør hvert av disse om til konkrete tester du kan kjøre uten å lese kode.

AI-appbyggere er gode til å få funksjoner til å fungere. De er ikke automatisk forsiktige, fordi «forsiktig» sjelden står i forespørselen. De fleste problemene nedenfor kommer fra ting ingen ba om, så løsningen er vanligvis å be om det.

Slik bruker du sjekklisten

Gå gjennom den i rekkefølge, og for hvert punkt gjør du to ting: be AI-en om å sørge for at det er håndtert, og test det selv. AI-en kan skrive en tillatelsessjekk; bare en test forteller deg at den fungerer. Punktene er merket slik:

• Må — gjør dette før noen andre bruker appen.
• Bør — gjør dette før du har ekte brukere eller ekte data.
• Senere — verdt å gjøre etter hvert som appen vokser.

Hvis du bare har én time, gjør alle Må-punktene.

1. Autentisering: hvem er dette?

Autentisering betyr å bekrefte hvem noen er — vanligvis med innlogging. Se hva autentisering er for grunnlaget og hvordan du legger til innlogging i appen din for alternativene.

• Må: Hver side som viser private data krever innlogging. Test: logg ut, og lim URL-en til en privat side direkte inn i nettleseren.
• Må: Hvert API-endepunkt bak disse sidene krever også innlogging — ikke bare siden. Test: logg ut, åpne nettleserens nettverksfane, og prøv på nytt en forespørsel appen gjorde mens du var logget inn.
• Må: Passord lagres hashet med en treg passord-hashing-algoritme, aldri i klartekst. OWASPs veiledning for passordlagring anbefaler Argon2id først, med scrypt, bcrypt eller PBKDF2 som alternativer. Spør: «Hvordan lagres passordene?»
• Bør: Lenker for tilbakestilling av passord utløper og fungerer bare én gang.
• Bør: Øktcookies er merket Secure, HttpOnly og SameSite, og utlogging avslutter økten på serveren.
• Senere: Tilby tofaktorautentisering, eller innlogging via en leverandør som har det.

Sjekk hver API-rute og side som returnerer brukerdata. Hver av dem må avvise forespørsler fra brukere som ikke er logget inn, på serveren, ikke bare i sidens kode. List opp rutene du sjekket.

2. Autorisasjon: hva har de lov til å gjøre?

Autorisasjon er steget etter innlogging: å avgjøre hva denne spesielle brukeren kan se og endre. Her har apper bygget med AI oftest alvorlige hull, fordi appen ser riktig ut — hver brukers dashbord viser bare deres egne data — mens serveren gladelig gir fra seg andres data hvis man ber direkte om det.

• Må: Hver lesing, oppdatering og sletting sjekker på serveren at posten tilhører gjeldende bruker (eller teamet deres).
• Må: Test det: opprett to kontoer, A og B. Som A, åpne en av As poster og noter ID-en i URL-en eller nettverksforespørselen. Logg inn som B og be om samme ID. B må få en feil, ikke As data.
• Må: Administrasjonssider og administrasjons-API-endepunkter sjekker brukerens rolle på serveren. Å skjule admin-lenken er ikke beskyttelse.
• Må: Brukere kan ikke endre sin egen rolle, pris, saldo eller eierfelt ved å redigere forespørselen. Test: se i nettverksfanen hva en profiloppdatering sender. Hvis den inneholder felt som role eller isAdmin, be AI-en ignorere dem fra klienten.
• Bør: ID-er i URL-er er vanskelige å gjette (tilfeldige ID-er i stedet for 1, 2, 3). Dette erstatter ikke tillatelsessjekker, men begrenser skaden når en mangler.

For hvert endepunkt som leser eller endrer en post, sjekk på serveren at innlogget bruker eier den eller har tilgang til den. Returner 404 hvis ikke. Vis meg deretter hvordan du ville testet dette med to kontoer.

3. Radnivåtilgang i databasen

«Radnivåtilgang» betyr at hver rad i en tabell (én booking, én faktura) bare er synlig for brukerne den tilhører. Det finnes to vanlige måter å håndheve det på:

Begge kan gjøres godt. Det som betyr noe:

• Må: Hvis nettleseren snakker direkte med databasen (noen hostede databaseprodukter tillater dette), er radnivåregler slått på for hver tabell. Uten dem kan alle med den offentlige nøkkelen lese hele tabellen.
• Må: Spørringer filtrerer på gjeldende bruker eller team, ikke på en ID nettleseren sender.
• Bør: Delte data (et teams prosjekter) har en klar regel for hvem som er med i teamet, håndhevet på ett sted.

4. Hemmeligheter og API-nøkler

En API-nøkkel er et passord for en tjeneste. Stripe, e-post og AI-leverandører bruker alle dem. For bakgrunn, se hva miljøvariabler og hemmeligheter er.

• Må: Nøkler lagres i prosjektets miljøvariabler eller hemmeligheter, aldri skrevet inn i koden.
• Må: Nøkler som kan bruke penger eller lese private data brukes bare på serveren. Test: åpne den live siden, se kildekoden og JavaScript-filene i utviklerverktøyene, og søk etter starten på nøkkelen din (for eksempel sk_). Den må ikke finnes der.
• Må: Nøkler er aldri limt inn i chatten, et offentlig arkiv eller et skjermbilde. Hvis en har blitt det, bytt den hos leverandøren (lag en ny, slett den gamle).
• Bør: Bruk begrensede eller avgrensede nøkler der leverandøren tilbyr det. Stripe anbefaler for eksempel begrensede nøkler som bare har tillatelsene integrasjonen din trenger.
• Bør: Test- og live-nøkler er separate, og den live appen bruker live-nøkler først når du er klar.

Noen nøkler er laget for å være offentlige — Stripes publiserbare nøkkel (pk_…) eller en kartnøkkel begrenset til domenet ditt. Regelen gjelder nøkler som gir makt, ikke hver streng som ser ut som en nøkkel.

5. Validering av input

Alt en bruker sender — skjemafelt, filopplastinger, URL-parametere — kan være hva som helst, ikke bare det skjemaet ditt tillater.

• Må: Validering skjer på serveren, ikke bare i nettleseren. Sjekker i nettleseren er for bekvemmelighet; hvem som helst kan hoppe over dem.
• Må: Databasespørringer bruker parametere, ikke tekst limt sammen av brukerinput (dette forhindrer SQL-injeksjon). Be AI-en bekrefte det.
• Må: Tekst brukere skriver inn vises som tekst, ikke kjøres som HTML. Test: skriv <b>hei</b> som navnet ditt. Du skal se taggene, ikke fet tekst.
• Bør: Filopplastinger sjekker type og størrelse, og opplastede filer serveres ikke fra appens hoveddomene som kjørbare sider.
• Bør: Feil som vises til brukere er enkle («Noe gikk galt»); detaljerte feil går bare til serverloggene.
• Bør: Webhooks fra tjenester som Stripe verifiserer leverandørens signatur før de gjør noe. Se hva en webhook er.

Legg til validering på serveren for hvert skjema og API-endepunkt: påkrevde felt, lengder, formater og tillatte verdier. Avvis alt annet med en tydelig melding. Vis ikke interne feildetaljer til brukere.

6. Hastighetsgrenser og misbruk

En hastighetsgrense begrenser hvor mange forespørsler noen kan gjøre i en periode. Uten dem kan hvem som helst gjette passord hele dagen, oversvømme registreringsskjemaet ditt, eller drive opp regningen din på et betalt API.

• Må: Innlogging, registrering og tilbakestilling av passord har hastighetsgrenser per IP-adresse og per konto.
• Må: Alt som koster deg penger per kall — forespørsler til AI-modeller, SMS, e-post — har en grense per bruker og krever innlogging.
• Bør: Offentlige skjemaer (kontakt, venteliste) har spambeskyttelse: en hastighetsgrense, et skjult honeypot-felt, eller en CAPTCHA.
• Bør: Sett forbruksgrenser eller varsler hos de betalte leverandørene dine, slik at en feil eller en angriper ikke kan lage en ubegrenset regning.

7. Avhengigheter

Apper bygges av åpen kildekode-pakker, og pakker har noen ganger kjente sårbarheter.

• Bør: Be AI-en sjekke for kjente sårbarheter (for JavaScript-prosjekter, npm audit eller tilsvarende for pakkebehandleren din) og oppdatere det som er berørt.
• Bør: Fjern pakker appen ikke lenger bruker.
• Bør: Vær forsiktig med pakker med svært få brukere eller navn som ligner skrivefeil av populære pakker.
• Senere: Sjekk på nytt hver eller annenhver måned, eller slå på automatiske varsler hvis koden din er på GitHub.

8. Sikkerhetskopier og gjenoppretting

Sikkerhet inkluderer å kunne gjenopprette etter feil — dine, AI-ens eller en angripers.

• Må: Vit hvor dataene dine ligger og om de sikkerhetskopieres. Ikke anta; sjekk dokumentasjonen til hosten din.
• Bør: Ta din egen jevnlige eksport av viktige data (for eksempel en CSV-eksportfunksjon eller en databasedump), lagret et annet sted.
• Bør: Hold koden din i versjonskontroll, slik at en hvilken som helst versjon kan gjenopprettes.
• Bør: Ødeleggende handlinger (slette konto, slette prosjekt) krever bekreftelse, og vurder en «myk sletting» som kan angres en periode.
• Senere: Test en gjenoppretting faktisk én gang. En sikkerhetskopi du aldri har gjenopprettet er et håp, ikke en plan.

9. Før lansering

• Må: Den live siden bruker HTTPS overalt.
• Må: Eksempeldata, testkontoer og feilsøkingssider fra utvikling er fjernet.
• Bør: En personvernerklæring sier hvilke data du samler inn og hvorfor — påkrevd mange steder hvis du samler inn personopplysninger. Ikke påstå sertifiseringer (SOC 2, HIPAA) du ikke har.
• Bør: Du har en måte å bli kontaktet om sikkerhetsproblemer på, og du vet hvordan du raskt bytter ut hver nøkkel.

For en bredere gjennomgang før lansering utover sikkerhet, se hvordan du tar en AI-prototype til produksjon.

Når du bør få en profesjonell gjennomgang

En sjekkliste fanger vanlige feil; den erstatter ikke en ekspert. Vurder å betale for en gjennomgang hvis du behandler kortnumre selv i stedet for gjennom en hostet betalingsside, lagrer helse-, finans- eller barnedata, selger til selskaper som krever sikkerhetsspørreskjemaer, eller ville blitt alvorlig skadet av et datalekkasje. At koden din kan eksporteres gjør en slik gjennomgang mye enklere.

Sikkerhet når du bygger på Mythex

Mythex har ikke et panel for sikkerhetsskanning, så sjekklisten over er prosessen å følge. Noen ting som hjelper:

• Prosjekthemmeligheter. Lagre nøkler under prosjektinnstillinger → Secrets, eller gjennom hemmelighetskortet agenten viser i chatten, slik at de holdes ute av koden og meldingene dine. Etter å ha endret en hemmelighet for en live-app, publiser på nytt.
• Plan- og Ask-moduser. Be agenten gjennomgå tillatelser uten å redigere: «I Ask-modus, list opp hver API-rute og hvilken tillatelsessjekk den gjør.»
• /test får agenten til å klikke gjennom forhåndsvisningen din som en bruker — nyttig for to-kontotesten i seksjon 2.
• Sjekkpunkter lar deg rulle tilbake en endring som ødela noe.

Se Sikkerhet for apper du bygger og Miljøvariabler og hemmeligheter i dokumentasjonen. Hvis du legger til brukerkontoer neste, les hvordan du legger til innlogging i appen din.

Spørsmål