17 Tips voor een betere website beveiliging

Beveiliging op het internet is op het moment een hot-topic. Links en rechts worden er nieuwsberichten gepubliceerd dat er een datalek is bij website X, vervolgens is er ingebroken bij website Y en ga zo maar door. Hoewel internet en website beveiliging constant in het nieuws is, het lijkt vaak toch wel ver weg. Elke dag worden er enkele tienduizenden websites gehackt, en jouw website kan zomaar de volgende zijn. Elke website heeft te maken met inbraakpogingen, vaak zelfs meerdere keren per dag. In de meeste gevallen merk je hier helemaal niets van. Maar het hoeft maar één keer fout te gaan en je zit gelijk met een bord vol problemen.

Elke minuut worden er (tien)duizenden aanvallen wereldwijd uitgevoerd, de meeste van deze aanvallen zijn onsuccesvol. Dat het merendeel van deze aanvallen mislukken en ongemerkt zijn is niet echt opzienbarend. Het grootste deel van dit aanvallend-internetverkeer is namelijk niet afkomstig van echte mensen. Bijna alle digitale inbraakpogingen zijn geautomatiseerd. De meeste van deze automatische inbraakpogingen gaan willekeurige websites of IP adressen af en proberen in te loggen met veelvoorkomende inloggegevens. Voor deze automatische inbraakpogingen maakt de grootte van je website niets uit. Op deze manier alleen al hebben de meeste websites al gelijk te maken met enkele tientallen inbraakpogingen per week.

De gevolgen van een gehackte website

klik hier om gelijk naar de tips te gaan.
Dat een gehackte website foute boel is hoeven we niet uit te leggen. Maar een gehackte website heeft niet altijd dezelfde directe gevolgen. Soms is het mogelijk dat je het niet eens door hebt dat er is ingebroken op je website, maar wat gebeurt er dan eigenlijk?

Ongemerkt gebruik door hackers

Als je website is gehackt hoef je dit niet gelijk te merken, sommige doelen zijn namelijk zeer goed verborgen en laten zichzelf niet zomaar zien. Een voorbeeld hiervan is als je website of webruimte stiekem gebruikt wordt voor andere doelen.
In dit geval wordt jouw website onderdeel van een gigantisch netwerk dat stiekem aanvallen gaat doen op andere websites. Of nog erger, je website wordt gebruikt in een netwerk om DDoS aanvallen uit te voeren.
Het kan ontzettend lang duren voordat je zelf echt doorhebt dat je website op de achtergrond is gekaapt, maar de consequenties zijn zeker merkbaar.

Het grootste probleem van dit type hack is dat het je eigen website eigenlijk niet direct schaadt. Er is maar een kleine hoeveelheid kwalijk verkeer afkomstig van je website, misschien wordt er maar één keer per week via jouw website een aanval uitgevoerd. Hierdoor duurt het lang voordat alles aan het licht komt.  Het probleem wordt pas zichtbaar zodra andere partijen jouw website gaan wantrouwen, en dat is een probleem want het succes van jouw website heeft veel te maken met vertrouwen bij andere partijen.
Een gevolg zal zijn dat de reputatie van je website een klap krijgt. En dit zal weer leiden tot problemen met (bijvoorbeeld) SEO.

Het achterhalen van privé gegevens

Privé gegevens zijn een bekend doel voor hackers. Creditcard gegevens, adresgegevens, email adressen en wachtwoorden zijn enkele voorbeelden van de informatie die achterhaald kan worden via een data lek.
Meestal is het voorpagina nieuws zodra ergens privé gegevens zijn gestolen, maar in het nieuws gaat het enkel over gigantische organisaties die in het vizier zijn gekomen van hackers. Vaak ontstaat hierdoor de gedachte dat kleine websites geen doelwit zijn. Helaas is dit niet het geval.
Elke website met gegevens die ook maar een klein beetje interessant kunnen zijn is gelijk een doelwit.

Bij een data lek van privé gegevens krijg je een heel scala aan problemen. Dat je gehackt bent is maar één deel van de problemen waar je mee te maken kan krijgen. De reputatieschade is gigantisch en dit kan financiële gevolgen hebben. Het is praktisch gegarandeerd dat webshops met een data lek klanten zullen verliezen.
Daarnaast wordt er meestal een zogenoemde "backdoor" geplaatst op je website zonder dat je dit merkt. Met zo'n backdoor kan een hacker zonder al te veel moeite opnieuw toegang krijgen tot je website en de gegevens die je verwerkt.

Spamverspreiding

Spam is iets wat iedereen kent. Of het nou via de e-mail is of via andere kanalen, iedereen heeft ooit wel eens te maken gehad met spammers. Als je zelf spam ontvangt dan denk je er meestal niet zo veel van. Het is echter ook mogelijk dat jouw website wordt gebruikt om anderen te spammen na een hack. Er zijn verschillende manieren waarop spamverspreiding plaats kan vinden via jouw website. De grootste open deur is spamverspreiding via reacties op berichten zoals blogartikelen, in dit geval heb je niet eens met hackers te maken maar alleen met zogenoemde "spambots". Heel schadelijk zal dit niet zijn, en het is bovendien nog relatief makkelijk om spambots te bestrijden.

Helaas zijn er ook spammethodes die niet gelijk zichtbaar zijn of makkelijk om op te lossen. Zo is het mogelijk dat er wordt ingebroken op een website waarna de website wordt gebruikt om spam e-mails te verzenden naar een gigantische hoeveelheid mensen. Vaak zal je dit niet zelf direct doorhebben, de spammers gebruiken namelijk verschillende methoden om ervoor te zorgen dat jij niet doorhebt wat er aan de hand is. Met deze manier van spammen kan je serieuze problemen krijgen voor je website of bedrijf. Als de spam ongecontroleerd doorgaat dan zal je positie op de zoekmachines binnen een dag merkbaar dalen. Na enkele dagen zal je merken dat je eigen e-mails opeens niet meer geaccepteerd worden bij de grote e-mail providers zoals Gmail, Yahoo en Microsoft. Je zult dus moeten touwtrekken met deze organisaties om ervoor te zorgen dat je domein wordt gezien als betrouwbaar, en dit gevecht wil je absoluut voorkomen aangezien het soms maanden kan duren.

Verspreiding van malware

Verspreiding van malware is iets wat helaas ook voor kan komen via een nietsvermoedende website. De detectie hiervan is echter steeds beter en de kans wordt elke dag kleiner dat je hiermee echt te maken krijgt. Het kan echter nog steeds gebeuren en de consequenties zijn niet mis. Afhankelijk van de bouw van je website is het voor een hacker mogelijk om stukken code toe te voegen aan jouw website. Een gevolg kan zijn dat website bezoekers op de achtergrond een virus downloaden terwijl ze aan het lezen zijn over de nieuwe spijkerbroekencollectie van je webshop. De eerste partijen die merken wat er aan de hand is zullen de zoekmachines zijn en anti-virus programma's.

Als je gebruik maakt van diensten voor je website van Google of Bing dan zal je redelijk snel bericht krijgen dat er ongewone activiteit is waargenomen (met een dringende ondertoon om dit op te lossen). Kort hierna zal je merken dat je positie in zoekmachines extreem snel zal dalen en het zal ontzettend lang duren voordat je website weer zal stijgen in de zoekresultaten. Daarnaast kan het zo zijn dat je website terecht komt op een zogenoemde "web trust blacklist". De Web Trust lijsten worden beheerd door enkele van de meest invloedrijke bedrijven op het gebied van internet veiligheid, twee voorbeelden zijn Google Safe Browsing en McAfee SiteAdvisor. Het duurt meestal redelijk lang voordat je echt op een blacklist terecht komt, maar als je er eenmaal op staat is het lastig om er weer vanaf te komen.

