Top 10 kwetsbaarheden in code om op te letten in 2026

De meeste datalekken beginnen nog steeds met een handvol bekende soorten bugs. Frameworks zijn veiliger geworden, maar de fouten zijn verhuisd: naar API-handlers, achtergrondtaken, infrastructuurcode en de lijm tussen services. Dit is de lijst die we bij elke audit als eerste nalopen, met de CWE die je terugziet in een rapport van CodeAuditAgent.

1. Gebrekkige toegangscontrole (CWE-639, CWE-862)

Verreweg de meest voorkomende ernstige bevinding: een endpoint laadt een record op ID zonder te controleren of het bij de aanroeper hoort. Authenticatie vertelt je wie iemand is; autorisatie moet bij elke afzonderlijke query plaatsvinden.

// Scope every lookup to the owner
const invoice = await db.invoice.findFirst({
  where: { id, userId: session.user.id },
});

2. Injectie (CWE-89, CWE-78)

Met strings opgebouwde SQL, shellcommando's en template-expressies zie je nog overal, meestal in die ene query die iemand voor de performance met de hand schreef. Parametriseer de query of geef argumenten mee als array; plak nooit invoer aan elkaar.

3. Hardcoded secrets (CWE-798)

API-sleutels die in de repository zijn gecommit, testtokens die live bleken te zijn, private keys in configuratiebestanden. Verplaats ze naar omgevingsvariabelen of een secret manager, en roteer alles wat ooit is gecommit: de regel verwijderen verwijdert de geschiedenis niet.

4. Server-side request forgery (CWE-918)

Elke functie die een door de gebruiker opgegeven URL ophaalt, zoals webhooks, linkvoorbeelden of imports, kan worden gericht op je interne netwerk of het metadata-endpoint van je cloud. Werk met een allowlist van hosts, resolve en controleer het IP-adres, en blokkeer private ranges.

5. Cross-site scripting (CWE-79)

Moderne frameworks escapen standaard, dus XSS verstopt zich nu in de nooduitgangen: props met ruwe HTML, markdown-renderers en URL's in href-attributen. Sanitize HTML met een beproefde library en weiger javascript:-URL's.

6. Onveilige deserialisatie en eval (CWE-502, CWE-95)

Pickle, YAML load, Java object streams en dynamische eval maken van data code. Gebruik in plaats daarvan veilige loaders en JSON die tegen een schema wordt gevalideerd.

7. Zwakke cryptografie (CWE-327, CWE-330)

MD5 of SHA-1 voor wachtwoorden, statische IV's, Math.random() voor tokens. Gebruik een wachtwoordhash die voor dat doel is ontworpen (Argon2id, bcrypt, scrypt) en een cryptografisch veilige bron van willekeur.

8. Open redirects (CWE-601)

Een next- of returnTo-parameter die elke URL accepteert, maakt van je domein een vertrouwde springplank voor phishing. Accepteer alleen relatieve paden binnen dezelfde origin.

9. Ontbrekende rate limiting (CWE-307, CWE-770)

Inloggen, wachtwoordherstel, OTP en elk endpoint dat je geld kost (e-mail, sms, AI-aanroepen) hebben limieten per gebruiker en per IP nodig. Zonder die limieten zijn brute-force-aanvallen en aanvallen die je rekening laten exploderen kinderspel.

10. Onveilige configuratie (CWE-16)

Wildcard-CORS met credentials, debugmodus in productie, uitgebreide stacktraces, te ruime bucket policies. Tijdens een code review lijken dit zelden bugs, omdat ze in configuratie staan, en precies daarom moeten ze als code worden gereviewd.

Zo gebruik je deze lijst

• Controleer klasse 1 tot en met 3 bij elke pull request; die hebben de grootste impact en worden het makkelijkst over het hoofd gezien.
• Behandel infrastructuur- en CI-configuratie als code die gereviewd wordt.
• Leg bij elke bevinding de CWE vast, zodat je fixes kunt volgen en trends kunt meten.