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.

Algemene Beoordeling
- Indien je een gratis SSL certificaat gebruikt moet de algemene beoordeling minimaal een B+ zijn.
- Als je een betaald SSL certificaat gebruikt moet de algemene beoordeling minimaal een A zijn.
Configuratie
- De ondersteunde protocollen moeten TLS 1.1, TLS 1.2 of TLS 1.3 zijn. Het protocol TLS 1.0 raden we af aangezien dit ondertussen verouderd is.
- Let op dat onder "Cipher suites" niets staat aangegeven als zwak of onveilig.
- Onder het kopje "Handshake simulation" mag niets aangegeven staan in oranje of rode letters.
- Bij "Protocol details" mag niets aangegeven staat in oranje of rode letters.

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

Alle mappen moet ingesteld zijn met code 755 of 750
Normale bestanden moeten ingesteld zijn met code 644 of 640
Configuratie bestanden moeten ingesteld zijn met code 440 of 400
Er mag geen enkele map zijn met code 777

#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.

Gutenberg
Beveiliging
Mobiele optimalisatie
Compatibiliteit
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.

#WordPress 5 gaat met #Gutenberg de strijd aan met Page-builders maar de score staat nu al op 0-2 achterstand voor Team WP" quote="WordPress gaat met Gutenberg de strijd aan met de Page-builders maar begint gelijk met een flinke achterstand Click to Tweet

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.

Klik hier om Gutenberg te downloaden

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.

Google Analytics en de GDPR (AVG)

De “General Data Protection Regulation” komt steeds dichterbij en daarom is het van belang dat ondertussen ook jouw website hier en daar moet veranderen.

De GDPR, of in het nederlands “Algemene verordening gegevensbescherming” (AVG), is een wet binnen de EU die een hoop veranderingen met zich meebrengt, de wet is namelijk niet alleen regelgeving maar brengt ook veranderingen in verschillende definities rondom persoonsgegevens. Dit zorgt er ook voor dat je verandering aan zult moeten brengen in de manier waarop je gegevens verzameld via bijvoorbeeld Google Analytics.

In het geval van Google Analytics en persoonsgegevens zijn er twee veranderingen:

IP adressen worden nu gezien als persoonsgegevens.
Pseudo-identiteitsgegevens zoals een klant-id worden gezien als traceerbare gegevens.

Punt twee is een beetje een vaag punt en heeft meer te maken met gerichte advertenties dan enkel het verzamelen van gegevens, de regels rondt dit punt verschillen per type website en wat je met deze informatie doet speelt uiteraard ook mee.

Binnen de GDPR (en even alle uitzonderingen weg denken) is het noodzaak dat punt één moet worden geanonimiseerd en dat een overeenkomst wordt aangegaan met Google voor gegevensbewerking.

De overeenkomst voor gegevensbewerking en het delen van gegevens

De eerste stap om je google analytics GDPR-proof te maken is een overeenkomst afsluiten met Google voor gegevensbewerking. Deze overeenkomst houdt in dat Google de geanonimiseerde data mag verwerken. Zonder deze overeenkomst is het niet toegestaan om Google Analytics te gebruiken onder de GDPR, gelukkig is het afsluiten van deze overeenkomst hartstikke makkelijk gemaakt. Om te starten klik je op beheer (rechtsonder) in je Google Analytics dashboard en navigeer je vervolgens naar je accountinstellingen (bovenaan de linkerkolom). Binnen deze instellingen kun je naar beneden scrollen tot “Aanpassing van de gegevensverwerking” om hier de huidige status van je overeenkomst te zien. Klik op de knop “Aanpassing bekijken” en volg de stappen op het scherm om de overeenkomst aan te gaan. Naast de overeenkomst gegevensverwerking is het ook noodzakelijk dat je als website eigenaar stopt met het delen van Google-analytics gegevens met Google. Onder de nieuwe wetten is dit niet toegestaan zonder dat je expliciet een akkoord hebt van je websitebezoeker. Het stopzetten van gegevens delen is ook mogelijk in je accountinstellingen (vlak boven het vak over de gegevensverwerking overeenkomst), zorg ervoor dat er geen enkel vakje over blijft met een vinkje erin. Het switchen naar de Google Tag Manager

