Is vibe coding veilig? De echte risico's en wat je controleert voor je publiceert

Vibe coding is veilig voor persoonlijke tools en prototypes, en het kan ook veilig zijn voor echte apps met echte gebruikers, maar alleen als je de controles toevoegt die "beschrijf het gewoon en kijk of het werkt" overslaat. De gevaarlijke problemen zijn van buitenaf niet zichtbaar: gebruikers die elkaars gegevens kunnen openen, geheime sleutels die in de browser staan en publieke formulieren zonder limieten. Deze gids legt uit welke risico's echt problemen veroorzaken, hoe je met geheimen omgaat, hoeveel review je nodig hebt, en een check van 30 minuten die je uitvoert voordat je publiceert.

Voor de volledige technische lijst, zie onze beveiligingschecklist voor AI-gebouwde apps. Deze pagina is de kortere, praktische versie voor mensen die geen code lezen.

Waarom vibe coding eigen risico's heeft

Als je vibe codet, beoordeel je de app door hem te gebruiken. Dat vangt kapotte knoppen en lelijke lay-outs. Het vangt niet de problemen die alleen verschijnen wanneer iemand de app anders gebruikt dan jij: een vreemde, een bot of een nieuwsgierige gebruiker die een webadres aanpast.

AI-modellen schrijven plausibele code, en het meeste ervan is prima. Maar ze optimaliseren voor wat je vroeg, zoals "laat het dashboard mijn projecten tonen", en voegen misschien de bescherming niet toe die je niet vroeg, zoals "en niet die van anderen". De oplossing is niet stoppen met vibe coden. Het is de bescherming expliciet vragen en die daarna testen.

Hoe riskant is je app? Een korte schaal

Wees eerlijk over in welke rij je zit. Veel apps beginnen in de eerste rij en schuiven naar de derde zonder dat iemand dat ooit heeft besloten.

De risico's die echt problemen veroorzaken

1. Gebruikers kunnen elkaars gegevens zien

Dit is het meest voorkomende ernstige probleem in AI-gebouwde apps. De pagina toont elke gebruiker alleen zijn eigen records, dus het lijkt goed te werken. Maar de server geeft elk record terug als iemand het ID in de adresbalk of in een verzoek aanpast. Omdat je altijd test als jezelf, zie je het nooit.

Zo controleer je het: maak twee accounts aan. Log in als gebruiker A, open een record van A en noteer het adres. Log in als gebruiker B in een privévenster en plak dat adres. Je zou "niet gevonden" moeten zien, nooit de gegevens van A.

Prompt:

Controleer elk serverendpoint dat gebruikersgegevens leest, wijzigt of verwijdert. Elk moet bevestigen dat de ingelogde gebruiker toegang heeft tot dat specifieke record. Geef een lijst van de endpoints, beschrijf hoe elk ze controleert, en repareer de endpoints die dat niet doen.

2. Geheimen op de verkeerde plek

Een geheim is alles wat toegang verleent: een API-sleutel voor een AI- of e-maildienst, een databasewachtwoord, de geheime sleutel van een betalingsprovider. Staat die in code die in de browser draait, dan kan iedereen de ontwikkelaarstools openen en hem kopiëren. Wordt hij in een openbare repository vastgelegd, dan vinden bots hem binnen een paar uur.

Zo controleer je het: vraag het de AI.

Geef elke API-sleutel, token en elk wachtwoord die deze app gebruikt. Vertel per stuk waar het wordt bewaard en of het ooit naar de browser wordt gestuurd. Verplaats alles dat in de code of in de frontend staat naar geheimen aan de serverkant.

3. Publieke formulieren en endpoints zonder limieten

Contactformulieren, aanmeldingen en AI-functies worden door bots gevonden. Zonder limieten krijg je spam, nepaccounts of een grote rekening, omdat een AI-API duizenden keren wordt aangeroepen.

Prompt:

Voeg rate limits toe aan aanmelden, inloggen, het contactformulier en elk endpoint dat een AI-dienst aanroept. Voeg een honeypot-veld toe aan publieke formulieren. Vertel welke limieten je hebt gekozen.

4. Vertrouwen op de browser

Alles wat de browser beslist, kan de gebruiker wijzigen: prijzen, kortingen, quizantwoorden, vlaggen als "is admin". Regels die ertoe doen, moeten aan de serverkant worden afgedwongen.

Prompt:

Zoek elke plek waar de browser iets beslist dat de server zou moeten beslissen: prijzen, totalen, rechten, rollen, scores. Verplaats die controles naar de server.

5. Geen weg terug

Een slechte wijziging of een kwaadwillende gebruiker kan gegevens verwijderen. Zonder back-up en zonder manier om terug te draaien wordt een kleine fout een blijvende fout. Zorg dat je tool checkpoints heeft voor de code en back-ups voor de database. Zie hoe maak je een back-up van de database van je app.

Geheimen op de juiste manier beheren

Geheimen veroorzaken meer vermijdbare schade dan iets anders, dus hier staan de regels op een rij:

