Beveiligingschecklist voor met AI gebouwde apps: wat je controleert voor de lancering

Voordat echte mensen een app gebruiken die je met AI hebt gebouwd, controleer je zeven dingen: elke pagina en API controleert wie de gebruiker is en wat die mag doen; geheime sleutels staan op de server, nooit in de browser of de chat; alle invoer wordt aan de serverkant gevalideerd; elke gebruiker kan alleen zijn eigen records bereiken; login en kostbare endpoints hebben een rate limit; afhankelijkheden zijn up-to-date; en je kunt je gegevens herstellen als er iets misgaat. De checklist hieronder vertaalt elk daarvan naar concrete tests die je kunt uitvoeren zonder code te lezen.

AI-appbouwers zijn goed in het laten werken van functies. Ze zijn niet automatisch zorgvuldig, omdat “zorgvuldig” zelden in de prompt staat. De meeste problemen hieronder komen door dingen waar niemand om heeft gevraagd, dus de oplossing is meestal om ernaar te vragen.

Hoe je deze checklist gebruikt

Doorloop hem in volgorde, en doe voor elk punt twee dingen: vraag de AI om ervoor te zorgen dat het is afgehandeld, en test het zelf. De AI kan een rechtencontrole schrijven; alleen een test laat zien dat die werkt. Items zijn gemarkeerd als:

• Moet — doe dit voordat iemand anders de app gebruikt.
• Zou moeten — doe dit voordat je echte gebruikers of echte data hebt.
• Later — de moeite waard naarmate de app groeit.

Als je maar een uur hebt, doe dan alle Moet-punten.

1. Authenticatie: wie is dit?

Authenticatie betekent bevestigen wie iemand is — meestal via login. Zie wat authenticatie is voor de basis en hoe je login aan je app toevoegt voor de opties.

• Moet: Elke pagina die privégegevens toont, vereist login. Test: log uit en plak de URL van een privépagina rechtstreeks in de browser.
• Moet: Elk API-endpoint achter die pagina’s vereist ook login — niet alleen de pagina. Test: log uit, open het netwerktabblad van de browser en probeer opnieuw een verzoek dat de app deed terwijl je was ingelogd.
• Moet: Wachtwoorden worden opgeslagen als hash met een langzaam wachtwoord-hashalgoritme, nooit als platte tekst. De OWASP-richtlijnen voor wachtwoordopslag raden eerst Argon2id aan, met scrypt, bcrypt of PBKDF2 als alternatieven. Vraag: “Hoe worden wachtwoorden opgeslagen?”
• Zou moeten: Links voor het resetten van wachtwoorden verlopen en werken maar één keer.
• Zou moeten: Sessiecookies zijn voorzien van Secure, HttpOnly en SameSite, en uitloggen beëindigt de sessie op de server.
• Later: Bied tweestapsverificatie aan, of inloggen via een provider die dat heeft.

Controleer elke API-route en pagina die gebruikersgegevens teruggeeft. Elke route moet verzoeken weigeren van gebruikers die niet zijn ingelogd, op de server, niet alleen in de code van de pagina. Geef een lijst van de routes die je hebt gecontroleerd.

2. Autorisatie: wat mogen ze doen?

Autorisatie is de stap na login: bepalen wat deze specifieke gebruiker mag zien en wijzigen. Hier hebben met AI gebouwde apps het vaakst ernstige gaten, omdat de app er goed uitziet — het dashboard van elke gebruiker toont alleen hun eigen gegevens — terwijl de server de gegevens van iedereen zonder meer teruggeeft als je er rechtstreeks om vraagt.

• Moet: Elke lees-, update- en verwijderactie controleert op de server dat het record bij de huidige gebruiker (of hun team) hoort.
• Moet: Test het: maak twee accounts, A en B. Open als A een van de records van A en noteer het ID in de URL of het netwerkverzoek. Log in als B en vraag hetzelfde ID op. B moet een fout krijgen, niet de gegevens van A.
• Moet: Beheerderspagina’s en beheerders-API-endpoints controleren de rol van de gebruiker op de server. Het verbergen van de beheerderslink is geen bescherming.
• Moet: Gebruikers kunnen hun eigen rol, prijs, saldo of eigenaarsvelden niet wijzigen door het verzoek aan te passen. Test: bekijk in het netwerktabblad wat een profielupdate verstuurt. Als er velden als role of isAdmin in staan, vraag de AI die vanaf de client te negeren.
• Zou moeten: ID’s in URL’s zijn moeilijk te raden (willekeurige ID’s in plaats van 1, 2, 3). Dit vervangt geen rechtencontroles, maar beperkt de schade als er een ontbreekt.