Dit is niet een verplichting en ook niet super noodzakelijk. Maar het aangeven aan Google welke gegevens wél of juist niet verzameld moeten worden is vele malen makkelijker via dit systeem.

Het is dus even aanpassen en een klein beetje tijd steken in het gebruiken van de Tag Manager maar dat zal ervoor zorgen dat je in de toekomst stukken makkelijker veranderingen kunt toepassen op je website, een bijkomend voordeel is dat de code van je website niet constant aangepast hoeft te worden.

De Google Tag Manager is te bereiken via de volgende link: https://tagmanager.google.com/?hl=nl#/home

Er wordt eerst gevraagd om een account en een “container” op te zetten. Het is hierbij verstandig om voor beide je website naam te gebruiken zoals op de afbeelding.

Vervolgens krijg je van Google 2 stukjes die je moet implementeren op je website. We hebben een kort stappenplan opgezet hoe je dit kunt doen op een standaard WordPress website. Download en installeer de plugin “Header and Footer scripts” op je WordPress website. Kopieer en plak de Google-code aangegeven met in het bovenste vak binnen de plugin. Kopieer en plak de Google-code aangegeven met in het onderste vak binnen de plugin. Sla de instellingen op. Verwijder nu je oude Google Analytics implementatieMeestal is dit via een plugin zoals MonsterInsights, dit heb je nu niet meer nodig en kun je dus verwijderen van je WordPress installatie.

De Google Tag Manager werkt met “Tags” en “Triggers”, dat klinkt heel gecompliceerd maar eigenlijk houdt het in dat jij als beheerder precies kunt aangeven wanneer welke data wordt verzameld op basis van een gebeurtenis. Hiermee kun je bijvoorbeeld aangeven dat Google Analytics data verzameld vanaf het eerste moment dat een website wordt bezocht maar dat een tool zoals Hotjar pas begint met opnemen zodra iemand op een specifieke knop drukt, dit biedt ontzettend veel vrijheid in de gegevens die je kunt verzamelen. Het beste hiervan is dat dit mogelijk is zonder dat je verder de code van je website hoeft aan te passen, het stukje Google code is genoeg.

De Tags en Triggers kun je zo gecompliceerd maken als je zelf wilt, nu houden we het redelijk simpel met enkel Google Analytics en het anonimiseren van IP adressen.

Het instellen van Google Analytics in de Google Tag Manager

Het werken met Google Tag Manager is even wennen, veel aspecten zijn nieuw en anders opgebouwd dan de traditionele Google producten zoals Analytics of Adwords.

Zodra je de code van Google Tag Manager hebt geïnstalleerd kom je (als het goed is) op het controlepaneel van de Tag Manager terecht, dit wordt je Werkruimte genoemd.

Je hebt verschillende werkruimtes per domein of applicatie dus let goed op dat je de juiste werkruimte hebt geselecteerd als je meerdere domeinen en/of applicaties inzet.

We starten met het maken van een nieuwe “Tag”, er komt nu een nieuw menu naar voren om deze Tag een naam te geven en in te stellen.

Het is handig om je Tag een duidelijke naam te geven van wat het is en doet, bijvoorbeeld “Google Analytics tag”.

Hierna is het zaak om de tag in te stellen en te configureren. Je ziet twee vakken:

Het bovenste vak genaamd “Tagconfiguratie”
Het onderste vak genaamd “Triggers”

Om een nieuwe Tag te kiezen kun je gewoon ergens in het bovenste vak klikken, een nieuw menu komt naar voren om een keuze te maken uit de beschikbare tags.

In dit menu kiezen we voor “Universal Analytics, Google Analytics”.

Nadat de tag volledig is ingeladen kun je verder met het configureren.

