Security is geen specialisme meer dat je aan een apart team uitbesteedt. In 2026 is secure coding een basisvaardigheid voor elke professionele ontwikkelaar. De aanvallen worden geavanceerder, de regelgeving strenger, en de kosten van een breach hoger dan ooit. Dit zijn de practices die je vandaag moet beheersen.

Injection-preventie: de basis die nog steeds fout gaat

SQL injection bestaat al meer dan twintig jaar, en toch duikt het nog regelmatig op in security audits. De oorzaak is bijna altijd dezelfde: string-concatenatie in queries. De oplossing is even oud als het probleem: parameterized queries of een ORM die dit voor je afhandelt.

Maar injection gaat verder dan SQL. In 2026 zien we steeds vaker:

  • NoSQL injection in MongoDB en vergelijkbare databases
  • LDAP injection bij integraties met Active Directory
  • Template injection in server-side rendering frameworks
  • Command injection wanneer user input in shell-commando's terechtkomt

De regel is universeel: vertrouw nooit user input. Valideer, sanitize, en gebruik altijd de veilige API's die je framework biedt. In .NET betekent dat: gebruik Entity Framework of Dapper met parameters, nooit string.Format of interpolatie voor queries.

Authenticatie en autorisatie: moderne patronen

Authenticatie (wie ben je?) en autorisatie (wat mag je?) zijn fundamenteel anders dan vijf jaar geleden. De belangrijkste verschuivingen:

  • Passwordless authenticatie wint terrein - passkeys, FIDO2, en magic links vervangen wachtwoorden
  • OAuth 2.1 consolideert best practices en elimineert onveilige flows (implicit grant is dood)
  • Token-based autorisatie met korte levensduur - access tokens van minuten, niet uren
  • Policy-based autorisatie in plaats van role-based - fijnmaziger en flexibeler

De meest voorkomende fout die we in code reviews tegenkomen: autorisatiechecks alleen in de UI. Als je API-endpoint niet zelfstandig verifieert of de huidige gebruiker deze actie mag uitvoeren, heb je een kwetsbaarheid. Autorisatie hoort in elke laag - van controller tot domeinservice.

Dependency scanning: je supply chain bewaken

Moderne applicaties bestaan voor 70-80% uit third-party code. NuGet-packages, npm-modules, container base images - elke dependency is een potentieel aanvalsoppervlak. In 2026 is dependency scanning net zo vanzelfsprekend als unit tests.

Wat je minimaal moet doen:

  • Automatische scanning in je CI/CD-pipeline met tools als Dependabot, Snyk of OWASP Dependency-Check
  • Geen floating versions in productie - pin je dependencies op exacte versies
  • Regelmatige updates - verouderde packages zijn de makkelijkste weg naar binnen
  • License compliance - niet security-gerelateerd, maar wel een risico dat je wilt beheersen

Het doel is niet nul kwetsbaarheden - dat is onrealistisch. Het doel is bewuste, getriagede risicoacceptatie. Je weet welke kwetsbaarheden er zijn, je hebt beoordeeld of ze relevant zijn voor jouw context, en je hebt een plan.

Code review als security-maatregel

Code reviews zijn je laatste verdedigingslinie voor code productie bereikt. Maar een effectieve security-review vereist focus. Waar moet je op letten?

  • Input handling - wordt alle externe input gevalideerd en gesanitized?
  • Foutafhandeling - lekken error messages interne details naar de gebruiker?
  • Logging - worden gevoelige gegevens (tokens, wachtwoorden, BSN) niet gelogd?
  • Cryptografie - worden bewezen algoritmen gebruikt, geen eigen implementaties?
  • Concurrency - zijn er race conditions die tot privilege escalation kunnen leiden?

Maak een security checklist onderdeel van je review-template. Niet als bureaucratisch afvinklijstje, maar als geheugensteun voor de reviewer. De meest effectieve reviews die we zien, combineren geautomatiseerde tooling (SAST, linters) met menselijke beoordeling van de logica.

Secrets in code: zero tolerance

Dit punt kan niet vaak genoeg herhaald worden: geen secrets in je broncode. Geen API-keys, geen connection strings, geen certificaten. Gebruik:

  • Environment variables of platform-specifieke secret stores (Azure Key Vault, AWS Secrets Manager)
  • Managed identities waar mogelijk - geen credentials nodig
  • Pre-commit hooks die scannen op patronen die op secrets lijken (tools als gitleaks of truffleHog)

Een secret dat ooit in je git-historie is beland, is gecompromitteerd. Roteer het onmiddellijk. Git history herschrijven is niet voldoende - ga ervan uit dat het gelekt is.

Security als gewoonte

Secure coding is geen fase in je ontwikkelproces. Het is een gewoonte - iets dat je automatisch doet bij elke regel code die je schrijft. Investeer in training, deel kennis in je team, en maak security-tooling onderdeel van je dagelijkse workflow.

Bij NForza bouwen we software waar organisaties op vertrouwen. Dat vertrouwen begint bij code die veilig is by design - niet als afterthought.