De malware waarschuwing van Google SafeBrowsing

Normaal merk je niet zo veel van de Web Trust lijsten, normaal is dit ook niet nodig aangezien het systemen zijn die op de achtergrond het werk doen. Het duurt best wel lang voordat je op een blacklist terecht komt en je zal (meestal) meerdere berichten krijgen over de status van je website. Het kan echter gebeuren dat je toch te maken krijgt met een blacklist en dit kan je voor maanden of soms jaren achtervolgen. Je kan gelijk merken dat het verkeer naar je website daalt naar bijna niks, je bezoekers worden namelijk gegroet met een melding zoals de afbeelding hierboven. Je kan de mogelijk waarschuwingen zelf zien via testsafebrowsing.
Mocht het toch zo zijn dat je website is opgenomen in de blacklist van Google SafeBrowsing dan is het natuurlijk nodig om dit op te lossen, Sucuri heeft een goed artikel hoe je dit het beste kunt aanpakken.

De checklist

Deze tips dienen als een basis voor iedereen die een website heeft, websites bouwt of websites beheert. Het maakt niet zo veel uit of je nou een starter bent in de wereld van websites of veteraan. Het is nou eenmaal de nare werkelijkheid dat elke website wel te maken krijgt met spammers en hackers. Je kan deze tips een beetje zien als een checklist om te kijken of je website in de basis wel veilig is.

Voor deze tips hoef je niet per sé een ontwikkelaar te zijn, kennis van code is handig maar niet nodig. Indien er een complexere tip is dan hebben we de handelingen uitgeschreven of we linken naar een helpdesk artikel waar dit beschreven staat.

#1 - Wees altijd up-to-date

Het updaten van je website software is eigenlijk de absolute basis als het aankomt op de veiligheid van je website. Updates van je CMS, plugins, modules of themas brengen vaak verbeterde beveiligingsmaatregelen met zich mee.
Alle software wordt minder veilig over tijd, het maakt eigenlijk niet uit met welke software je website is gemaakt. Het is daarbij natuurlijk wel belangrijk om software te gebruiken die regelmatig wordt geüpdate. Hoewel het vaak onschuldig lijkt om een update zo nu en dan over te slaan is helaas het tegengestelde waar. Het komt namelijk extreem vaak voor dat er op een website wordt ingebroken via een verouderde plugin of thema.

Indien automatisch updaten van plugins mogelijk is via je CMS dan is dit zeker het overwegen waard. Let hierbij wel op dat het mogelijk is dat plugins met elkaar gaan conflicteren, het is dus belangrijk dat je wel alle updates in de gaten houdt.
Als dit niet gewenst is dan kun je overwegen om gebruik te maken van "managed" diensten, hierbij wordt de zorg van je systeem up-to-date houden weggenomen. Beheerde diensten bestaan ondertussen voor praktisch elk CMS en dit kan een hele hoop schelen. Zo bieden we zelf Managed WordPress hosting die de zorg van updaten wegneemt samen met vele andere voordelen.

#2 - Gebruik goede wachtwoorden

Het gebruik van sterke wachtwoorden is cruciaal op het internet. Het inbreken bij websites via zwakke wachtwoorden is nog steeds de meest voorkomende manier waarop websites in de problemen komen. Vaak worden er nog steeds wachtwoorden gebruikt zoals "wachtwoord123" of variaties op woorden door middel van tekens: "W@chtw00r_d".
Het probleem is dat dit soort wachtwoorden nog steeds heel makkelijk te raden zijn voor computers, het is dus nodig dat wachtwoorden complexer worden maar dan kunnen we ze weer niet onthouden. De adviezen voor wachtwoorden zijn steeds weer anders en iedereen zegt dat het anders moet. Maar hoe moet het dan?

Of een wachtwoord écht sterk is, is afhankelijk van maar 2 factoren: Lengte en complexiteit. Een lengte van 12 tekens is tegenwoordig toch echt wel het minimum, en hoe complexer (willekeurige tekens) deze 12 of meer tekens hoe beter je wachtwoord. Let hierbij op dat je wachtwoord van letters en tekens niet op een echt bestaand woord lijkt... Het gebruik van "b@nkaut0maat" is namelijk weliswaar 12 tekens maar een stuk minder sterk als wachtwoord in vergelijking tot "2ksj5dZ{y7;h".
Het enige probleem wat nu nog bestaat is ons eigen geheugen, want zo'n volledig willekeurig wachtwoord is natuurlijk wel heel veilig maar niet te onthouden. Zeker niet als je gaat bedenken dat je wachtwoorden niet moet hergebruiken op andere websites.

Gelukkig is er een oplossing voor ons geheugenprobleem in de vorm van een wachtwoord-manager. Dit is een programma op je computer of laptop (en ook smartphone als je dit wilt) dat de wachtwoorden voor je onthoud en tegelijk controleert of je bestaande wachtwoorden wel veilig genoeg zijn. Om eerlijk te zijn, deze oplossing is natuurlijk niet ideaal. Maar het is zeker een betere oplossing dan vasthouden aan zwakke wachtwoorden. Goede wachtwoord-manager programma's zijn onder andere Dashlane, LastPass, en 1Password. Het is ook mogelijk om voor een Open-Source programma te kiezen zoals KeePass.

#3 - Limiteer het aantal login pogingen

Een veelvoorkomende methode om in te breken bij websites is brute-force. Dit houdt in dat een computer gewoon wachtwoorden gaat proberen in de hoop dat er een keer goed wordt gegokt. Een beetje moderne computer kan dit met enkele duizenden wachtwoorden per seconde uitvoeren. In het ergste geval wordt je wachtwoord gekraakt, en als dit niet gebeurt zit je nog steeds met het feit dat er duizenden pogingen per seconde zijn om in te loggen. Als dit niet wordt geblokkeerd dan zal dat betekenen dat je website een stuk trager zal worden voor normale bezoekers.

De oplossing is het limiteren van het aantal inlogpogingen per IP adres. Bijna elk CMS heeft wel verschillende plugins om dit mogelijk te maken. Voor WordPress kan je gebruik maken van de WP Limit Login Attempts plugin. In het geval van Joomla is er een vergelijkbare plugin genaamd Brute Force Stop die prima werkt. En als je Drupal gebruikt moet je soms wat verder zoeken maar ook hier is een plugin beschikbaar genaamd Login Security.

Deze plugins zijn specifiek voor het blokkeren van inlog pogingen, je kan ook kiezen voor de plugins die beschreven staan bij tip #14

#4 - Maak gebruik van 2 factor autorisatie

Naast een sterk wachtwoord is het sterk aan te raden om gebruik te maken van 2 factor autorisatie, of soms tweestaps-authenticatie genoemd. Het concept is simpel, om in te kunnen loggen moet je bewijzen dat jij wel echt eigenaar bent van het account. Dit gaat meestal door middel van je smartphone en ook dan kan het op verschillende manieren. Sommige websites gebruiken nog een SMS bevestiging die naar je mobiele nummer wordt gestuurd maar het komt steeds vaker voor dat 2 factor authenticatie via een app gaat op je smartphone. Hiervoor zijn verschillende apps beschikbaar op zowel Android als IOS, de meest bekende zijn de Google Authenticator en Authy.