Het is noodzaak om de tag eerst te linken aan je gewenste Google Analytics profiel, hiervoor heb je het Google Analytics Tracking ID nodig. Het Google Analytics Tracking ID kun je in het dashboard van Google Analytics vinden: Klik binnen Google Analytics op de knop “beheerder”, en klik vervolgens op “JS-tracking info” (middelste kolom). Helemaal bovenaan deze pagina is je Tracking Identificatie voor Google Analytics te vinden, het ziet er uit als “UA-999999999-9”. Kopieer deze code, je zult hem zometeen nodig hebben in de Tag Manager. Terug in de Tag Manager kan er gestart worden met het configureren van de Google Analytics Tag. Klik op het veld “Tagconfiguratie” om de instellingen aan te passen, je ziet nu velden voor het tracking type en de google analytics instellingen. In het veld bij “Google Analytics-instellingen” staat nu een tekst zoals “variabele voor instellingen selecteren”, dit veld gaan moeten we veranderen, klik op het veld en selecteer “nieuwe variabele”. Er komt nu een nieuw menu naar voren om de Google Analytics instellingen aan te passen, geef de variabele een gewenste naam en plak je Google Analytics Tracking-ID in het daarvoor bedoelde vak. Sla de instellingen echter nog niet op. Het is nu de bedoeling dat we data gaan anonimiseren zoals de IP adressen. Dit kan binnen hetzelfde menu onder “Meer instellingen”. Selecteer vervolgens “Velden die moeten worden ingesteld” en voeg het volgende veld toe: “anonymizeIp” met waarde “true” Vul dit veld in met de waarde zoals op de onderstaande afbeelding. De configuratie kan nu opgeslagen worden, je keert terug naar het menu van je Tag waar de volgende stap is om een “Trigger” in te stellen. Dit is simpel te doen door op het onderste veld (genaamd “Triggers”) te klikken. In het geval van Google Analytics is er maar een trigger mogelijk, een pageview trigger. Zodra je de Pageview trigger hebt geselecteerd kun je de aangemaakte tag opslaan. Je nieuw gemaakte tag is nu opgeslagen maar nog niet actief, om je tag te activeren moet nog één knop aangeklikt worden: De verzendknop op je dashboard.

Iets opslaan betekent in de Google Tag Manager niet dat iets ook direct actief wordt. De Google Tag Manager is gemaakt met de gedachte dat meerdere personen binnen een team het gebruiken om veranderingen toe te passen, daarom komen de veranderingen eerst in een overzicht terecht zodat de eindverantwoordelijke alles nogmaals kan inzien en kan goedkeuren. Als website eigenaar zul je echter alle rollen in dit traject zelf uitvoeren. Door simpelweg op de knop “verzenden” te drukken worden je aanpassingen geactiveerd. Je Google Analytics data is nu correct ingesteld met geanonimiseerde IP adressen.

Let op! De GDPR is enorm complex en het is daarom niet mogelijk om één artikel te maken dat voor iedereen klopt. Maak je gebruik van complexere integraties zoals Google Analytics + Adwords remarketing/Doubleclick, dan kunnen we alleen adviseren om contact op te nemen met een juridisch adviseur om specifiek te kijken wat wel of niet mag.

De Meltdown en Spectre kwetsbaarheden in processoren

4 Januari 2018, het jaar is nog maar net begonnen en de computerwereld wordt gelijk hevig door elkaar geschud door onderzoekers van onder andere Google Project Zero. In de documentatie wordt duidelijk gemaakt dat praktisch alle moderne processoren een cruciale optimalisatiefout bevatten waardoor het mogelijk wordt om geheugendata te lezen die eigenlijk helemaal niet toegankelijk hoort te zijn. Deze optimalisatietechniek wordt "Speculative Execution" genoemd en houdt in dat een processor taken verwerkt die misschien helemaal niet nodig zijn, de gedachte hierachter is om het werk uit te voeren voordat het bekend is of het werk nodig is. Dat klinkt misschien als een ontzettende verspilling van processorgebruik maar in werkelijkheid zorgt het ervoor dat bijna alle applicaties sneller kunnen werken.

Zo goed als alle processoren van nu gebruiken deze techniek, dat betekent eigenlijk dat alle apparaten met een processor een kwetsbaarheid hebben. Dit geldt voor alle servers op aarde tot die fancy smart-koelkasten. Alle apparaten die maar een beetje kunnen nadenken zijn potentieel kwetsbaar.

Hoe erg is het?

Verschillende onderzoeksinstituten hebben ondertussen concepten gepubliceerd die deze kwetsbaarheden exploiteren en aan het licht brengen. Zeker het Oostenrijkse Graz University of Technology (was ook aan boord tijdens het onderzoeksproces naar deze kwetsbaarheden) heeft meerdere Concepten gepubliceerd waarin deze kwetsbaarheden in actie te zien zijn. Zo is het mogelijk om het processorgeheugen uit te lezen wachtwoorden te stelen (zie onderstaande video).

