Uiteraard is security iets waar iedereen mee te maken heeft, van beheerder tot eindgebruiker en natuurlijk de ontwikkelaar die zonodig uitbuitbare bugs in zijn code laat. Foei! Nu we dat hebben gehad, is het de vraag hoe je het kunt voorkomen. Want het gaat natuurlijk om implementatie, juiste gebruikersautorisatie, maar ook om veilige code.

Natuurlijk, je moet wel voldoende tijd (lees: budget) krijgen om de boel goed dicht te timmeren, maar afgezien daarvan is het volgens Henrik Stahl, senior director van product strategy Java platform bij Oracle, eigenlijk helemaal niet moeilijk om code goed dicht te krijgen. “Het is een kwestie van het volgen van best practices. Die kun je echt overal vinden." aldus Stahl, die verder een paar tips geeft voor 'schone' code. Uiteraard redeneert Stahl hierbij vanuit Java, maar het geldt net zo hard voor andere programmeertalen.

Weet wat je móet afdekken

De meeste hackers zijn lui, en zullen zich dan ook alleen storten op de meest voorkomende gaatjes in de code. “Er bestaat een hele lijst van zaken die je als coder wilt vermijden", zegt Stahl. “Denk aan buffer overflows, stack overflows en de verkrijging van te veel rechten door verkeerde personen. Dit zijn heel generieke zaken."

Sommige talen hebben daar in zichzelf een soort van failsafe in, maar het is toch handig om ze zelf in de gaten te hebben. “Als de Java Virtual Machine goed functioneert hoef je bijvoorbeeld geen zorgen te hebben om buffer overflows, maar verhoogde rechten blijven wel iets waar je op moet letten."

Hou de domeinen gescheiden

Nog een open deur, maar eentje die veels te vaak niet dicht wordt gedaan: code moet draaien waar het moet draaien, en niet daarbuiten. “Natuurlijk moeten gebruikers transacties kunnen uitvoeren, maar je wilt niet dat de code die op het systeem van de gebruiker draait dingen doet op het backendsysteem."

Alles dient dus in de juiste security-context plaats te vinden, anders krijg je dat de ene gebruiker onverhoopt bij de gegevens kan van een ander. In sommige gevallen is het mogelijk om de boel in een sandbox te draaien. Doe dat dan ook.

Alles moet consequent zijn

Bij een afschrijving van een rekening moet het afgeschreven bedrag gelijk zijn aan het bedrag dat moet worden bijgeschreven. Zo niet, dan is er poen weg. Deze vergelijking gaat ook op voor de gegevens waarmee applicaties omgaan en dit geldt voor iedere applicatie op zijn eigen manier.

“De integriteit van de gegevens moet domweg kloppen", zegt Stahl. 1 plus 1 moet uitkomen op 2, en niet op 1,9999. Natuurlijk wéét je dit als ontwikkelaar, maar wederom is het een fout die vaker gemaakt wordt dan je lief is.

Hou een auditlog bij

Tijdens het coden kom je ongetwijfeld direct dingen tegen die functioneel niet kloppen: account A kan bij de gegevens van account B, iemand kan zich voordoen als eigenaar account C, enzovoorts. Naast dat je het probleem uiteraard direct oplost, is het volgens Stahl raadzaam om een logje bij te houden van dit soort incidenten.

Code kan namelijk heel erg uitgebreid zijn, en het kan zijn dat je iets laat zitten dat tijdens een toekomstige audit naar boven komt. Met een logje in de hand is het mogelijk om sneller verbanden te leggen, waardoor je wellicht nog meer probleempjes boven tafel kunt krijgen en deze sneller op kunt lossen.

Toch maak je fouten

Helaas moet je je als ontwikkelaar berusten in het feit dat je fouten zult maken. “Natuurlijk, er zijn er veel meer dingen die je moet doen", verzucht Stahl. “Dit is slechts een kleine selectie van algemene dingen. Ook best practices zullen niet overal een antwoord op hebben. Dat is theoretisch onmogelijk."