Beide apps werken op een vergelijkbare methode, de website waar je 2FA (2 factor authenticatie) wilt activeren laat een QR code zien die je scant met je app. Hiermee wordt je telefoon geregistreerd als het verificatie apparaat. Vervolgens zal je app een combinatie van 6 cijfers laten zien die elke 30 seconden verandert. Om in te loggen heb je dus nu de gebruikersnaam nodig in combinatie met het wachtwoord maar óók de 6 cijfers op je telefoon.

#5 - Kies goede hosting

Deze tip is zeer belangrijk voor de veiligheid van je website, het is jammer dat het gelijk een "wij van wc-eend adviseren wc-eend" verhaal wordt. Je hosting provider is de partij die het fundament moet neerleggen voor de veiligheid van je website. Je kan geen veilige website hebben als de server zo lek is als een mandje. Zo is het nodig dat je niet zomaar kunt inloggen in FTP of SSH, het is echt nodig dat deze protocollen goed dicht getimmerd zijn. Daarnaast is het nodig dat er genoeg veilige methodes beschikbaar zijn die je kunt gebruiken om je website op te zetten, zoals sFTP in plaats van gewoon FTP.

Bovendien is het belangrijk dat de hostingprovider controleert of geüploadde bestanden op de server wel virusvrij zijn en dat accounts goed zijn afgeschermd. Verder is het belangrijk dat de hostingpartij gebruik maakt van sterke encryptie-protocollen en algoritmes voor onder andere HTTPS. Hosting providers anno 2018 moeten echt het zogenoemde "security by design" principe aanhouden, dit houdt in dat een infrastructuur of systeem vanaf het eerste moment is gemaakt om veilig te zijn zoals onze nieuwe webhosting.

#6 - Gebruik HTTPS

HTTPS is ondertussen de standaard aan het worden op het internet, en dat is hartstikke goed. Als je nog geen gebruik maakt van HTTPS dan is het zeer sterk aan te raden om dit zo snel mogelijk in te stellen. Op deze manier is de verbinding tussen je website en de bezoeker versleuteld. Je kunt meer lezen over HTTPS en waarom het belangrijk is in ons blogartikel over SSL (HTTPS).

Maar zodra je een SLL certificaat hebt voor je website en dus HTTPS gebruikt dan ben je er nog niet. Het is handig om een SSL test te doen via de website van Qualys. Deze test controleert of het SSL certificaat voor je website en de instellingen van de server wel veilig genoeg zijn. De resultaten van deze test kunnen nogal ingewikkeld zijn dus hieronder hebben we aangegeven waar je op moet letten.

De resultaten van de SSL test voor ons demo-domein: niqexdemo.com

Mocht het zo zijn dat de test een probleem aangeeft bij de bovenstaande punten dan kun je 2 dingen doen. De eerste optie is om te vragen aan je hosting provider om de problemen op te lossen. De tweede optie om over te stappen naar een andere hostingprovider die wel aan deze eisen voldoet.

#7 - Maak gebruik van de Google Search Console

De Google Search Console is op zichzelf een geweldige tool om inzichten te krijgen over SEO en hoe je je website kunt laten groeien. Maar wat vaak wordt vergeten is dat de Search Console ook inzicht kan geven in de kwaliteit en veiligheid van je website. De Search Console scant je website regelmatig, indien er abnormaliteiten worden gedetecteerd dan krijg je hierover melding. Hierdoor heb je wat meer inzicht in de status van je website.

Je kunt je hier aanmelden voor de Google Search Console.

#8 - Stel de juiste bestandspermissies in

De bestandspermissies vertellen aan een server wie specifieke bestanden wel of niet mag inzien of bewerken. Goede instellingen voor bestandspermissies zijn belangrijk aangezien je niet wilt dat een willekeurige bezoeker bestanden kan bewerken. De bestandspermissies worden ingesteld met cijfercodes tussen 0000 en 0777, deze cijfercodes vertellen aan de server welke soort gebruiker wel of niet iets mag doen. Het is niet echt nodig dat je zelf precies weet waar elke code voor staat, je kunt echter wel controleren of de huidige instellingen van je website goed staan ingesteld met onderstaande mini-checklist

#9 - Maak gebruik van sFTP

Als je een eigen website in elkaar hebt geknutseld en je wilt deze uploaden naar de webserver dan zal je meestal FTP gebruiken. Dit staat voor File Transfer Protocol en is een redelijk snelle manier om bestanden van je computer naar de server te verplaatsen. FTP heeft echter een probleem: het is eigenlijk niet meegegaan met de beveiligingseisen van nu. In principe is het mogelijk dat een hacker kan meekijken in je verbinding terwijl je bestanden aan het uploaden bent via FTP. Hiervoor is een oplossing in het licht geroepen met de naam sFTP wat officieel SSH File Transfer Protocol heet, maar het wordt vaker Secure FTP genoemd.

Het grote verschil tussen gewoon FTP en sFTP is de versleutelde verbinding. Het instellen van sFTP is wat gecompliceerder dan normaal, maar dit is het wel waard aangezien sFTP echt vele malen sterker is dan normaal FTP.
Het verschilt per hosting partij hoe sFTP opgezet moet worden, kijk hier voor ons helpdesk artikel over sFTP voor meer informatie over het opzetten van sFTP op onze servers.

#10 - Blokkeer toegang tot configuratie bestanden

Bij tip #8 is al besproken welke permissies ingesteld moeten zijn voor specifieke bestanden. Het is echter ook verstandig om toegang tot specifieke bestanden volledig te weigeren. Zo is het handig om de toegang tot configuratie bestanden gewoon te weigeren aangezien deze vaak informatie bevatten over o.a. je database. Daarnaast hebben veel Content Management Systemen bestanden die je liever wilt afschermen, voorbeelden zijn "wp-config.php" voor WordPress en "Configuration.php" in Joomla. Je kunt de onderstaande stukjes code kopiëren (let op dat je de code for het juiste CMS kopiëert) en plakken in je .htaccess bestand om dit voor elkaar te krijgen.

Het blokkeren van wp-config.php (WordPress)

<files wp-config.php>
order allow,deny
deny from all
</files>

Het blokkeren van configuration.php (Joomla)

<files configuration.php>
order allow,deny
deny from all
</files>

#11 - Blokkeer toegang tot xmlrpc.php (WordPress)

Nu we toch bezig zijn met het blokkeren van specifieke bestanden dan is het belangrijk dat we even één extra bestand in WordPress onder de loep nemen: xmlrpc.php
Het xmlrpc.php bestand maakt het mogelijk om content op je website te publiceren vanaf een externe locatie, via een app bijvoorbeeld. Tot zo ver klinkt het nog redelijk onschuldig. Het probleem van het xmlrpc.php bestand is dat het ook toelaat dat er tienduizenden wachtwoorden per minuut geprobeerd kunnen worden om in te loggen. Veel plugins die het aantal inlogpogingen limiteren zoals in tip #3 controleren alleen het inlog formulier.

