SQL injectie voorkom je door nooit gebruikersinvoer direct in een databasequery te plaatsen. Gebruik prepared statements met parameters, valideer en filter alle input, beperk databaserechten tot het minimum en houd je software up-to-date. Hieronder lees je hoe je dit concreet toepast in je eigen projecten, met voorbeelden die je direct kunt gebruiken.
Wat is SQL injectie precies
SQL injectie ontstaat wanneer een aanvaller via een invoerveld, zoals een zoekbalk of inlogformulier, eigen SQL-code in een query weet te smokkelen. Als die invoer ongefilterd in de query wordt geplakt, kan de database onbedoelde opdrachten uitvoeren. Denk aan het omzeilen van een login, het uitlezen van klantgegevens of zelfs het verwijderen van tabellen.
Het probleem zit niet in de database zelf, maar in de manier waarop de applicatie queries opbouwt. Zodra je strings aan elkaar plakt om een query te vormen, loop je risico. Dit geldt voor elke taal: PHP, Python, Node.js of Java.
Prepared statements correct gebruiken
De belangrijkste maatregel tegen SQL injectie is het gebruik van prepared statements (ook wel parameterized queries genoemd). Hierbij stuur je de structuur van de query en de gebruikersinvoer apart naar de database, waardoor invoer nooit als uitvoerbare code wordt geïnterpreteerd.
In PHP met PDO ziet dit er bijvoorbeeld zo uit: je schrijft de query met plaatsvervangers zoals ? of :naam, en bindt daarna de waarden apart. De database weet dan dat alles wat binnenkomt puur data is, nooit code. Dit werkt hetzelfde in andere talen: Python’s psycopg2 en sqlite3, Node’s mysql2 en Java’s PreparedStatement bieden allemaal deze functionaliteit.
Extra beveiligingslagen
Prepared statements zijn de kern, maar een goede beveiliging bestaat uit meerdere lagen. Zo voorkom je dat één gemiste plek direct tot een lek leidt.
Valideer en filter input
Controleer of invoer voldoet aan het verwachte formaat, bijvoorbeeld een e-mailadres of een getal. Wijs onverwachte tekens af voordat ze de applicatie bereiken.
Beperk databaserechten
Geef de databasegebruiker van je applicatie alleen de rechten die nodig zijn. Een webformulier hoeft geen tabellen te kunnen verwijderen.
Gebruik een ORM of query builder
Deze tools bouwen queries veilig op en verkleinen de kans dat ontwikkelaars per ongeluk strings aan elkaar plakken.
Zet een web application firewall in
Een WAF filtert verdachte patronen uit inkomend verkeer en vormt een extra vangnet naast je eigen code.
Houd software up-to-date
Verouderde CMS-plugins en frameworks bevatten vaak bekende kwetsbaarheden. Update regelmatig en verwijder ongebruikte software.
Serverconfiguratie en monitoring
Naast je code speelt ook de serveromgeving een rol. Foutmeldingen van de database mogen nooit rechtstreeks aan bezoekers getoond worden, want deze kunnen informatie lekken over de tabelstructuur. Zet detailuitvoer van fouten uit in productie en log fouten in plaats daarvan server-side.
Controlepanelen zoals Plesk maken het eenvoudig om PHP-instellingen, errorlogs en databasegebruikers per site te beheren, zodat je snel kunt zien of er iets misgaat. Draai je websites op NVMe-opslag en LiteSpeed, dan merk je bovendien dat extra beveiligingslagen zoals een WAF nauwelijks invloed hebben op de laadtijd.
Zorg ook dat je hostingomgeving dagelijkse backups maakt, zodat je bij een geslaagde aanval snel kunt terugdraaien naar een schone versie. Bekijk de mogelijkheden van webhosting als je op zoek bent naar een omgeving met deze opties standaard ingericht, of lees hoe overstappen naar Tandata in zijn werk gaat als je al ergens anders gehost wordt.
Twijfel je over een specifieke instelling in je omgeving? In de kennisbank staan uitgebreide uitleg en stappenplannen per onderwerp.
Veelgestelde vragen
Is een ORM altijd veilig tegen SQL injectie?
Niet automatisch. Een ORM is veilig zolang je de ingebouwde querymethoden gebruikt. Zodra je rauwe SQL-strings samenstelt binnen een ORM, ben je weer kwetsbaar.
Kan een firewall SQL injectie volledig voorkomen?
Nee, een firewall is een extra laag maar geen vervanging voor veilige code. Combineer altijd prepared statements met serverbeveiliging.
Is SQL injectie alleen een risico bij formulieren?
Nee, ook URL-parameters, cookies, headers en API-verzoeken kunnen worden misbruikt als ze ongefilterd in queries belanden.
Moet ik mijn hele codebase controleren op dit probleem?
Ja, het is verstandig om alle plekken waar gebruikersinvoer de database bereikt te controleren, ook oudere of minder gebruikte functionaliteiten.
Conclusie
SQL injectie voorkom je structureel door prepared statements te gebruiken, invoer te valideren, databaserechten te beperken en je serveromgeving goed in te richten. Combineer deze maatregelen voor een robuuste beveiliging van je webapplicatie.