Een aantal zaken dat mij opvalt:
-Je Nederlands kan beter. Het stuk bevat dt-fouten, inconsequent gebruik van Engels en Nederlands, spatiefouten en andere fouten. Ook zou ik als ik jou was m'n hoofdvraag nog eens goed doorlezen.
-Als ik naar de titels van je subhoofdstukken kijk gaat de ene over een beveiligingsoplossing (SSL), de volgende over een probleem (XSS) en de volgende twee weer over noch een probleem noch een oplossing. Waarom benader je het niet allemaal op dezelfde manier?
-Waarom heb je het puur over SSL en noem je TLS niet?
-Je hebt het over goedkeuren (en "goed keuren") van certificaten, volgens mij bedoel je daar ondertekenen.
-Waarom heb je gekozen voor een gedeeld hostingplatform als beveiligingsprobleem? In theorie kunnen medegebruikers van je server ook bij een gedeelde server niet bij jouw gegevens, lekken in deze scheiding daargelaten. Daarnaast komt dit probleem niet in de top tien van OWASP voor. De beheerder van de server kan bijna altijd bij jouw data, ook bij de door jou aangedragen VPS-aanbieder DigitalOcean.
-Volgens jou werkt serialization tegen XSS. Waar heb je dit vandaan?

"Vaak wordt er wel aan basis beveiliging gedacht zoals bijvoorbeeld het gebruik maken van HTTPS maar dit is niet genoeg."

Hangt dat niet van de situatie af ? Een webformulier waar ik een enquete anoniem invul, en geen persoonlijke gegevens achterlaat is wat anders dan een webformulier waar je je belastingaangifte doet, of je creditcard gegevens achterlaat voor een bestelling. Ik zou dus beginnen met het maken van een risk assessment.

"De hosting provider DigitalOcean biedt webservers aan waar je als gebruiker de volledige controle over hebt. Om een zo veilig mogelijke omgeving op te zetten wordt daarom aangeraden om een soort gelijke service zoals DigitalOcean te gebruiken."

Hoe bedoel je dat, iedere klant krijgt een control panel. Bij hosting providers worden websites vaak massaal gehacked, doordat de hosting provider bijvoorbeeld de security updates van zo'n control panel niet goed bijhoudt. Indien iemand het control panel hacked, dan heeft deze controle over jouw webserver.

Wat versta jij verder onder "volledige controle" wanneer je een shared cloud webserver huurt bij een hosting provider ?

Je hebt geen controle over de hardware, geen controle over impact van DDoS aanvallen op andere klanten, en als je zelf wordt aangevallen, loop je het risico afgesloten te worden om andere klanten in bescherming te nemen, om maar wat te noemen.

Je controle is wat dat betreft toch vrij beperkt te noemen.

Niet de website maar de verbinding. Als toekomstige professional moet je niet bijdragen aan de verwarring die in de volksmond bestaat.

M.b.t. de laatste zin: de gegevens kunnen niet door iedereen uitgelezen worden, een aanvaller zal daar moeite voor moeten doen.

In plaats van "Dit is voor websites geen probleem ..." bedoel je waarschijnlijk iets als "Dit vormt voor gebruikers geen beveiligingsrisico ...".

Echter, alleen lezen via http is ook niet zonder risico's. Een succesvolle MitM kan alle informatie wijzigen die wordt uitgewisseld en zowel de gebruiker als de server op het verkeerde been zetten.
Voorbeeld: de gebruiker opent http://www.nu.nl/ en de aanvaller wijzigt een pagina in "Wachtwoorden internetbankieren ING gekraakt" met een link naar een neppagina waar wachtwoorden gewijzigd kunnen worden.

Los van verwarring over bedrijf.nl en bedrijfx.nl is het onjuist dat je zo in alle gevallen forceert dat de browser via https met de server communiceert. Hoewel een MitM via https met de server zal communiceren, blijft de gebruiker http://... zien in de browser.
Een gedeeltelijke oplossing voor dit probleem is het toepassen van HSTS (zie https://www.security.nl/posting/389177/Bank+https+aanval+op+TV#posting389187).

Wat ik geheel mis in jouw artikel is wijzen op het belang van authenticatie van de server. Een verstandige gebruiker zal niet zomaar op elke server zijn of haar gegevens willen invullen, en moet 2 dingen zeker weten:
1) De domain name (zoals bedrijf.nl) is daadwerkelijk van de bedoelde organisatie;
2) De browser heeft daadwerkelijk een verbinding met de bedoelde domain name (zoals bedrijf.nl).

Hierbij helpt SSL/TLS. Uitleggen hoe dat werkt voert wellicht te ver voor jouw artikel, maar omdat mijn ervaring is dat weinig mensen dit begrijpen, leg ik het hieronder uit.

Op de server staat een sleutelpaar bestaande uit een (geheime) private key en een bijbehorende (niet geheime) public key. Alles wat je met een public key versleutelt kan uitsluitend met de bijbehorende private key worden ontsleuteld. De server stuurt de public key naar de browser. De browser genereert een willekeurig getal, bijv. 13579, versleutelt dit met de public key en stuurt het resultaat naar de server. De server ontsleutelt dat met de private key en roept: het was 13579! Dit is een vereenvoudiging, het doel is echter hetzelfde: hierdoor weet de browser zeker dat de server beschikt over de private key behorende bij de public key die de server opstuurde.

Dat zegt nog niets - tenzij we weten van wie het sleutelpaar is. Daarom stoppen we de public key samen met een domain name in een certificaat en laten dat certificaat door een certificate authority digitaal ondertekenen. Belangrijk: als het goed is stelt de certificate authority daarbij vast of degene die het certificaat aanvraagt, gerechtigd is om dat te doen namens de organisatie met de gegeven domain name.

In plaats van de kale public key stuurt de server voortaan het certificaat naar de browser. De browser controleert of de domain name in het certificaat overeenkomt met de in de URL balk getoonde domain name, en of de server over de juiste private key beschikt. Als dat allemaal klopt (en de private key van de server niet door aanvallers gekopieerd is) communiceert de browser daadwerkelijk met de bedoelde server. Pas als je zeker weet met wie je praat heeft het zin om de verbinding te versleutelen!

Als ik jou was zou ik me nog wat meer verdiepen in de web applicatie problemen, want hier sla je de plank een paar keer flink mis.

Onder code injectie worden niet injecties verstaan die client-side worden uitgevoerd (zoals html of javascript), maar juist injecties die server-side worden uitgevoerd (zoals php, java, enz).

Prepared statements helpt alleen tegen SQL injection; niet tegen aanvallen als XSS, enz.

Serialisation is iets anders dan schonen en haalt ook niks weg. Bij serialisation zet je karakters om in een andere notatie in de hoop dat het systeem waar het terecht komt snapt dat dit data is en niet uitvoerbare code. Ik gebruik hier bewust 'hoop', omdat het cruciaal is dat de goede methode wordt gebruikt voor de plek waar de data wordt gebruikt, omdat het anders niet of zelfs averechts werkt.

Het daadwerkelijk opschonen van invoer (als in: weghalen van mogelijk kwalijke zaken) noemt men sanitatie.

Veel belangrijker dan serialisatie en sanitatie is echter validatie wat inhoudt dat je controleert of de inhoud van de invoer overeenkomt met de verwachting. Dit is niet altijd mogelijk, maar postcode velden waar strings van 30 karakters met allerlei rare tekens in staan zijn natuurlijk bij voorbaat al verdacht en zou je niet eens moeten willen verwerken als 'website'.