De ingebouwde beveiliging van het xmlrpc.php bestand en WordPress is de afgelopen jaren al gigantisch verbeterd. Maar het komt nog steeds voor dat er Brute-force aanvallen en DDoS aanvallen worden uitgevoerd via het xmlrpc.php bestand. Als je geen gebruik maakt van de functionaliteiten die dit bestand brengt dan kun je het beste dit bestand blokkeren. Let op, de JetPack plugin maakt gebruik van dit bestand en werkt dus niet meer zodra xmlrpc.php wordt geblokkeerd.
Je kunt het bestand blokkeren door onderstaande code te kopiëren en te plakken in je .htaccess bestand.

<files xmlrpc.php>
order allow,deny
deny from all
</files>

#12 - Gebruik een gemaskeerde database prefix

Als een extra maatregel tegen geautomatiseerde aanvallen is het handig om je de tabellen in je database een willekeurige prefix te geven. Dit wordt in de beveiligingswereld "Security Through Obscurity" genoemd, dit betekend beveiliging door geheimhouding. Een echte hacker wordt hierdoor niet gestopt, maar het is prima om geautomatiseerde aanvallen te weren. Het is belangrijk om te onthouden dat Security Through Obscurity géén echte website beveiliging is en alleen werkt tegen geautomatiseerde aanvallen.

Als voorbeeld van een willekeurige prefix gebruiken we de database structuur van WordPress. Standaard wordt bij WordPress de "wp_" prefix gebruikt voor de database tabellen. Een geautomatiseerde aanval probeert in het wild in te breken bij tabellen die beginnen met wp_, als de tabellen echter nooit met wp_ beginnen dan wordt de aanvraag gelijk geweigerd. Een voorbeeld van een willekeurige prefix is yju_ in plaats van wp_.

#13 - Controleer of databases niet extern bereikbaar zijn

Als een extra beveiligingsmethode voor je database kun je controleren of de database in kwestie extern bereikbaar is. Dit houdt in dat je een verbinding met de database kunt maken zonder dat deze eerst is goedgekeurd. In plaats van alleen de gebruikersnaam en het wachtwoord moet óók het IP adres van de verbinding kloppen voordat je toegang krijgt tot de database. Dit is iets wat je hosting partij wel of niet heeft ingesteld. Op onze webhosting servers staat dit standaard ingeschakeld, het is dus nodig om eerst het IP adres toe te voegen als een vertrouwd adres. Op deze manier wordt je website beveiliging net wat sterker door dubbele controle.

#14 - Installeer een "Web-Application-Firewall" voor je CMS

Doe vooral jezelf een plezier en gebruik een beveiligings-plugin voor je CMS. Hoewel deze plugins vaak niet perfect zijn is het gegarandeerd dat deze plugins een heleboel hoofdpijn kunnen voorkomen. Let echter op dat plugins voor de beveiliging van je CMS geen magie kunnen, je zult zelf nog steeds bezig moeten zijn met de beveiliging van je website.
Een zogenoemde Web Application Firewall is nodig om te compenseren voor de gebreken van je CMS. Elke week worden er wel gaten of exploitatie-mogelijkheden gevonden in de populairdere CMS'en. Vaak is het zo dat de ontwikkelaars van het CMS zelf niet snel genoeg kunnen handelen om deze gaten weer te repareren. De beveiligings-plugins kunnen dit wel (tot op een zekere hoogte) wat ervoor zorgt dat de algemene veiligheid van je website een stuk beter wordt. Hieronder hebben we een lijst met goede plugins.

#15 - Zorg ervoor dat bezoekers geen onbekende bestandstypen kunnen uploaden

In de wereld van het internet moet je er eigenlijk van uit gaan dat alles wat een gebruiker kan invullen of uploaden eng is. Alles wat ingevuld of geüpload kan worden kan namelijk (in principe) ook misbruikt worden. Zeker als het gaat om het uploaden van bestanden moet je uitkijken. Er zijn verschillende manieren waarop een bestandsupload schadelijke gevolgen kan hebben. De meest voorkomende methode is echter via verschillende bestandstypen.

Het is belangrijk dat het uploaden van bestanden alleen mogelijk is voor goedgekeurde bestandstypen. Zo kan je voorkomen dat er een bestand wordt geüpload dat je website of de server schaadt.
Een bestandstype dat je doorgaans wilt voorkomen in uploads is XML. Dat is niet per sé omdat XML gevaarlijk is, maar het is helaas wel makkelijk te misbruiken voor een slimme hacker.
Het is verstandiger om alleen bestandsuploads toe te staan voor typen bestanden die je zelf vertrouwd. Zoals PDF bestanden of simpele tekst bestanden.

#16 - Gebruik systemen voor reacties met ingebouwde anti-spam tools

Spammers kunnen echt een verschrikking zijn. Naast het feit dat je er gek van kan worden kan het ook daadwerkelijk nadelige gevolgen hebben voor je website. De meeste spam berichten staan vol met links naar shady websites. Helaas is het zo dat zoekmachines ook deze reacties kunnen zien en ze vaak meenemen in de indexatie. Dit kan ervoor zorgen dat zoekmachines je gaan zien als een website die actief linkt naar bijvoorbeeld phishing sites. Een daling in de resultaten bij zoekmachines zal direct merkbaar zijn. Het niet bestrijden van spam kan dus serieuze gevolgen hebben voor je SEO.

Er zijn verschillende manieren waarop je spam kunt bestrijden. De makkelijkste manier is zelf niet spam bestrijden. Het is een stuk makkelijker om gebruik te maken van diensten die dit voor je doen. Bovendien levert het meestal betere resultaten op dan je eigen filterregels instellen. Zelf gebruiken we Disqus voor mogelijke reacties op onze artikelen. Disqus heeft ingebouwde anti-spam functies die erg goed werken en is makkelijk om op te zetten.
Heel veel andere "all-in-one" oplossingen zijn er eigenlijk niet wat jammer is. Als je geen oplossing zoals Disqus wilt gebruiken moet je terugvallen op andere systemen voor reacties op artikelen. Dit is nog steeds mogelijk maar moet dan via plugins worden opgelost. Een goede WordPress plugin om spam te bestrijden is Akismet in combinatie met de standaard WordPress reacties. Het is ook mogelijk om te kijken naar oplossingen zoals Google Recaptcha op je website.

#17 - Stel de juiste Server headers in

De laatste tip op onze lijst, en misschien wel gelijk de langste. Server Headers zijn een belangrijk onderdeel van het functioneren van websites. De headers hebben op zichzelf een cruciale rol voor je website, daarom kunnen ze zeer belangrijk zijn voor je website beveiliging. Het leveren van de server headers is praktisch het eerste wat de server doet. Goed ingestelde headers kunnen dus gelijk vertellen wat de computer van een bezoeker wel of niet mag doen. Je kunt zelf je huidige server headers controleren op de site securityheaders.com. Hieronder hebben we de belangrijkste server headers op een rijtje gezet.

De Strict-Transport-Security header

De Strict-Transport-Security header, of afgekort HSTS, is een belangrijke header voor communicatie tussen website en bezoeker. Deze header verteld namelijk aan de computer van een bezoeker dat onbeveiligde communicatie niet is toegestaan. Dit is iets anders dan het doorsturen naar HTTPS. Als je verkeer doorstuurt naar HTTPS dan zegt de server eigenlijk dat de bezoeker naar een ander adres moet. In het geval van de HSTS header doet de computer van de bezoeker dit. De computer van de bezoeker onthoudt namelijk dat alleen HTTPS is toegestaan.