Controleer voor elk endpoint dat een record leest of wijzigt op de server of de ingelogde gebruiker er eigenaar van is of er toegang toe mag hebben. Geef 404 terug als dat niet zo is. Laat me daarna zien hoe je dit test met twee accounts.

3. Toegang op rijniveau in de database

“Toegang op rijniveau” betekent dat elke rij van een tabel (één boeking, één factuur) alleen zichtbaar is voor de gebruikers waartoe die behoort. Er zijn twee veelgebruikte manieren om dit af te dwingen:

Beide kunnen goed worden gedaan. Belangrijk zijn:

• Moet: Als de browser rechtstreeks met de database praat (sommige gehoste databaseproducten staan dat toe), zijn regels op rijniveau ingeschakeld voor elke tabel. Zonder die regels kan iedereen met de publieke sleutel de hele tabel lezen.
• Moet: Queries filteren op de huidige gebruiker of het team, niet op een ID dat de browser meestuurt.
• Zou moeten: Gedeelde gegevens (de projecten van een team) hebben een duidelijke regel voor wie in het team zit, op één plek afgedwongen.

4. Geheimen en API-sleutels

Een API-sleutel is een wachtwoord voor een dienst. Stripe, e-mail- en AI-providers gebruiken er allemaal. Voor achtergrond, zie wat omgevariabelen en geheimen zijn.

• Moet: Sleutels worden opgeslagen in de omgevariabelen of geheimen van het project, nooit in de code geschreven.
• Moet: Sleutels waarmee geld kan worden uitgegeven of privégegevens kunnen worden gelezen, worden alleen op de server gebruikt. Test: open je live site, bekijk de paginabron en de JavaScript-bestanden in de devtools, en zoek naar het begin van je sleutel (bijvoorbeeld sk_). Die mag er niet in staan.
• Moet: Sleutels zijn nooit in de chat, een openbare repository of een screenshot geplakt. Als dat wel is gebeurd, roteer de sleutel dan bij de provider (maak een nieuwe aan en verwijder de oude).
• Zou moeten: Gebruik beperkte of afgebakende sleutels waar de provider die aanbiedt. Stripe raadt bijvoorbeeld beperkte sleutels aan die alleen de rechten hebben die je integratie nodig heeft.
• Zou moeten: Test- en livesleutels zijn gescheiden, en de live-app gebruikt alleen livesleutels als je er klaar voor bent.

Sommige sleutels zijn bedoeld om openbaar te zijn — Stripe’s publishable key (pk_…) of een kaartsleutel die tot je domein is beperkt. De regel gaat over sleutels die kracht geven, niet over elke tekenreeks die op een sleutel lijkt.

5. Invoervalidatie

Alles wat een gebruiker verstuurt — formuliervelden, bestandsuploads, URL-parameters — kan alles zijn, niet alleen wat je formulier toestaat.

• Moet: Validatie gebeurt op de server, niet alleen in de browser. Controles in de browser zijn voor het gemak; iedereen kan ze omzeilen.
• Moet: Databasequeries gebruiken parameters, niet tekst die aan elkaar is geplakt uit gebruikersinvoer (dit voorkomt SQL-injectie). Vraag de AI om dit te bevestigen.
• Moet: Tekst die gebruikers invoeren wordt als tekst weergegeven, niet als HTML uitgevoerd. Test: voer <b>hello</b> in als je naam. Je moet de tags zien, geen vetgedrukte tekst.
• Zou moeten: Bestandsuploads controleren type en grootte, en geüploade bestanden worden niet vanaf het hoofddomein van je app als uitvoerbare pagina’s aangeboden.
• Zou moeten: Fouten die aan gebruikers worden getoond zijn eenvoudig (“Er ging iets mis”); gedetailleerde fouten gaan alleen naar de serverlogs.
• Zou moeten: Webhooks van diensten zoals Stripe verifiëren de handtekening van de provider voordat ze iets doen. Zie wat een webhook is.

Voeg validatie aan de serverkant toe aan elk formulier en elk API-endpoint: verplichte velden, lengtes, formaten en toegestane waarden. Wijs al het andere af met een duidelijke melding. Toon interne foutdetails niet aan gebruikers.

6. Rate limits en misbruik

Een rate limit begrenst hoeveel verzoeken iemand in een periode kan doen. Zonder die limieten kan iedereen de hele dag wachtwoorden raden, je aanmeldformulier overspoelen of je rekening opdrijven bij een betaalde API.