Een Meltdown demo waarin live wachtwoorden bekeken kunnen worden. Credit Michael Schwarz van de Graz Universiteit of Technology.

Maatregelen voor deze kwetsbaarheden zijn onderweg voor verschillende systemen. De grote systeemontwikkelaars van deze wereld zijn al wat eerder op de hoogte gebracht zodat er op de achtergrond aan een oplossing gewerkt kon worden. De maatregelen zijn nog erg beperkt en verschillen per systeem maar onder andere Windows, Apple, Google, Mozilla, Android en RedHat zijn langzaam maar zeker updates aan het uitrollen die de Meltdown-kwetsbaarheden in een soort quarantaine zetten.

Helaas, de updates zijn niet zonder consequenties. De techniek waar het allemaal fout gaat is een optimalisatie techniek van de processorfabrikanten, dit betekent dat het oplossen van deze fout ten koste zal gaan van systeem prestaties. Over tijd zal deze impact op snelheid wel weg gewerkt worden maar vanwege de urgentie is het niet mogelijk om een super geoptimaliseerde update uit te brengen.

Wees dus de komende tijd extra alert op updates van je computers, telefoons, tablets, smart-tv en je koelkast.

Updaten is altijd belangrijk. Soms is het oké om een update uit te stellen voor een paar dagen, deze keer niet. Update zo snel mogelijk.

Meltdown

Door een Meltdown-aanval krijgt een aanvaller volledig inzicht in het geheugen van een systeem en wat de processor op het moment aan het verwerken is, hierdoor kunnen zeer gevoelige gegevens van het besturingssysteem en andere applicaties opeens bekeken worden.
Voor zover bekend hebben alle Intel processoren van ná 1995 deze kwetsbaarheid (op Intel Atom processoren na). AMD en ARM processoren worden nog nader onderzocht en het is nog niet definitief duidelijk of Meltdown van toepassing is op de processoren van deze fabrikanten.
Software updates om Meltdown te neutraliseren worden op dit moment uitgegeven door verschillende systeemontwikkelaars, deze software updates zijn door sommige ontwikkelaars al uitgegeven of worden op korte termijn uitgegeven.

Spectre

De Spectre kwetsbaarheid houdt in dat code uit een andere applicatie geforceerd kan worden uitgevoerd terwijl deze code normaal niet zou worden uitgevoerd. Hierdoor is het mogelijk om vertrouwelijke informatie te lekken.

Voor zover bekend zijn alle processoren van Intel, AMD en ARM kwetsbaar voor dit lek. Het is echter wel zo dat een Spectre aanval een stuk gecompliceerder is dan een Meltdown aanval, helaas is het daarmee ook lastiger om te neutraliseren. Op het moment zijn er nog geen consequent werkende maatregelen tegen Spectre.

De vervolgstappen bij Niqex

We houden alles zeer nauwlettend in de gaten om mogelijke oplossingen zo snel mogelijk toe te passen.
We hebben op het moment hotfixes klaar staan om de Meltdown kwetsbaarheid te neutraliseren, deze updates worden deze avond (5 januari) toegepast op onze servers.

Het is echter mogelijk dat deze updates een negatieve impact zullen hebben op de prestaties van onze systemen, het is helaas niet te voorspellen hoe deze impact zal zijn. Mocht het zo zijn dat deze updates daadwerkelijk resulteren in slechtere prestaties dan willen we hier graag bij voorbaat onze excuses voor aanbieden.

We zijn van mening dat databeveiliging een absolute top-prioriteit is, snelheid ten koste van beveiliging is geen optie.

Wat is nieuw in WordPress 4.9

WordPress 4.9 is officieel uitgekomen en is de tweede en laatste grote update van het CMS in 2017. Versie 4.9 met codenaam "Tipton" brengt een gevarieerde combinatie van nieuwe functies naar WordPress die voor sommigen ontzettend handig zullen zijn en voor anderen misschien wat minder, wellicht zitten er in deze update geen functies die voor jou echt van belang zijn maar ook achter de schermen laat WordPress 4.9 een hoop verbeteringen zien.
Het was al van te voren aangekondigd dat deze update niet de focus zou leggen op de aankomende Gutenberg editor, Gutenberg zal nog even moeten wachten tot volgend jaar waar deze (waarschijnlijk) in WordPress 5.0 wordt toegevoegd. Deze update van WordPress gaat niet over Gutenberg maar ondanks dat is het wel duidelijk dat de fundering voor Gutenberg wordt neergelegd.