De HSTS header is dus eigenlijk een efficiëntere manier om HTTPS te forceren op je website. Er zit echter één nadeel aan dit systeem: zodra je bent gestart kan je niet meer terug. Meestal is dit echter geen echt probleem, SSL certificaten zijn namelijk makkelijk te verkrijgen.

De X-frame-options header

De x-frame-options header is een belangrijke header om een hackmethode genaamd "clickjacking" tegen te gaan. Het is mogelijk om via een zogenoemd iframe website informatie in te laden op een andere website. In het geval van Clickjacking is dit zeer gevaarlijk. Het is namelijk mogelijk om het uiterlijk van jouw website in te laden maar de links te veranderen. Dit is mogelijk door de manier waarop websites worden ingeladen, dit gebeurt in laagjes. Dit klinkt heel technisch en dat is het helaas ook. De Australische Troy Hun heeft een (technisch) goed artikel geschreven over clickjacking en hoe dit werkt. Je kunt dit artikel hier lezen.

De X-xss-protection header

De X-xss-protection header heeft de functie om XSS aanvallen tegen te gaan. XSS is de afkorting voor Cross Site Scripting, een methode voor hackers om uitvoerbare code te injecteren op je computer. De X-xss-protection header is een configuratie header. Het geeft een instructie aan de computer van de bezoeker wat gedaan moet worden als een XSS aanval wordt gedetecteerd. Onder normale omstandigheden is het geadviseerd om dit in te stellen op blokkeren.

De X-content-type-options header

Dit is de makkelijkste header. Er is namelijk maar één instelling. Als het gaat om communicatie tussen website en bezoeker komt het aan op verschillende soorten content typen. Zo heb je "Stylesheet", "Script", "Document", "png" en zo gaat het nog wel even door. Elke soort content heeft zijn eigen bestands-extensie, zo maakt "Stylesheet" gebruik van het bestand .css.

Met wat originele benamingen is het echter mogelijk om verwarring te creëren tussen website en bezoeker. Stel we nemen een bestand genaamd Voorbeeld.css.js. De website zal zeggen "Het bestand eindigt op JS dus is het een Script", in dit voorbeeld is dit correct.
De browser kan echter zeggen "Er staat CSS in de bestandsnaam dus is het een Stylesheet", in dit voorbeeld is dit incorrect. Ondertussen is hierdoor een conflict ontstaan tussen website en browser.

Dit conflict kan weggewerkt worden door de X-content-type-options header. Deze header geeft namelijk aan dat hetgeen wat de website zegt leidend is. In andere woorden, de website heeft altijd gelijk.
Je kan deze header het beste altijd gebruiken om er zeker van te zijn dat er geen conflicten kunnen optreden.

Hoe kan ik deze server headers instellen?

Je kunt onderstaande code kopiëren en plakken in je .htaccess bestand voor Apache of je vhost bestand voor NGINX.
Let op dat je de juiste code kopiëert.
Controleer de instellingen van deze server headers zelf, de onderstaande voorbeelden zijn standaard instellingen. Dit betekent niet dat de onderstaande voorbeelden goed werken voor jouw website.

#Header configuratie voor Apache
<IfModule mod_headers.c>
        Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    Header always set X-Frame-Options "SAMEORIGIN"
        Header always set X-XSS-Protection "1; mode=block"
    Header always set X-Content-Type-Options: nosniff
</IfModule>
#Header configuratie voor NGINX
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header X-Content-Type-Options "nosniff" always;

Belangrijk om te weten

Goede website beveiliging is voor elke website net anders. Elke website is anders en het vereist nou eenmaal wat moeite om het goed te doen. Er is helaas niet één antwoord op de vraag hoe je je website moet beveiligen.
Als je alle tips in deze lijst hebt behandeld dan ben je zeker goed op weg. Maar blijf bezig met je website en de beveiliging van je website. Het internet veranderd continu en dat betekent dat je mee moet veranderen. Als je niet veranderd wordt het makkelijker voor hackers.
En daar zit natuurlijk niemand op te wachten.

De 5 dingen die je kunt verwachten van WordPress 5

WordPress heeft recentelijk zijn 15e verjaardag gevierd, en in die 15 jaar is er een hele hoop gebeurd. Niet alleen is WordPress uitgegroeid tot het meest gebruikte CMS ter wereld, het heeft ook bewezen dat WordPress meer is dan dat het ooit was. Wat in 2003 startte als een redelijk simpele blogging-tool is gegroeid tot een CMS met misschien wel de meeste mogelijkheden. Grote updates van WordPress hebben altijd nieuwe functies meegebracht en verbeteringen laten zien, maar bij WordPress 5 is er een andere verwachting. De nieuwe update zal namelijk het hart van WordPress aanpassen, de standaard editor gaat weg en de deur gaat open voor Gutenberg.

Er wordt al langere tijd over WordPress 5 gespeculeerd, soms met enthousiasme of juist met angst. De verwachting was dat de nieuwste versie al in mei of april beschikbaar zou zijn, dit zou ook overeenkomen met het normale schema van WordPress versies. Echter, het is nu augustus dus we kunnen met redelijke zekerheid zeggen dat er van het schema wordt afgeweken. En er zijn niet veel aanwijzingen dat WordPress 5 binnen de aankomende paar weken gaat uitkomen. Niet geheel verrassend, want de ontwikkeling van de nieuwste versie heeft een handvol obstakels.

We weten niet zeker wanneer de nieuwe versie 5 uit zal komen, ergens in 2018 is eigenlijk het enige wat zeker is. Als we een voorspelling moeten doen dan zou oktober/november de grootste kans hebben. In de officiële planning is nog steeds geen release datum openbaar gemaakt. Wanneer de nieuwste versie van 's werelds populairste CMS echt uitkomt blijft dus een mysterie. Tot die tijd: onze lijstje met 5 dingen die te verwachten zijn in de aankomende WordPress update.

Update: WordPress 5 is sinds 6 december officieel uitgebracht.

  1. Gutenberg
  2. Beveiliging
  3. Mobiele optimalisatie
  4. Compatibiliteit
  5. Nieuwe Copy/paste API

De Nieuwe Gutenberg editor

De nieuwe Gutenberg editor brengt een hoop commotie met zich mee, niet geheel onterecht. De Gutenberg editor is een gigantische verandering voor WordPress. Met de komst van WordPress 5 wordt er vaarwel gezegd tegen de oude vertrouwde TinyMCE editor. Met Gutenberg wordt de manier hoe je content gebruikt op je website, alles gaat via "blocks".  Gutenberg is zelf al enige tijd beschikbaar als plugin, dus we hebben even een testrit gemaakt met de nieuwe editor.

1. Een compleet nieuw uiterlijk

Het eerste wat opvalt bij de Gutenberg editor is het uiterlijk, net zoals vele andere punten van Gutenberg is dit volledig vanaf de grond opgebouwd. De nieuwe look is zeker een verbetering, het lijkt een beetje op de interface van Medium. De focus wordt echt gelegd op de content, op zichzelf is dit een zeer fijne aanpassing.
Maar helaas heeft het nieuwe uiterlijk ook wat gemiste kansen.

Er mist een hele boel informatie, aan de ene kant is dat fijn en aan de andere kant is het een nachtmerrie. De focus die gelegd wordt op de content is ontzettend goed maar het gaat ten koste van informatie.

