Je wilt het telefoonnummer op je website aanpassen. Simpel, toch? Eventjes inloggen, nummertje wijzigen, klaar.
Maar nee. Je kunt het niet zelf. Het nummer staat “hardcoded” in de broncode. Je moet je developer bellen. Die stuurt een factuur voor een kwartier werk. Voor het wijzigen van een telefoonnummer.
Herkenbaar? Dan heb je te maken met hardcoded waarden. En dat is op z’n best irritant — en op z’n slechtst een serieus veiligheidsrisico.
Hardcoded in gewone taal
Hardcoded betekent dat een waarde letterlijk in de code is getypt. Niet op een plek waar je het makkelijk kunt aanpassen, maar midden in de programmacode zelf.
Denk aan het verschil tussen een krijtbord en een gegraveerde steen. Op een krijtbord pas je de tekst in drie seconden aan. Op een gegraveerde steen? Dan heb je een beeldhouwer nodig.
Hardcoded waarden zijn gegraveerde stenen. Voorbeelden:
- Je bedrijfsnaam staat letterlijk op 23 plekken in de code in plaats van op één centrale plek
- Het e-mailadres voor contactformulieren zit vastgebakken in de broncode
- Prijzen staan niet in een database maar direct in de pagina
- Een API-sleutel (een soort wachtwoord voor koppelingen) staat gewoon leesbaar in de code
Die eerste drie zijn vervelend. Die laatste is gevaarlijk.
Waarom developers het doen
Eerlijk is eerlijk: soms is het luiheid. Maar vaker is het haast. Een waarde hardcoden is sneller dan het netjes opzetten via een database of configuratiebestand. En als de deadline dringt, wint snelheid het van netheid.
Het probleem: die “tijdelijke oplossing” wordt permanent. Niemand komt erop terug. En twee jaar later heeft niemand meer een idee waar die waarde überhaupt staat — tot het misgaat.
De vibe coding-explosie maakt het erger
En nu wordt het serieus. Want er is een trend die dit probleem flink verergert: vibe coding.
Vibe coding is de term voor software bouwen met AI-tools zoals ChatGPT, Copilot of Cursor. Je beschrijft wat je wilt in gewone taal, de AI genereert de code, en je plakt het in je project. Klinkt handig. Is het ook — als je weet wat je doet.
Maar steeds meer mensen zonder technische achtergrond gebruiken AI om complete applicaties te bouwen. En die AI maakt het ze wel heel makkelijk om hardcoded waarden te introduceren zonder het te beseffen.
Wat er in de praktijk gebeurt:
Je vraagt een AI: “Maak een contactformulier dat e-mails stuurt naar info@mijnbedrijf.nl.” De AI levert werkende code op. Mooi. Maar dat e-mailadres? Staat hardcoded in de broncode. En die broncode staat op GitHub. Openbaar.
Of erger: je vraagt de AI om een koppeling te maken met een betaalsysteem. De AI vraagt om je API-sleutel. Je plakt die erin. De code werkt. Maar die sleutel staat nu in je code. En als die code ergens online staat — op GitHub, in een publieke repository, of zelfs in een slecht beveiligde map op je server — dan kan iedereen erbij.
En “iedereen” betekent ook hackers.
Waarom dit een veiligheidsprobleem is
Dit is geen theoretisch risico. Er zijn geautomatiseerde bots die het internet afstruinen op zoek naar hardcoded API-sleutels, wachtwoorden en database-credentials in openbare code. 24 uur per dag, 7 dagen per week.
Wat er kan gebeuren als ze iets vinden:
Financiële schade — Een gelekte API-sleutel van een cloudservice kan ertoe leiden dat iemand anders op jouw kosten servers opstart. Er zijn gevallen bekend van bedrijven die binnen een weekend duizenden euro’s kwijt waren aan ongeautoriseerd cloudgebruik.
Datadiefstal — Hardcoded database-wachtwoorden geven directe toegang tot je klantgegevens. Namen, adressen, e-mails, bestelhistorie — alles wat onder de AVG valt. Een datalek kost je niet alleen geld aan boetes, maar ook het vertrouwen van je klanten.
Misbruik van koppelingen — Een gelekte betalings-API-sleutel kan betekenen dat iemand transacties uitvoert op jouw account. Of dat je mailsysteem wordt misbruikt om spam te versturen. Op jouw naam.
Toegang tot je hele systeem — Eén gelekt wachtwoord kan de deur openzetten naar alles. Hackers gebruiken één zwak punt om zich een weg naar binnen te werken. Een hardcoded wachtwoord is niet zomaar een zwak punt — het is een open deur met een welkomstmat.
De kosten lopen snel op
Laten we het even concreet maken. Een beveiligingsincident door hardcoded credentials kan je het volgende kosten:
- Direct financieel verlies door misbruik van diensten en koppelingen
- Juridische kosten als klantdata is gelekt (AVG-boetes kunnen oplopen tot 4% van je jaaromzet)
- Reputatieschade die je niet in euro’s kunt uitdrukken maar die je wél klanten kost
- Herstelkosten om het lek te dichten, wachtwoorden te roteren en systemen opnieuw te beveiligen
- Downtime terwijl je alles op slot gooit en uitzoekt wat er precies is gebeurd
En dan spreken we nog niet over de uren die je erin steekt. De stress. De klanten die je moet bellen om te vertellen dat hun gegevens mogelijk op straat liggen.
Dat alles omdat een wachtwoord in de code stond in plaats van in een beveiligd configuratiebestand.
Hoe het wél moet
Het goede nieuws: hardcoded waarden voorkomen is niet ingewikkeld. Het vereist alleen dat je het vanaf het begin goed inricht:
Configuratiebestanden en environment variables — Gevoelige waarden zoals API-sleutels en wachtwoorden horen in een apart configuratiebestand dat niet in je broncode zit. In Laravel (het framework waar wij mee werken) gebruik je een .env-bestand. Dat bestand staat nooit in je repository en is alleen toegankelijk op de server zelf.
Een CMS of beheeromgeving — Waarden die je regelmatig wilt wijzigen — telefoonnummers, e-mailadressen, prijzen, openingstijden — horen in een beheerpaneel. Zodat jij ze zelf kunt aanpassen. Zonder developer. Zonder factuur.
Secrets management — Voor gevoelige koppelingen gebruik je een secrets manager. Dat is een kluis voor je digitale sleutels. Alleen de applicatie zelf kan erbij, en zelfs dan alleen op het moment dat het nodig is.
Code reviews — Vier ogen zien meer dan twee. Een ervaren developer checkt de code voordat het live gaat. Niet om te zeuren, maar om precies dit soort fouten te vangen.
Vibe coding is niet per se fout — maar wees eerlijk
Laat ons duidelijk zijn: AI-tools zijn fantastisch om sneller te werken. Wij gebruiken ze zelf ook. Het probleem is niet de AI — het probleem is wanneer niemand de output controleert.
AI-gegenereerde code is een eerste versie. Een draft. Het is alsof je een stagiair een klusje geeft: het resultaat kan prima zijn, maar je controleert het wel even voordat het de deur uit gaat.
Als je vibe coding gebruikt om een applicatie te bouwen waar klantdata, betalingen of bedrijfsprocessen doorheen lopen, laat dan alles reviewen door iemand die weet waar die naar kijkt. De kosten van die review zijn een fractie van de kosten van een beveiligingsincident.
Checklist: staat er iets hardcoded in jouw software?
Stel jezelf deze vragen:
- Kun je je telefoonnummer, e-mailadres en openingstijden zelf aanpassen op je website? Zo nee: waarschijnlijk hardcoded.
- Staat je code op GitHub of een andere openbare plek? Zo ja: controleer of er geen wachtwoorden of API-sleutels in staan.
- Heeft iemand met AI een applicatie of koppeling gebouwd zonder technische review? Zo ja: laat het nakijken.
- Weet je waar je API-sleutels opgeslagen zijn? Zo nee: zoek het uit. Vandaag nog.
De samenvatting
Hardcoded waarden zijn op z’n best onhandig (je kunt niks zelf aanpassen) en op z’n slechtst gevaarlijk (hackers bij je data). Met de opkomst van vibe coding wordt het probleem groter, omdat meer mensen code produceren zonder de beveiligingsrisico’s te overzien.
De oplossing is niet stoppen met AI of stoppen met bouwen. De oplossing is zorgen dat iemand met verstand van zaken meekijkt. Dat gevoelige waarden op de juiste plek staan. En dat je software gebouwd is om beheerd te worden — niet om te hopen dat het goed gaat.
Twijfel je of jouw website of applicatie hardcoded risico’s bevat? Stuur ons een berichtje — we kijken er graag even naar. Liever nu een uurtje checken dan later een weekend paniek.