Hierbij de nieuwe functies en verbeteringen in WordPress 4.9

Let op voordat je gaat updaten naar de nieuwe versie! Maak altijd eerst een backup.

Het nieuwe inplannen van veranderingen

Het inplannen van berichten en zelfs pagina's is niks nieuws voor WordPress, het is erg gebruikelijk om een nieuwe blogpost aan te maken en vervolgens deze in te plannen zodat het bericht automatisch zichtbaar wordt op het moment dat jij het wilt.

Iets wat wél nieuw is in dit systeem is dat je nu veranderingen kunt inplannen op bestaande pagina's en berichten. Dit is perfect voor het veranderen van bestaande pagina's zonder dat je je website verkeer negatief beïnvloedt. Met deze nieuwe inplan-methode is het mogelijk om massale veranderingen te maken aan meerdere pagina's en deze tegelijkertijd zichtbaar maken. Een gebruiksvoorbeeld is een webshop die nieuwe artikelen wilt aankondigen op de site, er kunnen achter de schermen veranderingen worden gemaakt op de pagina's en deze worden ingepland om allemaal zichtbaar te worden op exact hetzelfde tijdstip.

Deel je concepten

Een nieuwe functie van WordPress 4.9 is dat je opgeslagen concepten van pagina's en berichten kunt delen met anderen zonder dat je je pagina of bericht ook echt hoeft te publiceren. WordPress is namelijk nu in staat om specifieke URL's te genereren speciaal voor het delen van concepten. Superhandig als je samen met je collega, familie of buurman je site in elkaar wilt zetten. Samenwerking wordt een stuk makkelijker met deze functie.

Nieuwe widgets

Er zijn twee grote veranderingen in de widgets van WordPress 4.9. In versie 4.8 van WordPress zagen we al de introductie van media widgets waarmee afbeeldingen, video en audio toegevoegd konden worden aan je pagina's of berichten. WordPress 4.9 gaat hiermee verder en introduceert de galerij widget. Afbleeding galerijen direct in WordPress zonder de noodzaak van plugins is een hele verbetering.

Het is nu ook mogelijk om media elementen toe te voegen in de Text widgets van WordPress. Dat betekent dat je afbeeldingen, audio en video gemakkelijk in je text widgets kunt plaatsen zonder hier complexe structuren van te maken.

Makkelijker veranderen van thema's

Hoewel het niet de meest spannende toevoeging is van WordPress 4.9, het is toch wel een verbetering die welkom is en voor sommige gebruikers zal dit een enorme verbetering zijn.
Het installeren van nieuwe thema's gaat nu stukken makkelijker vanuit de WordPress customizer, in vorige versies bleek de installatie van thema's via de customizer niet erg soepel te gaan en dit zorgde dan ook vaak voor problemen.
Behalve dat de installatie van thema's soepeler gaat is WordPress nu ook in staat om de geplaatste widgets over te brengen naar het nieuwe thema. De tijd van verloren widgets na een thema verandering is over.

Fout-notificaties en syntax highlighting

Na acht jaar is CodeMirror terug in WordPress. CodeMirror is een implementatie die code scant, kleurt en fouten zichtbaar maakt. Als je op je website gebruik maakt van eigen CSS en/of JavaScript dan is dit misschien wel de beste toevoeging aan WordPress van dit jaar. Hoe vaak komt het wel niet voor dat je op opslaan drukt nadat je net je nieuwe stuk CSS voor je website hebt toegevoegd en je mist helaas net ergens een puntkomma. Uren hoofdpijn terwijl je aan het zoeken naar die éne fout in je code zijn over met deze implementatie die de fouten en verbeteringen aangeeft zodat je sneller door kunt met het volgende punt van je website.

Niet alleen maakt het je code een stuk overzichtelijker, het systeem zal ook weigeren met opslaan als er een fout in de code staat. De dagen dat je pagina's niet meer werken omdat er per ongeluk een fout staat in de code zijn over.

Geen zin in deze toevoeging? Dan is het makkelijk ook weer uit te schakelen in je profiel.

