Hoe je een beveiligingsaudit uitvoert op een AI-gegenereerde app

AI-appbouwers kunnen u in enkele minuten van een prompt naar een werkend product brengen, maar snelheid is niet gelijk aan veiligheid. Gegenereerde code compileert en demonstreert goed, maar kan nog steeds onveilige standaardinstellingen, te ruime toegangsregels of vergeten geheimen bevatten. Dit is een praktische, defensieve walkthrough voor oprichters en ontwikkelaars die een AI-gegenereerde app willen controleren voordat deze echte gebruikers tegenkomt.

Waarom AI-gegenereerde code een beveiligingsbeoordeling nodig heeft

Grote taalmodellen leren van enorme openbare codebases — inclusief voorbeelden die zijn geschreven voor duidelijkheid, niet voor productieverharding. Ze hebben de neiging om de happy path: code die werkt wanneer invoer goed gevormd is en aanroepers eerlijk zijn. Beveiligingscontroles zoals autorisatiecontroles, invoervalidatie en snelheidsbeperking zijn precies de onderdelen die gemakkelijk kunnen worden weggelaten omdat de app nog steeds werkt zonder hen.

Een AI-bouwer heeft ook geen duurzaam model van uw bedreigingsoppervlak. Het weet niet welke velden gevoelig zijn, welke eindpunten alleen voor beheerders moeten zijn, of welke derde partij u vertrouwt. Die context moet u zelf leveren en verifiëren. Behandel gegenereerde code zoals u een bijdrage van een snelle maar onbekende aannemer zou behandelen: nuttig, maar gecontroleerd voordat het wordt uitgebracht. Als u nog steeds de algehele gereedheid afweegt, zie dan zijn AI-gegenereerde apps productieklaar.

Stel uw audit in: tools en scope

Combineer geautomatiseerd scannen met handmatige beoordeling. Automatisering vangt bekende slechte patronen op schaal; mensen vangen gebroken bedrijfslogica die scanners niet kunnen begrijpen.

• Afhankelijkheidsscanners — npm audit, pip-audit, or an SCA tool to flag vulnerable packages.
• SAST (statische analyse) — tools zoals Semgrep of CodeQL om injectie, zwakke crypto en onveilige sinks aan het licht te brengen.
• Header- en CSP-checkers — een HTTP-headeranalysator om transport- en browserbeschermingen te bevestigen.
• Geheimscanners — Gitleaks of TruffleHog om sleutels te vangen die in de repo zijn gezet.

Beperk de audit tot de gehele aanvraaglevenscyclus: wie er belt, wat ze mogen doen, welke gegevens binnenkomen en welke vertrekken. De onderstaande categorieën volgen veelgebruikte OWASP-stijl risicogebieden.

Authenticatie, sessies en toegangscontrole

Authenticatie beantwoordt wie u bent; autorisatie beantwoordt wat u mag doen. AI-gegenereerde apps krijgen vaak de eerste goed en de tweede fout.

Wat te controleren

• Wachtwoorden worden gehasht met een sterk adaptief algoritme (bcrypt, scrypt of Argon2) — nooit platte tekst of snelle hashes zoals MD5.
• Sessietokens zijn willekeurig, verlopen en roteren bij inloggen; cookies gebruiken HttpOnly, Secure, en SameSite.
• Elk gevoelig eindpunt controleert autorisatie op de server, niet alleen door UI-knoppen te verbergen.

Test op gebroken toegangscontrole (IDOR)

Insecure Direct Object References are the classic AI-generated flaw: an endpoint like /api/orders/1043 returns the record without confirming it belongs to the caller. Manually change the identifier to another user's resource and confirm the server responds with 403 of 404, niet de gegevens. Dwing eigendoms- en rolcontroles af in een enkele, hergebruikte autorisatielaag in plaats van ad-hoc voorwaardelijke controles te verspreiden.

Invoervalidatie en injectie

Vertrouw nooit invoer — inclusief queryparameters, headers, JSON-body’s en bestandsnamen.