Een hele hoop nuttige informatie is verborgen, voornamelijk de informatie die je normaal altijd beschouwd als "niet zo belangrijk". Een voorbeeld is het aantal woorden in een artikel. Zeker informatie als het aantal woorden is erg nuttig tijdens het schrijven van een artikel, het voelt raar om het niet te zien.

Het uiterlijk van de nieuwe Gutenberg editor.

De interface van Gutenberg ziet er mooi uit maar het is zeker wennen simpelweg doordat er veel informatie op het scherm is verstopt op andere plekken. Daarbovenop, Gutenberg doet zelf niet heel veel moeite om te laten zien waar de informatie wél staat. Een voorbeeld is de afbeelding hiernaast, het koste ongeveer 6 pogingen om de afbeelding aan de rechterkant te plaatsen.

2. Alles gaat in blokken

Ja, echt alles gaat in blokken. De meeste tekst kan toegevoegd worden door middel van het paragraaf-blok, Koppen gaan via het kop-blok en zo gaat het nog wel eventjes door. Het gebruik van dit systeem zorgt voor een redelijk overzichtelijke structuur van je content. Daarnaast is het zo dat er automatisch een nieuw paragraaf-blok wordt aangemaakt zodra je op enter drukt.

Het blokkensysteem is overzichtelijk in gebruik en ook redelijk makkelijk, tenzij je iets anders wilt dan kale tekst. Het feit dat écht alles een eigen blok is voelt nogal raar als je bezig bent met het daadwerkelijk opstellen van je artikel of post. Iets waar we gelijk tegenaan liepen was het lijstje met de 5 nieuwe dingen in WordPress 5 bovenaan dit artikel... Nadat we het paragraaf-blok hadden toegevoegd was het tijd om daadwerkelijk het lijstje toe te voegen, maar dat kon niet. Binnen het paragraaf-blok is het niet mogelijk om dingen zoals lijstjes of blokquotes toe te voegen. Dit zijn nu aparte blokken geworden.

Dit specifieke voorbeeld is nogal onschuldig, maar het is gegarandeerd dat het blokkensysteem ergens problemen gaat veroorzaken. Niet omdat het slecht is maar omdat er opnieuw een leercurve is.

Daarnaast is het maar de vraag of de categorieën waarin de blokken zijn ingedeeld wel zo duidelijk zijn. De enige categorieën die we echt logisch vinden zijn "Meest gebruikt", "Layout elementen" en "Widgets". Mede door deze categorieën kan het soms een opdracht zijn om het juiste blok te vinden. Zelf zouden we het niet erg vinden als de categorieën opnieuw worden ingedeeld. Bijvoorbeeld in "tekstblokken" voor alle tekst gebaseerde content, en "media blokken" voor alle media zoals afbeeldingen, audio en bestanden. Zulke kleinen aanpassingen zouden de leercurve wat kunnen verlagen voor Gutenberg.

Het probleem van Gutenberg

Gutenberg is niet slecht. Sterker nog, het is een best aangenaam systeem zodra je over de leercurve heen bent. Die leercurve is waarschijnlijk het grootste probleem als het aankomt op de publieke acceptatie van Gutenberg. Grote kans dat dit ook de reden is waarom Gutenberg een nogal slechte rating krijgt als plugin. Bijna 400 van de +700 beoordelingen is met één ster (4 augustus, 2018).

Is de leercurve het grootste probleem van Gutenberg? Nee.

Er is echter een groter probleem bij Gutenberg dan de leercurve... Namelijk dat er met Gutenberg wordt geprobeerd om een page-builder te zijn. Page-builder plugins zijn niet nieuw voor WordPress en ze zullen in WordPress 5 ook gewoon blijven bestaan. De meest bekende Page-builders zijn Elementor, Beaver Builder en Visual Composer, deze drie plugins samen worden gebruikt op een afgeronde 2 miljoen websites. Het is niet geheel onlogisch dat het team van WordPress zelf de strijd aan wil gaan met deze giga-plugins. Gutenberg heeft echter een gigantische achterstand op deze plugins.

Gutenberg, als Page-builder, heeft geen enkel voordeel over de plugins zoals Elementor of Beaver Builder. Het is helaas op praktisch elk gebied slechter dan deze plugins en is vaak moeilijker in gebruik dan de bestaande plugins. Dat betekend dat Gutenberg een strijd aangaat en nu al verloren heeft. Gutenberg is echter niet zo'n groot drama zoals de beoordelingen laten zien. Voordat WordPress 5 uitkomt is het echter verstandig om zelf ook Gutenberg uit te proberen, download Gutenberg als plugin met de link hieronder.

Beveiliging in WordPress 5

In begin 2017 was er nog serieuze ophef over de veiligheid van WordPress. Het was namelijk mogelijk om de WP REST API te exploiteren. Met de WP REST API is het mogelijk om communicatie met je WordPress website op te zetten, bijvoorbeeld voor applicaties. Gelukkig was dit probleem snel en efficiënt opgelost door het team van WordPress, maar het liet wel weer zien dat een gat in de beveiliging mogelijk is.

De vraag naar verbeterde beveiliging op het internet groeit steeds verder, en WordPress zal met de aankomende versie ook weer verder werken aan de algemene veiligheid van het CMS. Welke acties precies worden ondernomen door het WordPress team is nog niet helemaal duidelijk. Maar helaas is er nog geen hint naar ingebouwde tweestaps-verificatie of minimale wachtwoord sterkte. We kunnen alleen maar hopen dat dit wordt toegevoegd in bijvoorbeeld WordPress 6.

Verbeterde mobiele optimalisatie

De internetwereld van nu is mobiel, en het wordt tijd dat WordPress hier wat meer op aanpast. Responsieve websites waren al een lange tijd mogelijk via WordPress maar het bewerken van websites via mobiel is altijd een redelijke opgave. WordPress 5 moet hier een verandering in gaan brengen. Zo wordt er belooft dat het gebruik van het WordPress Dashboard stukken makkelijker wordt op mobiel. Met verbeterde layout en het wordt makkelijker om nieuwe content via je mobiel aan te maken en te publiceren.

Ook timmert WordPress aan de mobiele variant vanwege druk van o.a. Google. Niet dat ze daadwerkelijk druk hebben uitgeoefend... Maar wel hebben ze al enige tijd geleden de "Mobile First" index aangekondigd.
Dat houdt in dat websites met een goede indeling en optimalisatie voor mobiele apparaten voorkeur krijgen in de Google zoekresultaten. Dat WordPress zelf nu ook bezig is om de code van WordPress te optimaliseren voor mobiele apparaten is dus goed nieuws voor je SEO.

Een drama met compatibiliteit

Dit is waarschijnlijk een van de weinige keren dat we echt het advies geven om te wachten de daadwerkelijke update naar WordPress 5. Zeker twee weken, misschien wel een maand. Aan de andere kant is het meer dan verstandig om nu al verschillende onderdelen van je website te updaten naar de aankomende versie.

Waarom? Omdat WordPress 5 de grootste update zal zijn die het CMS in jaren heeft gezien. Een groot deel van de themas en plugins zullen niet meer werken na de update. Binnen het WordPress team wordt er nog hard gewerkt aan compatibiliteit met huidige plugins maar ondanks dat is er een grote kans dat delen van je website straks niet meer werken. Het zal nog enige tijd duren voordat alle plugins echt compatibel zullen zijn met WordPress 5 en Gutenberg.
Compatibiliteit is geen echt probleem als je gebruik maakt van onze Managed WordPress Hosting, wij controleren na elke update of alles op je website nog wel werkt. Mochten er problemen zijn dan gaan we snel terug naar een vorige versie van je website.

