De veiligheidschecklist voordat je live gaat

Wie kan er bij je project en je diensten?

Iedereen die bij je accounts kan. Een project dat live staat hangt aan een handvol diensten: de host, de databasedienst, de registrar van je domein, je versiebeheer, misschien een betaaldienst en een e-maildienst. Wie op een van die accounts inlogt, kan je project omleiden, leeghalen of overnemen. De eerste controle is dus niet technisch: het is een lijst van elke dienst met een account, en per dienst de vraag of iemand met alleen je wachtwoord binnenkomt.

Zet op elke dienst de tweede stap aan, met een app of een sleutel en niet met sms als dat kan. Gebruik per dienst een eigen wachtwoord uit een wachtwoordbeheerder. Bewaar de herstelcodes die je krijgt op een plek buiten je telefoon, want de dag dat je die kwijt bent is de dag dat je ze nodig hebt. En kijk of er nog oude toegangen zijn: een testaccount, een vriend die even hielp, een koppeling met een tool die je niet meer gebruikt.

Dit is de controle met het grootste effect en de minste techniek. De meeste projecten die overgenomen worden, worden overgenomen via een account, niet via de code.

• Een lijst van elke dienst met een account.
• Tweede stap aan, eigen wachtwoord per dienst, herstelcodes buiten je telefoon.
• Oude toegangen en koppelingen weg.

Staat er iets in de code wat er niet in hoort?

Sleutels, wachtwoorden en verbindingsadressen met een wachtwoord erin. Een AI die snel wil bouwen zet zo'n waarde graag rechtstreeks in de code, omdat het dan werkt. Zodra die code in een repository staat, staat de sleutel er ook, in elke versie, ook nadat je hem hebt weggehaald. En zodra iemand anders de code ziet, heeft hij toegang tot de dienst waar de sleutel voor is.

De plek waar zulke waarden horen is de configuratie van je host, als omgevingsvariabele, en lokaal een bestand dat niet in versiebeheer zit. Je project leest ze bij het starten in plaats van ze te bevatten. Elke host heeft daar een scherm voor en elke bouwtool documenteert hoe je ernaar verwijst.

Controleer het zo: vraag je AI om de code door te zoeken op alles wat op een sleutel of wachtwoord lijkt, en lees de lijst. Staat er iets, haal het weg, zet het op de juiste plek, en vraag daarna bij de dienst een nieuwe sleutel aan, want de oude staat in de geschiedenis en die vergeet niets. Zet dan een regel in je versiebeheer die het configuratiebestand uitsluit, zodat het niet nog een keer gebeurt.

• Sleutels in de configuratie van de host, niet in de code.
• Vind wat er staat, haal het weg, en vraag een nieuwe sleutel aan.
• Sluit het configuratiebestand uit van versiebeheer.

Wat gebeurt er met wat een bezoeker intikt?

Alles wat een bezoeker kan intikken, uploaden of in een adres kan zetten, is een deur. Drie klassieke gaten: een formulier dat zijn invoer zonder controle doorgeeft aan een database, een pagina die de invoer van een ander toont zonder hem onschadelijk te maken, en een upload die elk bestand accepteert. Een AI die op werkend stuurt maakt ze zonder het te zeggen.

De regel is dat je project niets van buiten vertrouwt. Elke waarde wordt gecontroleerd op wat hij moet zijn (een e-mailadres, een getal binnen een bereik, een tekst van hoogstens zoveel tekens) voordat hij iets doet, en alles wat je toont uit invoer van een ander wordt eerst onschadelijk gemaakt. De meeste raamwerken doen dat laatste standaard; controleer of dat in jouw project ook zo is en niet ergens is uitgezet.

Test het zelf. Tik in elk veld iets wat er niet hoort: een stuk code, een heel lange tekst, een negatief getal, een bestand met een andere extensie. Als je project daar netjes op reageert, met een foutmelding en zonder iets te doen, is dat een controle die de meeste prototypes niet halen.

• Niets van buiten vertrouwen; elke waarde controleren voordat hij iets doet.
• Wat je toont uit invoer van een ander: eerst onschadelijk maken.
• Zelf testen met invoer die niet hoort.

Ziet iemand alleen wat van hem is?

Een ingelogde bezoeker mag zijn eigen gegevens zien en veranderen, niet die van een ander. Dat klinkt vanzelfsprekend en het is de fout die het vaakst gevonden wordt in projecten die snel gebouwd zijn. De controle zit dan in het scherm: je ziet alleen je eigen lijst. In de laag eronder zit hij niet, en met een ander nummer in het adres zie je de lijst van een ander. Een AI bouwt het scherm goed en de laag eronder soms niet.