• SQL-injectie — bevestig dat de app geparametriseerde query’s of een ORM gebruikt, en dat er geen query wordt opgebouwd door gebruikersstrings samen te voegen.
• Cross-site scripting (XSS) — user content must be output-encoded; watch for dangerous sinks like innerHTML or dangerouslySetInnerHTML.
• Command- en template-injectie — onvertrouwde waarden mogen nooit een shell of template-evaluator bereiken.

Valideer op basis van een toegestane lijst: definieer wat een veld zou moeten bevatten (type, lengte, formaat) en wijs de rest af. Dit verkleint het aanvalsoppervlak veel betrouwbaarder dan het proberen te blokkeren van bekende slechte patronen.

Beheer van geheimen en inloggegevens

Gegenereerde startcode hardcodeert vaak een API-sleutel of database-URL om de demo te laten draaien. Dat is prima in een sandbox en gevaarlijk in een repository.

• Doorzoek de codebase op sleutels, tokens en verbindingsstrings; verplaats ze allemaal naar omgevingsvariabelen of een geheimenbeheerder.
• Confirm .env files are in .gitignore and were never committed — run a secret scanner over full git history.
• Toepassen minimale rechten voor inloggegevens: API-sleutels en databaserollen met een beperkt bereik die alleen kunnen doen wat de app nodig heeft.

Als een geheim ooit in versiebeheer is beland, roteer het dan. Het verwijderen van de regel maakt de blootstelling niet ongedaan. Of je deze code kunt verplaatsen hangt af van je platform — zie bezit je de code.

Afhankelijkheden en de toeleveringsketen

Het grootste deel van een moderne app is code die je niet hebt geschreven. AI-bouwers kunnen verouderde versies vastzetten of pakketten met bekende kwetsbaarheden binnenhalen.

1. Voer een afhankelijkheidsscanner uit en los adviezen met hoge ernst op vóór de lancering.
2. Verwijder pakketten die je niet echt gebruikt — elk ervan is een aanvalsoppervlak.
3. Let op typosquatting: een voorgestelde pakketnaam die dicht bij, maar niet, de populaire naam ligt.
4. Commit een lockbestand zodat builds reproduceerbaar zijn, en scan opnieuw volgens een schema.

Transport, headers en misbruikbeveiliging

Deze zijn goedkoop toe te voegen en ontbreken vaak in gegenereerde uitvoer.

Transportbeveiliging

• Serveer alles via HTTPS; stuur HTTP om en schakel HSTS.
• Controleer TLS-certificaten bij uitgaande oproepen — schakel verificatie niet uit om "het te laten werken."

Beveiligingsheaders en CSP

Voeg een Content-Security-Policy, plus X-Content-Type-Options, Referrer-Policy, and frame protections. Run your deployed URL through a header checker and tighten the CSP until only trusted sources are allowed.

Snelheidsbeperking en bestandsuploads

• Beperk de snelheid van authenticatie en dure eindpunten om brute-force en misbruik te dempen; voeg vergrendeling of backoff toe bij herhaalde mislukkingen.
• Valideer bij uploads het type en de grootte, sla bestanden op buiten de webroot, genereer server-side namen en voer nooit geüploade inhoud uit.

Gegevensblootstelling, PII en veilige logging

Audit wat de app retourneert en wat hij registreert. API-reacties delen vaak te veel — ze sturen een volledig gebruikersobject met wachtwoordhashes of interne vlaggen terwijl de client slechts drie velden nodig heeft. Retourneer expliciete, minimale DTO's.

Logs zijn een veelvoorkomend lekpunt. Bevestig dat tokens, wachtwoorden, volledige kaartnummers en persoonlijke gegevens worden geredigeerd voordat ze in logs of foutvolgers terechtkomen. Ga om met persoonlijke gegevens (PII) volgens het privacyregime waaronder je opereert en versleutel gevoelige gegevens in rust. Los de generatiepatronen op in plaats van het individuele lek, zodat het probleem niet opnieuw optreedt bij de volgende build.

Een beveiligingsaudit is geen eenmalige poort, maar een gewoonte die je herhaalt bij elke betekenisvolle wijziging. Combineer deze review met een breder implementatie plan, begrijp de beperkingen van de tools die je gebruikt, en je kunt snel bewegen zonder de gegevens van je gebruikers als onderpand te verzenden. Om te zien hoe LogicMint past in die workflow, verken de prijzen opties.