Compatibiliteit was een redelijk groot thema in versie 4.9 van WordPress. Het is dan ook wel te verwachten dat de meeste bekende plugins en themas gewoon compatibel zullen zijn met WordPress 5. Maar sommige complexe plugins zullen wat problemen ervaren, en die problemen zullen ook niet binnen een snelle week zijn opgelost. Er zijn twee dingen die je kunt doen om er nu al achter te komen of je site problemen gaat ervaren.
Namelijk het testen van de Gutenberg plugin of je plugins opzoeken in de grote compatibiliteits-database.

Maar wat nou als je plugins of themas niet goed door één deur gaan met Gutenberg en je wilt wel graag updaten naar WordPress 5?

Dan is er geen paniek nodig. Je kunt nadat je website is geupdate naar WordPress 5 nog terug naar de oude editor door middel van de Classic Editor plugin. De meeste plugins en themas voor WordPress zijn gebonden aan de editor voor functionaliteiten. Indien je website dus niet meer goed werkt dan komt dat door de Gutenberg editor. Dit kan verholpen worden door de Classic Editor plugin te installeren en te activeren, je krijgt hierdoor weer de oude functionaliteiten terug waardoor je plugins en themas weer normaal moeten werken.

Makkelijk kopiëren en plakken met de nieuwe API

Misschien is dit wel een van de minst bekende functies van WordPress 5. Officieel is het onderdeel van Gutenberg, maar eigenlijk is alles van WordPress 5 onderdeel van Gutenberg. Het gaat om kopiëren en plakken. Het varieert uiteraard hoe content geschreven wordt voor je artikelen en blog posts, maar het is niet ongewoon dat je je content ergens anders schrijft en vervolgens plakt in WordPress.

Op het moment is het kopiëren en plakken van content vaak nog een beetje stroef. Het plakken van content in de huidige (oude) editor is namelijk niet goed mogelijk. Tuurlijk, het is mogelijk om alles gewoon in de editor te plakken maar dan is wel je opmaak kwijt. Vervolgens ben je weer onnodig veel tijd kwijt omdat je het hele artikel moet doorspitten en de koppen en subkoppen individueel moet veranderen. De Gutenberg ontwikkelaars zijn het erover eens dat dit niet handig is en anders moet in WordPress 5.

Met WordPress 5 is het mogelijk om volledige bestanden te kopiëren en te plakken naar WordPress zonder dat de opmaak van je tekst wegvalt. Koppen en alinea's worden moeiteloos overgezet naar individuele blokken. Elke kop krijgt zijn eigen kop-blok en ook de onderliggende informatie wordt doorvertaald. Bijvoorbeeld Kop 2 in een word document wordt vertaald naar H2 in WordPress, hetzelfde geldt voor Kop 1 naar H1 enzovoorts. Ook met alinea's wordt goed omgegaan aangezien elke alinea zijn eigen paragraaf-blok krijgt in WordPress.

Het maakt ook niet uit van welke bron je je content kopieert. Of je nou Microsoft Word, Google Docs of een heel ander programma gebruikt om je content te schrijven. Kopiëren en plakken van teksten werkt nu gewoon zoals het hoort te werken.
Het enige wat helaas nog niet kan is het kopiëren en plakken van afbeeldingen vanuit Word of Google Docs, maar wellicht komt dit in een toekomstige update.

Bereid je voor op verandering

Of we het nou willen of niet, Gutenberg komt eraan met WordPress 5. Voor sommigen zal dit een nachtmerrie zijn en voor andere een zeer gewenste update. Hoe dan ook, het komt eraan en het is verstandig om je voor te bereiden.

Ten eerste is het écht meer dan aan te raden om Gutenberg nu al uit te proberen. Doe dit wel op een aparte test site zodat je zeker weet dat er geen conflicten zullen ontstaan. Op die manier weet je zeker of er wel of geen problemen zullen ontstaan met je website als je website wordt geupdate.

Maar wat nou als je er achter komt dat je website en Gutenberg (nog) niet goed mixen? In dit geval is het zeer aan te raden om automatische updates volledig uit te schakelen. Je kunt dit doen door onderstaande lijn code toe te voegen aan het wp-config.php bestand.

define( 'WP_AUTO_UPDATE_CORE', false );

Door deze lijn toe te voegen garandeer je dat je WordPress website in geen enkel geval automatisch overgaat naar WordPress 5, en dus ook niet naar de Gutenberg editor. Zo kun je veilig wachten totdat al je plugins en themas zijn geupdate voordat je verder gaat met WordPress 5.
Plak de lijn zoals in het voorbeeld hieronder:

define( 'WP_DEBUG', false );
define( 'WP_AUTO_UPDATE_CORE', false );
/* That's all, stop editing! Happy blogging. */

Als je gebruik maakt van onze Managed WordPress Hosting dan hoef je je niet veel zorgen te maken over de WordPress 5 update. Er wordt namelijk altijd gecontroleerd of je plugins wel compatibel zijn en of website nog wel goed werkt nadat er een update is uitgevoerd.

Tijd om te relaxen

De update naar WordPress 5 is groot en kan door sommigen gezien worden als onnodig of zelfs vervelend. WordPress moet doorgaan met innoveren, dat is voor het CMS de enige echte manier om zijn plek te behouden of te groeien in de globale CMS markt. Innovatie kan eng zijn, maar niet innoveren is nog veel enger aangezien dat een nog veel groter scala aan problemen meebrengt.

Wees echter goed voorbereid en zorg ervoor dat je site klaar is voor Gutenberg zodat je niet voor verassingen komt te staan. Daarna kan je wat meer relaxen, want WordPress 5 zal niet het einde zijn van je website. En het zal ook niet het einde zijn van WordPress.

Waarom je Google Pagespeed score niet zo belangrijk is

Google PageSpeed Insights wordt zo goed als altijd naar voren gebracht als het gaat om website snelheid. Als website-eigenaar of ontwikkelaar wordt je steeds vaker geconfronteerd met de "need for speed" in de internetwereld. Als website eigenaar weet je al lang dat snelheid super belangrijk is, zeker als je goed wilt scoren in zoekmachines. Een snelle test en er is paniek in de tent, want je site krijgt een slechte score. Maar moet je die score nou wel echt serieus nemen?

De Google PageSpeed score zegt niks over SEO

Het maakt Google zelf niks uit hoe je website naar voren komt in de PageSpeed test. Wat Google als zoekmachine wél belangrijk vindt is de effectieve snelheid van je website, maar daar gaat de PageSpeed test niet over. De Google PageSpeed test moet je zien als een test die laat zien wat er op technisch gebied beter kan. Een hoge score houdt in dat je mogelijke verbeteringen en methodes hebt toegepast. Een lage score houdt in dat er nog methodes zijn die je kunt gebruiken om je website te verbeteren.
Een lage score betekent dus niet dat je website langzaam is of andersom.
Google, als zoekmachine, kijkt heel anders naar je website. Er wordt voornamelijk gekeken naar de daadwerkelijke snelheid van je website in plaats van technische mogelijkheden. Het is dus goed mogelijk dat je website prima zal scoren in Google ondanks een teleurstellende score in de PageSpeed test.