Dat concludeert eigenlijk wel zo'n beetje de nieuwe toevoegingen en verbeteringen. Er zijn zeker nog een hele hoop extra verbeteringen toegevoegd maar deze zijn voornamelijk onder de motorkap te vinden. Optimalisaties van enkele Javascript bibliotheken, betere API's en minder afhankelijkheid van jQuery zullen ervoor zorgen dat WordPress een stuk sneller zal zijn in deze nieuwe versie en in toekomstige versies.

HTTP/2, de nieuwe koning van het internetverkeer

Het HyperText Transfer Protocol, ofwel HTTP, bestaat al ontzettend lang. De doorgaans gebruikte versie van HTTP is versie 1.1 wat sinds 1997 bestaat.

HTTP is één van de vele ruggengraten die het internet kent maar het protocol dat de afgelopen 20 jaar is gebruikt is oud. HTTP1.1 werkt maar is niet langer optimaal en heeft verschillende limieten die we in 2017 écht niet willen. Modern uitziende websites hebben tegenwoordig een grootte en complexiteit waarmee HTTP1.1 erg veel moeite heeft. Het ooit zo revolutionaire protocol uit 1997 moet plaats maken voor iets nieuws. Sinds 2015 bestaat dat nieuwe protocol genaamd HTTP/2.

Het grote probleem van HTTP1.1

Het grootste probleem in met huidige moderne websites en HTTP1.1 is dat elk 'element' een nieuwe verbinding moet maken met de server. Als jouw website 3 Javascript bestanden en 2 CSS bestanden moet inladen dan worden er 6 verschillende verbindingen opgezet naar de server (basis aanvraag meegerekend). Een beetje grote website gaat al snel richting de 30-40 aanvragen per pagina en het helpt dan niet dat ook nog eens je browser het aantal verbindingen tot een server limiteert.
Hoe meer verschillende elementen op je website pagina hoe meer vertraging je oploopt. Hierbij komt vaak kijken dat data gaat opstapelen waar het niet hoeft, een goed voorbeeld hiervan is cookies. Cookies worden alke keer opnieuw verstuurd terwijl dit eigenlijk maar één keer nodig is.

Het ontstaan van HTTP/2 en de voordelen

Dat HTTP1.1 inefficiënt is voor de complexere websites was al langer bekend, Google is daarom na veel onderzoek begonnen met een eigen internetprotocol genaamd SPDY (speedy). SPDY is maar voor een korte tijd gebruikt en was grotendeels exclusief voor Google diensten. Met name Gmail en Google maps maakten gebruik van SPDY. Google's SPDY heeft de basis neergelegd voor het huidige HTTP/2, en veel van de functionaliteiten zijn ook overgenomen. Met name Google en Microsoft zijn betrokken geweest met de productie van HTTP/2 maar ook andere techgiganten zoals Facebook en Cisco hebben drastische bijdragen geleverd aan het project.

Multiplexing

HTTP/2 maakt gebruik van een techniek die Multiplexing genoemd wordt. Waar HTTP1.1 meerdere verbindingen moest opzetten om bestanden op te vragen van een server kan dit nu over één verbinding, dat scheelt ontzettend in tijd. Daarbovenop kan de server ook nog de volgorde bepalen waarin de bestanden gestuurd moeten worden over deze verbinding, bijvoorbeeld éérst CSS en daarna Javascript bestanden. En om het nog mooier te maken, de bestanden worden ook nog in kleine stukjes geknipt. Het voordeel hiervan is dat meerdere bestanden tegelijkertijd door de server verstuurd kunnen worden over dezelfde verbinding. Dat zorgt voor minder wachttijd en een betere datastroom.

Het verschil tussen HTTP1.1 en HTTP/2. Credit: WPMUDEV

Server Push

Een andere functie die HTTP/2 biedt is Server Push, in het kort houdt dit in dat de server alvast bestanden naar je browser stuurt nog voordat je browser hier om heeft gevraagd.

"Welkom op deze website, dit is de HTML en hier heb je alvast de benodigde CSS en Javascript bestanden" ~ een HTTP/2 server

Zonder Server Push vraagt je browser de HTML op van een website, deze HTML heeft meerdere verwijzingen naar andere bestanden op de server en vervolgens vraagt je browser aan de server: "Mag ik die andere bestanden ook hebben?".

Dat laatste stukje van communicatie is niet meer nodig met Server Push, de bestanden zijn namelijk al van te voren naar je browser gestuurd. Het voornaamste doel van Server Push is het terugdringen van website laadtijden.