De controle hoort op de plek waar de gegevens vandaan komen: bij de database, in de regels per tabel, of in de laag van je project die met de database praat. Het artikel over de database beschrijft hoe je dat per dienst nakijkt.

Test het met twee accounts. Maak er twee aan, zet in het ene iets, en probeer dat vanuit het andere te bereiken, ook door in het adres een nummer te veranderen. Lukt het, dan is dit het eerste wat je repareert, voordat er een derde account is.

• De controle zit niet in het scherm maar in de laag eronder.
• Regels per tabel bij de database, of in de laag die ermee praat.
• Twee accounts, en proberen bij elkaar te komen.

Is alles versleuteld, en zijn de standaardinstellingen weg?

Alles wat tussen bezoeker en server reist, reist versleuteld, of het reist niet. Je host regelt het certificaat zodra je domein gekoppeld is; jij controleert dat de onversleutelde variant doorstuurt naar de versleutelde, en dat er geen koppeling in je project naar iets onversleutelds wijst. Dat laatste geldt ook voor de verbinding met je database en je andere diensten.

Standaardinstellingen zijn de tweede helft. Een databasedienst met een beheerderswachtwoord dat je nooit veranderde, een beheerpagina die op een voorspelbaar adres staat en voor iedereen open is, een instelling die tijdens het bouwen op alles toestaan stond en daar bleef staan. Loop elke dienst na op wat er standaard aan of open staat, en zet dicht wat je niet gebruikt.

Kijk ook naar wat je project over zichzelf vertelt. Een foutmelding met de volledige technische details, een bestand met versienummers, een pagina die de structuur van je database toont: het zijn kleine dingen die het samen makkelijk maken voor iemand met slechte bedoelingen.

• Alleen versleuteld, ook naar je database en je diensten.
• Standaardwachtwoorden weg, beheerpagina's dicht, bouwinstellingen terug.
• Geen technische details naar buiten.

Wat gebeurt er als het misgaat?

Iets gaat mis. Niet misschien; een keer. De vraag is of je het merkt en of je terug kunt. Merken betekent dat je een melding krijgt als je project niet meer antwoordt of als er ineens heel veel gebeurt; de meeste hosts hebben daar iets voor, en anders bestaan er eenvoudige diensten die je adres elke paar minuten opvragen. Terug kunnen betekent een back-up die je een keer hebt teruggezet en een versie van je code waar je naartoe kunt.

Bedenk ook wat een bezoeker ziet als het misgaat. Een nette foutpagina zonder technische details, en een manier om je te bereiken. Dat is geen beveiliging in de strikte zin, maar het is wel het moment waarop mensen beslissen of ze je vertrouwen.

En schrijf op wat je doet als het misgaat, in vijf regels: waar je kijkt, wie je belt, hoe je terugzet. Niet omdat het ingewikkeld is, maar omdat je het niet meer weet als het zover is.

• Merken: een melding als het project niet antwoordt.
• Terug kunnen: back-up teruggezet, code in versiebeheer.
• Een nette foutpagina en vijf regels voor jezelf.

Zit er een AI in je project, en wat leest die?

Leest je project met een taalmodel teksten van anderen, zoals een e-mail, een webpagina of een geüpload document, en doet het daarna iets? Een antwoord sturen, iets opzoeken, iets aanpassen? Dan is er een deur die de andere zes controles niet dekken. Een tekst kan instructies bevatten die het model opvolgt alsof jij ze gaf. Dat heet prompt-injectie, en het staat bovenaan de lijst van risico's voor toepassingen met taalmodellen van OWASP.

De kern van de verdediging is scheiding: wat de AI leest, mag de AI niet besturen. Externe tekst gaat gemarkeerd het model in, als gegevens en niet als opdracht. Het model krijgt niet meer rechten dan het voor zijn taak nodig heeft. En elke handeling met gevolgen (iets versturen, iets verwijderen, iets betalen) vraagt eerst een mens om akkoord. Het artikel over prompt-injectie gaat hier dieper op in.

Zit er geen AI in je project, dan is deze controle klaar. Zit hij er wel, dan is dit de controle die je niet aan de bouwtool kunt overlaten, want de bouwtool is er zelf een.

• Leest je AI tekst van anderen en doet hij daarna iets: dan geldt dit.
• Externe tekst als gegevens, niet als opdracht; minste rechten; een mens bij gevolgen.
• Geen AI in je project: klaar. Wel: lees het artikel over prompt-injectie.

Bronnen

Nagelopen op 5 september 2026. De zeven controles zijn werkwijze en geen wet; de zevende leunt op de lijst van OWASP.

• OWASP, LLM01:2025 Prompt Injection

Verder lezen

Drie plekken die hierop aansluiten.