Een 100% score maakt je gek

Als je jezelf echt eventjes goed wilt pesten dan moet je vooral de uitdaging aangaan om een 100% score te halen met je website. Spoiler: met een beetje semi-complexe website gaat het je niet binnen een week lukken.
Sommigen gaan zelfs zo ver om te zeggen dat het "praktisch onmogelijk" is. Voor de duidelijkheid: een 100% score is zeker mogelijk, maar er kan veilig gezegd worden dat het tijdsverspilling is. De score heeft nauwelijks correlatie met daadwerkelijke snelheid, dus waarom zou je?
Google PageSpeed zal enkele adviezen geven waar je helemaal niks mee kan, simpelweg omdat jij als website eigenaar niet altijd alles in handen hebt.
Het beste voorbeeld is nog altijd het advies dat er gebruik gemaakt moet worden van browsercaching op Google Analytics. Dit is iets wat echt alleen Google zelf kan doen, daar gaat dus je score.

Conflicten met het internet van nu

De PageSpeed test geeft een hoop adviezen die zeker een toegevoegde waarde hebben. Toch worden er enkele adviezen gegeven waarvan je moet afvragen of je dit eigenlijk wel moet doen. Voornamelijk het advies over blokkerende Javascript en CSS elementen boven de vouw krijgt steeds vaker vraagtekens in het moderne internet. In principe klopt het advies van Google. Javascript en CSS code dat boven de vouw is geplaatst maakt je website in theorie langzamer. De oplossing? Volgens PageSpeed moet je dus Javascript en CSS verplaatsen naar onder de vouw, of in de footer zoals dit soms genoemd wordt. In de echte wereld is het maar de vraag of dit wel handig is. Het probleem dat Javascript en CSS boven de vouw het laden blokkeren wordt vaak al opgelost door andere technieken zoals het asynchroon laden van de elementen en HTTP/2. Bovendien zal het constant uitstellen van Javascript en CSS een negatieve impact hebben op de gebruikerservaring van je website. En die gebruikerservaring is veel belangrijker dan die 5 milliseconden aan winst.

Moet ik dan de Google PageSpeed test vermijden?

Niet per sé. De Google PageSpeed test is nog steeds een prima tool om de technische kant van je website te testen, maar als het gaat om echt de snelheid van je website dan zijn er betere opties. Een tool die je kunt gebruiken om de daadwerkelijke snelheid van je website te meten is Pingdom, let hierbij wel op dat je Stockholm kiest als testlocatie.
Als je website al binnen anderhalve seconde laadt dan hoef je echt niet wakker te liggen van de PageSpeed score die nog laag is. Google vindt het alleen maar belangrijk dat je website snel is, niet hoe je website snel is. Al is de code van je website een grote puinhoop, als je website binnen een halve seconde laadt dan vindt Google het prima.
Dat betekend echter niet dat je de resultaten van de PageSpeed test moet negeren. Je wilt namelijk wel dat je website enigszins is geoptimaliseerd, alleen die 100% score is een brug te ver.
Probeer als het kan een score te halen van 75 of hoger, met zo'n score ben je er gelijk zeker van dat je website voldoet aan moderne standaarden.

Let er echter op dat de toegepaste technieken ook wel echt een voordeel bieden voor jouw website. Pas geadviseerde methodes alleen toe als de voordelen groter zijn dan de nadelen, en dat verschilt per website.

Feature Spotlight: Eigen Git Repositories

Waar de softwarewereld nu zou staan zonder Git is helaas een vraag die we niet kunnen beantwoorden. Maar het is een feit dat Git de softwarewereld een flink stuk heeft versneld. Sinds 2005 is Git uitgegroeid tot abnormale grootte in de softwarewereld, GitHub heeft alleen al meer dan 85 miljoen repo's. De manier waarop Git is gebouwd heeft voornamelijk gezorgd voor deze gigantisch snelle groei, flexibiliteit en beveiliging in combinatie met snelheid is de samenvatting voor het succesverhaal van Git.

Wat is Git?

Git is niets anders dan een controle systeem voor verschillende versies binnen een software project. Git is constant bezig met het bijhouden van veranderingen, en dat doet het ontzettend goed. Zo houdt Git telkens bij wat er aangepast is, wie dat heeft gedaan en nog veel meer. De volledige historie van een project is terug te vinden, inclusief de eerdere versies van bestanden en de aanpassingen die gemaakt zijn. Dit op zichzelf is al een geweldige combinatie van functies voor software ontwikkelaars en programmeurs, doe daar nog een schepje beveiliging en je hebt een geweldige basis voor een software platform.
Sinds de eerste uitgave in 2005 is het door Linus Torvalds ontwikkelde Git erg ver gekomen, en niet alleen in populariteit. Ook in de functies is Git door de jaren gegroeid naar veruit het meest volwassen platform voor software ontwikkeling.

Git en web development

Ook in de wereld van web development worden git repo's ontzettend vaak gebruikt, het is en blijft immers software ontwikkeling. De internetgiganten van deze wereld zoals GitHub, GitLab en BitBucket bieden de meest geweldige diensten. Ze doen echter maar één ding (en dat doen ze heel goed), en dat is het onderbrengen van repositories. In een industrie zoals web development is dat niet zozeer een probleem, maar wel wat minder efficiënt. De systemen van GitHub, GitLab of BitBucket zijn geen webservers, hierdoor is het niet mogelijk om deze platformen te gebruiken voor dynamische websites. Het maken van een dynamische website zorgt ervoor dat je als ontwikkelaar een inefficiënte werkstroom moet aanhouden. En hetzelfde geldt voor het ontwikkelen van web-applicaties.

Van repository naar productie

In de wereld van web development is het ook vaak gewenst om Git te gebruiken, maar de route van ontwikkeling naar productie is onhandig. Zodra je klaar bent met het ontwikkelen van je site of applicatie is het nodig om deze online te zetten. Je collega heeft net de laatste toevoegingen afgerond dus is het nodig om eerst een repository-pull te doen. En dan ben je nog niet klaar want moet je het project nog uploaden naar de webserver. Met een beetje geluk doet FTP er dan minder dan een halve dag over om de tienduizend bestanden in je project te uploaden. Lang verhaal kort: het werkt wel, maar het is gewoon niet zo handig.

De toevoeging van Git

Om deze route van ontwikkeling naar productie te versnellen is het nu mogelijk om volledige Git repositories onder te brengen op onze webhosting pakketten. Het onderbrengen van de repositories op de webservers zorgt ervoor dat je niet meer afhankelijk bent van protocollen zoals FTP. Een bijkomend voordeel is dat je zelf kunt bepalen hoe je de repositories gaat gebruiken.

Zo is het bijvoorbeeld mogelijk dat de fysieke locatie van de website op de server ook gelijk de repository is. Dit zou ervoor zorgen dat elke commit in de master-branch ook gelijk live komt te staan.
En als dat niet gewenst is met de manier waarop een project ontwikkeld wordt... Dan kan er ingesteld worden dat elke week automatisch een deployment plaats vindt.
Dit zijn maar twee voorbeelden van de mogelijkheden die het onderbrengen van een Git repository op de webservers meebrengen.

De Git functies zijn vanaf vandaag beschikbaar op alle webhosting pakketten.