Helaas zitten er nog wel wat kronkels in het principe van Server Push, het grootste probleem is dat minder goed werkt met dynamische content op websites. Daarbovenop moet de website eigenaar zelf aangeven bij de server welke bestanden gebruik kunnen maken van Server Push, het is dus niet een automatisch systeem voor alle bestanden.

Een binair protocol

HTTP1.1 is ooit gemaakt met de gedachte dat ook mensen het moeten kunnen begrijpen, HTTP/2 is het daar niet mee eens en is volledig binair. In andere woorden, het bestaat enkel uit 01010101. HTTP/2 is gemaakt met de gedachte dat computers het snel moeten begrijpen, het doel van HTTP/2 is immers dat het voor de eindgebruiker sneller wordt. Het grote voordeel is dat de data sneller verstuurd wordt en ook sneller verwerkt kan worden door de ontvangende computer, nadeel is dat het écht een hel is om te debuggen.

Niqex en HTTP/2

Het heeft even geduurd... Maar alle webhosting pakketten die we aanbieden hebben vanaf nu ondersteuning voor HTTP/2.

Werkt het dan ook voor mijn site?

Als je een SSL certificaat hebt dan ja. Gelukkig krijg je die gratis van ons dus dat is ook een zorg minder. Wij zorgen ervoor dat alle websites die over HTTP/2 kunnen draaien dat ook doen.

Verder blijft HTTP1.1 gewoon beschikbaar voor alle websites die geen gebruik maken van SSL/HTTPS.

Ga ook van start met HTTP/2 webhosting

Wat is SSL en waarom is het nodig?

Startend bij de basis: SSL staat voor Secure Sockets Layer, het is dé implementatie voor beveiligde verbindingen als het gaat om internetverkeer en daarmee voornamelijk het verkeer tussen je computer en de website die je bezoekt.

De naam SSL kom je misschien niet heel vaak tegen maar het is de drijvende kracht achter een afkorting die wél erg bekend is, namelijk HTTPS. HTTPS zie je tegenwoordig overal en dat is maar goed ook want dat houdt in dat het internet steeds iets veiliger wordt.

Oké, maar wat doet SSL nou eigenlijk?

Het fundament van SSL bestaat eigenlijk uit twee processen:

Authenticatie
Encryptie

De combinatie van deze twee functies zorgt ervoor dat de website die je bezoekt kan aangeven dat het wel écht de website is die je wilt bezoeken en dat de verbinding tussen je computer en de website versleuteld is.

Zowel de authenticatie en encryptie nemen meestal maar enkele milliseconden in en worden beide op de achtergrond geregeld vlak voordat de website die je bezoekt wordt geladen.

De eerste stap is authenticatie, dit gebeurt met een zogeheten SSL-handshake. Tijdens deze ‘handdruk’ worden certificaten uitgebreid gecontroleerd. Deze controle vindt plaats op zowel de server van de website als op je eigen computer. Op deze manier kan er worden bepaald of jij als bezoeker veilig bent voor de server en of de server veilig is voor jou als bezoeker.

Hierna begint het proces van encryptie, dit gebeurt met zogenoemde sleutels en een hele hoop wiskundige formules. Als we alle technische praat weghalen dan komt het encryptieproces ongeveer op het volgende neer:

De informatie van de website wordt uit elkaar gehaald
De uit elkaar gehaalde informatie wordt gemanipuleerd door de wiskundige formules
De gemanipuleerde informatie wordt opgestuurd naar de website bezoeker
De computer van de websitebezoeker kan de informatie weer kloppend maken en in elkaar zetten.

Als ook maar één deel van alle bovenstaande stappen niet klopt dan blokkeert het hele HTTPS protocol en krijg je als bezoeker een error te zien. Dit kun je zelf zien op de website badssl.com, hier hebben ze allemaal voorbeelden van foute HTTPS verbindingen.

En wat is daar het praktisch nut van?

Het grootste voordeel van de encryptie is dat alle informatie die uitgewisseld wordt tussen de bezoeker en server absoluut onleesbaar wordt voor iedereen die een poging waagt om mee te kijken.

