CL Web bouwt en ontwikkelt al zo'n jaar of 4 onze website's (ja inmiddels zijn het er meerdere). Blij met de fijne, professionele, betrouwbare samenwerking en het altijd meedenken in verbeteringen. Korte lijnen, goed bereikbaar en alles bespreekbaar. Iedere dag leren wij meer van hen.
Kwaliteit, Professionaliteit, Responsiviteit, Waarde
Kies voor topbeveiliging van jouw website en applicatie
Up-to-date
Altijd de meest recente versie van Laravel
AVG-proof
Websites en applicaties zijn AVG-proof
Hacking tested
Regelmatige websecurity tests door ethische hackers
SSL-certificaat
Voor een beveiligde verbinding tussen gebruiker en server
24/7 monitoring
Eventuele foutmeldingen worden direct opgemerkt
Securitydashboard
Doorlopende bewaking van bekende kwetsbaarheden (CVE's) in elk onderdeel van jouw website of applicatie
Tweevoudige verificatie (2FA)
Voor extra beveiliging bij het inloggen
IP-restricties
Indien gewenst is de website of applicatie alleen via bepaalde IP-adressen bereikbaar
Firewall en load balancer
Bescherming en splitsing van data over verschillende servers
Hosting in eigen beheer
Zowel Nederlandse als internationale hosting
Securitydashboard: doorlopend zicht op CVE-risico's
Beveiliging is geen eenmalige oplevering. Er worden vrijwel wekelijks nieuwe kwetsbaarheden gepubliceerd in software die overal wordt gebruikt, geregistreerd als CVE (Common Vulnerabilities and Exposures). Een website die vorig jaar veilig was, kan dat vandaag niet meer zijn zonder dat er iets aan gewijzigd is.
Daarom draaien alle websites en applicaties die wij beheren in ons securitydashboard. Dat houdt per project bij welke onderdelen erin zitten en welke versie daarvan draait, en legt dat naast de gepubliceerde CVE's. Verschijnt er een kwetsbaarheid die jouw applicatie raakt, dan zien wij dat meteen — in plaats van het te ontdekken nadat iemand er misbruik van heeft gemaakt.
Per melding wegen we hoe urgent het is: hoe groot is het risico, is het betreffende onderdeel in jouw situatie überhaupt bereikbaar, en kan de update meteen door of moet er eerst getest worden. Kritieke kwetsbaarheden pakken we direct op, de rest loopt mee in het reguliere onderhoud.
Beveiliging in lagen: waar het misgaat en wat eraan te doen is
De meeste hacks zijn niet op jou gericht. Het overgrote deel is geautomatiseerd: scripts die het hele internet aflopen op zoek naar bekende gaten — een verouderde plugin, een openstaande beheeromgeving, een wachtwoord dat al in een eerder datalek is gelekt. Dat betekent ook dat je er met een paar lagen op orde al een heel eind komt.
De code zelf. Laravel dekt de bekendste aanvalsroutes standaard af, maar dat werkt alleen als je het framework ook gebruikt zoals het bedoeld is. Daarom leest er altijd een tweede ontwikkelaar mee via een code review.
De onderdelen eronder. Elke applicatie leunt op pakketten van derden. Die bewaken we op nieuwe CVE's, zoals hierboven beschreven.
Toegang. Tweefactorauthenticatie bij het inloggen, rechten per rol in plaats van één beheerdersaccount voor iedereen, en waar nodig toegang beperkt tot bepaalde IP-adressen.
De infrastructuur. Firewall, load balancer, SSL en hosting in eigen beheer, zodat we bij een probleem niet afhankelijk zijn van de planning van een externe partij.
Controle achteraf. Regelmatige securitytests door ethische hackers, die gericht proberen binnen te komen op de plekken waar geautomatiseerde scans niets vinden.
AVG: persoonsgegevens verwerken zonder risico
Zodra je website of applicatie gegevens van mensen verwerkt — een contactformulier is al genoeg — val je onder de AVG. De kern daarvan is niet ingewikkeld: verzamel alleen wat je nodig hebt, bewaar het niet langer dan nodig, en zorg dat alleen de juiste mensen erbij kunnen.
In de praktijk betekent dat keuzes tijdens de bouw, niet erna. Welke velden staan er echt in het formulier? Hoe lang blijven aanvragen bewaard en wat ruimt zichzelf op? Wie ziet welke gegevens, en is terug te zien wie wat heeft ingezien? Achteraf verbouwen kost meer dan het vooraf goed inrichten, en bij een datalek is precies dit wat je moet kunnen aantonen.
Wat je zelf kunt doen
Een deel van de beveiliging ligt niet in de techniek maar in het gebruik. Drie dingen leveren onevenredig veel op:
Zet tweefactorauthenticatie aan voor iedereen met beheerrechten, niet alleen voor jezelf.
Ruim accounts op van mensen die er niet meer werken. Een vergeten account met beheerrechten is een van de meest voorkomende ingangen.
Geef mensen de rechten die bij hun werk horen. Iemand die bestellingen verwerkt hoeft geen instellingen te kunnen wijzigen.
Veelgestelde vragen over websecurity
Hoe weet ik of mijn website gehackt is?
Soms is het overduidelijk — een vreemde pagina, een waarschuwing van Google, mails die niet aankomen omdat je domein op een blocklist staat. Vaker is het subtiel: een onbekend beheerdersaccount, bestanden met een gewijzigde datum, of uitgaand verkeer naar servers waar je niets mee te maken hebt.
Juist die stille varianten zijn het gevaarlijkst, omdat ze maandenlang kunnen doorlopen. Daarom draait er monitoring op afwijkingen in plaats van te vertrouwen op wat iemand toevallig opvalt. Vermoed je dat er iets niet klopt: neem contact op en wacht niet af.
Wat gebeurt er als er een nieuwe kwetsbaarheid in Laravel wordt gevonden?
Die verschijnt als CVE, en ons securitydashboard legt dat naast de versies die in jouw project draaien. Raakt het jouw applicatie, dan zien we dat zonder dat iemand handmatig releases hoeft te volgen.
Daarna is het een afweging: hoe groot is het risico, is het betreffende onderdeel in jouw situatie bereikbaar, en kan de update meteen door of moet er eerst getest worden. Kritieke kwetsbaarheden pakken we direct op, de rest loopt mee in het reguliere onderhoud.
Is een SSL-certificaat genoeg om mijn website veilig te noemen?
Nee. Een SSL-certificaat versleutelt het verkeer tussen de bezoeker en de server, zodat niemand onderweg kan meelezen. Dat is noodzakelijk, maar het zegt niets over de veiligheid van de applicatie zelf.
Een website met een geldig slotje kan prima een verouderde plugin draaien of een beheeromgeving zonder tweefactorauthenticatie hebben. Het slotje beschermt de weg ernaartoe, niet wat er aan het eind staat.
Wat is het verschil tussen monitoring en een securitytest?
Monitoring loopt continu en kijkt naar wat er ís: draaiende versies, foutmeldingen, afwijkend verkeer, nieuwe CVE's. Het signaleert dat er iets veranderd is of dat er een bekend risico bij is gekomen.
Een securitytest is een momentopname waarbij een ethische hacker gericht probeert binnen te komen. Die vindt dingen die geen enkel geautomatiseerd systeem opmerkt, zoals een fout in de logica van je bestelproces. Je hebt ze allebei nodig: het een vervangt het ander niet.
Wat moet ik doen bij een datalek?
Bij een datalek met risico voor de betrokkenen moet je dat binnen 72 uur melden bij de Autoriteit Persoonsgegevens, en in ernstige gevallen ook bij de mensen zelf. Die klok begint te lopen zodra je het lek kent, niet zodra je het hebt opgelost.
Praktisch betekent dat: eerst het gat dichten en het bewijs bewaren, dan vaststellen welke gegevens het betreft en van hoeveel mensen. Wij helpen bij dat technische deel en leveren de gegevens die je voor de melding nodig hebt. De melding zelf doe je als verwerkingsverantwoordelijke zelf.
Onze klanten
Websecurity uitbesteden?
Neem contact op met Cyril
Eigenaar CL Web & Applicatie Specialist
Laatst bijgewerkt op