• Plak nooit een echte sleutel in de chat. Chats worden opgeslagen, gedeeld en in screenshots vastgelegd. Zet sleutels in de geheimen of omgevingsvariabelen van je tool. (Wat zijn omgevingsvariabelen en geheimen.)
• Roep betaalde diensten aan vanaf de server. De browser vraagt je server; je server roept de AI- of betalingsdienst aan met de sleutel.
• Gebruik aparte sleutels voor testen en echt gebruik, zodat een gelekte testsleutel geen echt geld kan raken.
• Stel uitgavenlimieten in in de dashboards van AI- en e-mailproviders.
• Vervang een sleutel direct als je denkt dat die is gelekt. Maak een nieuwe aan, werk het geheim bij en verwijder daarna de oude.

Op Mythex staan geheimen in de projectinstellingen, buiten de code, en kan de agent ze gebruiken zonder dat de waarden in de chat verschijnen. Onze gids over API-sleutels veilig bewaren behandelt meer providers.

Hoeveel codereview heb je nodig?

Bij vibe coding lees je niet elke regel. Dat hoeft ook niet. Maar sommige regels moet iemand wel bekijken.

• Persoonlijke tools: niets extra's bovenop de controles hierboven.
• Apps met gebruikersaccounts: controleer hoe inloggen en gegevenstoegang werken. Dat kun je doen door de AI te vragen het in gewone woorden uit te leggen, en te checken of de uitleg overeenkomt met wat jij verwacht.
• Apps met betalingen of gevoelige gegevens: laat een ontwikkelaar kijken naar authenticatie, rechten, betalingsafhandeling en alles wat persoonsgegevens opslaat. Het kost een paar uur van hun tijd, geen herschrijving.

Een bruikbare prompt, ook zonder ontwikkelaar:

Leg in gewone woorden uit hoe deze app bepaalt wie een gebruiker is en wat die mag zien. Wijs de bestanden aan. Geef daarna een lijst van wat een beveiligingsreviewer zou moeten bekijken.

Onze gids over hoe je AI-gegenereerde code reviewt legt uit waar reviewers naar kijken, en die kun je aan degene geven die de review doet. Als je tool het exporteren van code of synchroniseren met GitHub toestaat, is zo'n review eenvoudig te regelen; op Mythex zijn beide onderdeel van Pro.

De publicatiecheck van 30 minuten

Voer dit uit voordat je de link met iemand buiten je eigen kring deelt.

Toegang (10 minuten)

1. Twee accounts, twee browsers: kan B de records van A openen via de URL? Dat mag niet.
2. Log uit en bezoek het adres van elke pagina rechtstreeks. Privépagina's moeten je naar de inlogpagina sturen.
3. Open als gewone gebruiker de admin-adressen. Die moeten worden geweigerd.

Geheimen (5 minuten)

1. Vraag de AI met de prompt hierboven waar elke sleutel staat.
2. Open de app, bekijk de bron van de pagina en zoek naar "key", "secret" en "token".

Formulieren en misbruik (5 minuten)

1. Verstuur elk formulier leeg, met erg lange tekst, en tweemaal snel achter elkaar.
2. Controleer of er rate limits zijn voor aanmelden, inloggen en elke AI-functie.

Gegevens en herstel (5 minuten)

1. Weet waar de gegevens staan en hoe je ze herstelt.
2. Controleer of je de code kunt terugzetten naar een eerdere werkende versie.

Juridisch en basis (5 minuten)

1. Verzamel je persoonsgegevens? Voeg dan een privacyverklaring toe en leg uit wat je verzamelt. Zie hoe schrijf je algemene voorwaarden en een privacyverklaring.
2. Controleer of de gepubliceerde app HTTPS gebruikt. De meeste bouwtools, Mythex inbegrepen, regelen dat voor je.

Als alles slaagt, sta je er goed voor bij een vroege lancering. Herhaal stap 1 tot en met 5 na elke grote wijziging aan inloggen, rollen of gegevens.

Wat vibe coding-platforms wel en niet beschermen

Een goed platform regelt veel van de infrastructuur: HTTPS, geïsoleerde werkruimten, een database per project, opslag van geheimen, back-ups en terugdraaien. Mythex geeft elk project een eigen privéwerkruimte en database, houdt geheimen buiten de code en slaat na elke geslaagde wijziging een checkpoint op, zodat je die kunt ongedaan maken.

Wat geen platform kan, is de regels van jouw app kennen. Alleen jij weet dat klanten elkaars facturen niet mogen zien, of dat een kortingscode maar één keer mag werken. Die regels moeten in je prompts staan en door je tests worden bevestigd.

Het korte antwoord

Vibe coding is zo veilig als de controles die je toevoegt. Voor een persoonlijke tool houd je sleutels uit de code en geniet je ervan. Voor alles met gegevens van andere mensen voer je de check van 30 minuten hierboven uit vóór elke lancering, en laat je een ontwikkelaar naar betalingen en gevoelige gegevens kijken. Om deze risico's in echte projecten te zien, lees je onze voorbeelden van vibe coding; om vanaf het begin met deze controles te bouwen, volg je hoe bouw je een app met vibe coding.

Veelgestelde vragen