Als je verbinding met een website over HTTP is in plaats van HTTPS dan is het toch echt te adviseren om geen betalingsgegevens in te vullen maar deel ook je mailadres niet. Het is namelijk mogelijk dat daardoor gegevens worden gestolen doordat iemand meekijkt met je sessie. Het gebeurt misschien niet zo vaak, maar het is mogelijk en dat is al reden genoeg om SSL en HTTPS erg serieus te nemen.

Geen enkele site hoort nog zonder encryptie, doe mee met #HTTPSeverywhere samen met @LetsEncrypt 🛡 Click to Tweet

Moeten alle websites dan over SSL/HTTPS? Ook mijn blog?

Ja.

Heel veel meer valt er eigenlijk niet te zeggen over het wel of niet hebben van SSL/HTTPS. Of je nou een webshop hebt of een klein blog, SSL/HTTPS is de standaard tegenwoordig.

Er zijn een hoop andere websites of blogs die beweren dat je als kleine particuliere site geen HTTPS nodig hebt maar daar zijn we het gewoon echt niet mee eens. HTTPS heeft namelijk geen enkel nadeel behalve van een vertraging op je website van ~50 milliseconden of zelfs minder.

Sterker nog, HTTPS levert nog een extra voordeel bovenop de beveiliging! Het grote internet-orakel genaamd Google heeft in 2014 al aangegeven dat website met HTTPS automatisch een betere positie krijgen in de zoekresultaten dan websites zonder HTTPS. En niet alleen Google doet dit, ondertussen zijn alle andere zoekmachines zoals Bing en Yahoo meegegaan met dit initiatief. Het is dus naast beveiliging ook nog een zeer belangrijk SEO punt.

Nog meer nuttige dingen?

Jazeker.

Een SSL certificaat (en daarmee dus HTTPS) is nodig om gebruik te kunnen maken van HTTP/2.

HTTP/2 is een relatief nieuw internetprotocol dat we gratis ondersteunen op al onze webhosting pakketten, HTTP/2 verminderd vertragingen met websites enorm en kan ervoor zorgen dat jouw website veel snellere laadtijden heeft dan andere websites. Lees meer over HTTP/2

Wat voor SSL certificaat moet ik dan kiezen en hoe start ik ermee?

SSL certificaten bestaan in verschillende soorten en maten tegenwoordig, het perfecte certificaat voor jouw website is echt afhankelijk van jouw site en doel.

Bij onze webhosting pakketten krijg je gratis SSL certificaten van LetsEncrypt, deze certificaten zijn goed genoeg voor de meeste websites en we installeren ze ook nog voor je website, die optie is dus volledig kosteloos en is een prima oplossing om SSL/HTTPS op je website te krijgen.

Zodra je website groeit is het (soms) echter verstandig om een SSL certificaat mee te laten groeien. Als je enkel een blog hebt dan is het meestal niet nodig om veel te investeren in een SSL certificaat, het gratis LetsEncrypt certificaat wat je van ons krijgt is dan meestal voldoende, mocht je dat zelf echter niet genoeg vinden dan zijn er redelijk goedkope SSL certificaten beschikbaar met garantie.

Ook mijn website is beveiligd met @LetsEncrypt #HTTPSeverywhere 🛡 Click to Tweet

Voor grotere websites, bedrijven en webshops is het echter een ander verhaal, als je website net nieuw is dan is het gratis SSL certificaat nog gewoon voldoende maar na een tijdje is de website gaan groeien en krijg je meer bezoekers. Als je een bedrijfswebsite hebt of een webshop dan wil je uiteraard vertrouwen uitstralen met je website. Op dat moment komen de grotere SSL certificaten in beeld, zeker het zogenoemde 'Extended Validation' SSL certificaat zorgt voor extra vertrouwen bij je bezoekers. Het Extended Validation certificaat, of korter; EV, zorgt ervoor dat de bedrijfsnaam bovenin de URL-balk te zien is. Deze certificaten zijn absoluut onkraakbaar en kunnen ongelofelijk belangrijk zijn om je online identiteit te beschermen, zeker als je al redelijk wat websitebezoekers hebt.

De wereld van SSL certificaten kan echter lastig zijn om doorheen te werken en certificaten komen in veel verschillende vormen en maten. Weet je niet wat voor certificaat je nodig hebt? Stuur ons dan een berichtje, we geven je graag advies voor de beste certificaten die aansluiten bij jouw doelen.