• Moet: Login, aanmelden en wachtwoordreset hebben een rate limit per IP-adres en per account.
• Moet: Alles wat je per aanroep geld kost — AI-modelverzoeken, sms, e-mail — heeft een limiet per gebruiker en vereist login.
• Zou moeten: Openbare formulieren (contact, wachtlijst) hebben spambeveiliging: een rate limit, een verborgen honeypotveld of een CAPTCHA.
• Zou moeten: Stel uitgavenlimieten of meldingen in bij je betaalde providers, zodat een bug of aanvaller geen onbeperkte rekening kan veroorzaken.

7. Afhankelijkheden

Apps zijn gebouwd uit open-sourcepakketten, en pakketten hebben soms bekende kwetsbaarheden.

• Zou moeten: Vraag de AI om te controleren op bekende kwetsbaarheden (voor JavaScript-projecten npm audit of het equivalent voor je pakketbeheerder) en werk getroffen pakketten bij.
• Zou moeten: Verwijder pakketten die de app niet meer gebruikt.
• Zou moeten: Wees voorzichtig met pakketten met zeer weinig gebruikers of namen die lijken op typefouten van populaire pakketten.
• Later: Controleer elke een of twee maanden opnieuw, of zet automatische meldingen aan als je code op GitHub staat.

8. Back-ups en herstel

Beveiliging omvat het kunnen herstellen van fouten — die van jou, van de AI of van een aanvaller.

• Moet: Weet waar je gegevens staan en of ze worden geback-upt. Neem het niet aan; controleer de documentatie van je host.
• Zou moeten: Bewaar je eigen periodieke export van belangrijke gegevens (bijvoorbeeld een CSV-exportfunctie of een databasedump), op een aparte plek.
• Zou moeten: Bewaar je code in versiebeheer, zodat elke versie kan worden hersteld.
• Zou moeten: Destructieve acties (account verwijderen, project verwijderen) vragen om bevestiging, en overweeg een “zachte verwijdering” die een tijdje ongedaan kan worden gemaakt.
• Later: Test een herstel één keer echt. Een back-up die je nooit hebt hersteld is een hoop, geen plan.

9. Voor de lancering

• Moet: De live-site gebruikt overal HTTPS.
• Moet: Voorbeeldgegevens, testaccounts en debugpagina’s uit de ontwikkeling zijn verwijderd.
• Zou moeten: Een privacyverklaring beschrijft welke gegevens je verzamelt en waarom — in veel landen verplicht als je persoonsgegevens verzamelt. Claim geen certificeringen (SOC 2, HIPAA) die je niet hebt.
• Zou moeten: Je hebt een manier waarop mensen je over beveiligingsproblemen kunnen bereiken, en je weet hoe je snel elke sleutel roteert.

Voor een bredere controle vóór de lancering, verder dan beveiliging, zie hoe je een AI-prototype naar productie brengt.

Wanneer je een professionele review nodig hebt

Een checklist vangt veelgemaakte fouten op; hij vervangt geen expert. Overweeg om voor een review te betalen als je kaartnummers zelf verwerkt in plaats van via een gehoste checkout, gezondheids-, financiële of kindergegevens opslaat, verkoopt aan bedrijven die beveiligingsvragenlijsten vragen, of ernstige schade zou lijden bij een lek. Als je code exporteerbaar is, wordt zo’n review veel makkelijker.

Beveiliging bij bouwen op Mythex

Mythex heeft geen beveiligingsscanpaneel, dus de checklist hierboven is het proces dat je moet volgen. Enkele dingen die helpen:

• Projectgeheimen. Sla sleutels op onder projectinstellingen → Secrets, of via de secrets-kaart die de agent in de chat toont, zodat ze uit je code en berichten blijven. Publiceer opnieuw na het wijzigen van een geheim voor een live app.
• Plan- en Ask-modi. Vraag de agent om rechten te controleren zonder iets te bewerken: “Maak in Ask-modus een lijst van elke API-route en welke rechtencontrole die uitvoert.”
• /test laat de agent je preview doorklikken als gebruiker — handig voor de test met twee accounts uit sectie 2.
• Checkpoints laten je een wijziging terugdraaien die iets heeft kapotgemaakt.

Zie Beveiliging voor apps die je bouwt en Omgevariabelen en geheimen in de documentatie. Als je hierna gebruikersaccounts toevoegt, lees dan hoe je login aan je app toevoegt.

Veelgestelde vragen