De simpelste weg om je data te beveiligen is om ze niet bereikbaar te hebben, zoals ze niet online te hebben. Zeg maar de bekende "air gap" beveiliging. Daarmee voorkom je dat als er perongeluk iets open staat of kapot blijkt te kunnen, de data gejat kan worden. Simpel, niet?

Daarna: Beveiligingslekken zijn meestal vrij geniepig. Een SQL injectie is een "quoting"probleem. Dat is best te ondervangen en met standaardmethodes ben je een eind op weg. Uiteindelijk moet je het hele proces snappen en dan kun je zo volgen hoe zoiets werkt, en dan kun je ook uitvogelen hoe je je ertegen moet verdedigen. Maar het is slechts een van de vele vormen van geniep. Beetje teveel werk om dat zo even uit te leggen.

Er zijn er meer. Iedere keer dat er data van vreemde oorsprong binnenkomt loop je een zeker risico. PHP was altijd berucht door het gemak waarmee je als buitenstaander scriptvariablen kon invullen. Waarmee alle invoercontrole simpelweg omzeild wordt.

Van ASP weet ik dat het redmondspecifiek is. Wat dan weer bovenop hun webserver zal draaien, en dan het OS eronder, allemaal dingen die ik niet zondermeer aan het internet zou willen hangen.

HTML kan de webserver in principe zo recht toe recht aan als bestandje serveren (en dat kan tegenwoordig heel efficient en dus snel) zonder dat er verdere instructies uitgevoerd worden op de server. Wil je toch weer ingewikkelder zaken met je webpaginas, kun je naar javascript grijpen. Nadeel is dan weer dat dit en makkelijk nodeloos langzaam wordt voor je klant en dat je makkelijk "cross-site scripting"-lekken kan creeren. Dit is niet specifiek op kale HTML, overigens; een willekeurige scripttaal op je servert met js in de browser geeft zomogelijk nog meer gedonder, want complexer.

Er zijn wel meer manieren om HTML te genereren. ruby on rails was een tijdje heel populair, java ("servlets") is groot in de wereld van het grootbedrijf, python is populair tegenwoordig, noem maar op. Je kan zelfs je webpaginas per template engine na iedere wijziging "statisch" genereren en dat dan op je webserver te parkeren als op te dienen kale html.

Maar je zal nog wat meer rond moeten kijken, naar wat er kan en wat de verschillende risicos zijn. Er is niet zomaar een enkele "beste", dat ligt heel erg aan wat je wil en dan komt er ook nog je persoonlijke voorkeur kijken. Mijn voorkeur is heel sterk om zoveel mogelijk met html+css en verder niets te doen, server side scripts te bewaren voor dingen die echt niet zonder kunnen, en client side javascript ook te beperken tot oftewel dingen die echt niet anders kunnen oftewel zo te gebruiken dat als javascript uitstaat dat de site wellicht minder soepeltjes maar nog steeds correct werkt.

Zo hou je de boel simpel. En hoe simpeler, hoe makkelijker de beveiligingsgaten te voorkomen, te vinden, en te vullen zijn.

Is de site klein en hoef niet veel geupdate te worden hou het bij html houden. Dan kan er niks via de site zelf gebeuren tenzij echt iemand toegang heeft tot de bestanden zelf. Maar de mogelijkheden zijn dan beperkt wat Sasha Helena al zei.

Wil je groter of moet je meer dingen op de site kunnen is denk ik PHP het beste om te kiezen. Maar ik weet zelf niks van ASP af dus kan het fout hebben. Maar wat je ook gebruikt als serverside taal geld altijd dat je nooit je gebruikers moet vertrouwen. Alles wat je kan veranderen dus dubbel controleren. Verwacht je dus een getal controleer of de waarde een getal is. Zo niet geef je een foutmelding. En wat je ook beter niet kan doen is onnodige dingen aan de site toevoegen die niet of bijna nooit gebruikt worden. Hoe complexer de site namelijk wordt hoe groter de kans op fouten is. Hou je je hieraan ben je al redelijk veilig.

Wat hierboven staat moet SQL injection al moeilijker maken maar in PHP (denk ook in andere talen) heb je functies die al veel werk voor je doen. In php moet je mysql_real_escape_string gebruiken als je nog verbinden met de database op de oude manier. Vanaf php 5.1 kan je ook PDO gebruiken met de database. Dit maakt mysql_real_escape_string overbodig omdat dit al voor je gedaan wordt als je PDO prepared statements goed zijn. Zelf raad ik PDO aan bij een nieuwe site omdat de andere manier in php 6 komt te vervallen. Ook al zal er een alternatieve oplossing zijn om het te blijven ondersteunen.

Link PDO: http://www.phptuts.nl/view/27/1/ (letop dit is hele uitleg over PDO tevens zijn hier ook meer dingen te vinden)
Link mysql_real_escape_string: http://php.net/manual/en/function.mysql-real-escape-string.php

Als laatste. De veiligheid van een website is niet alleen de code zelf. Ook de software + configuratie van de server spelen een rol hoe veilig een website is.

Wat ik zelf weet is dat er binnenkort een zeer goedkoop en goed bedrijf komt die zich specialiseert in de beveiliging van uw website.

U zou dan gebruik kunnen maken van die services om zo 99% uit te sluiten.

Er is namelijk altijd wel een manier om binnen te komen. Maar om bijna alles uit te sluiten dan blijft er weinig meer over, wat in uw voordeel is natuurlijk :)

@Cryptografie, volgens mij moet je op marktplaats zijn met je spam ...

Ik noem dit geen spam. Ik weet alleen dat er binnenkort zo'n service komt.

Het kan inderdaad wel een beetje als spam overkomen, wat niet mijn bedoeling is!

https://www.owasp.org/index.php/Main_Page

OWASP is een van de grootste instanties die zich bezig houden met richtlijnen voor het maken van veilige web applicaties, dus ook websites :)

Hier kan je veel informatie vinden over hoe je je sourcecode moet opbouwen en welke technieken je kan gebruiken om het aanvallers lastig te maken. Als je deze regels gebruikt denk ik dat je het beste PHP kan gebruiken. Veel info over te vinden, en de exploits die er zijn zijn lastig te gebruiken tenzij de aanvaller de precieze code kan achterhalen.

Ook zijn er verschillende sites die via opdrachten je secure leren code, zoals http://www.codecademy.com/learn

Succes

Denk dat er wel 1000den bedrijfjes zijn die denken dat ze secure kunnen coden

Ik bedoel niet het coden ervan, maar de beveiliging ervan na checken van het gecodeerd stuk.

Maar ik ga hier niet verder op in. I.v.m SPAM ;)