Leer meer over WordPress core softwarebeveiliging in dit gratis whitepaper. Je kan het ook downloaden in PDF formaat.
![](http://web.archive.org./web/20221001080349im_/https://s.w.org/about/images/logos/wordpress-logo-stacked-rgb.png)
Overzicht
Dit document is een analyse en uitleg van de core software-ontwikkeling van WordPress en de bijbehorende beveiligingsprocessen, evenals een onderzoek van de inherente beveiliging die rechtstreeks in de software is ingebouwd. Beslissers die WordPress beoordelen als een content management systeem of web-applicatie zouden dit document moeten gebruiken in hun analyse en besluitvorming, en voor ontwikkelaars om ernaar te verwijzen om zich vertrouwd te maken met de beveiligingscomponenten en best practices van de software.
De informatie in dit document is up-to-date voor de nieuwste stabiele release van de software, WordPress 4.7 op het moment van publicatie, maar moet ook als relevant worden beschouwd voor de recentste versies van de software, omdat compatibiliteit met eerdere versies een sterke focus is voor het WordPress ontwikkelingsteam. Specifieke beveiligingsmaatregelen en wijzigingen worden genoteerd, omdat deze in specifieke releases aan de core software zijn toegevoegd. Het wordt ten zeerste aangeraden om altijd de laatste stabiele versie van WordPress te gebruiken om de veiligste ervaring mogelijk te maken.
Samenvatting
WordPress is een dynamisch open source contentbeheersysteem waar miljoenen websites, web-applicaties en blogs op draaien. Het wordt momenteel door meer dan43% van de top 10 miljoen websites op internet gebruikt. De bruikbaarheid, uitbreidbaarheid en volwassen ontwikkeling van WordPress maken het een populaire en veilige keuze voor websites van elke omvang.
Sinds de start in 2003 heeft WordPress een voortdurende verharding ondergaan, zodat zijn core software veel voorkomende beveiligingsrisico's kan aanpakken en beperken, waaronder de top 10 lijst die is geïdentificeerd door het Open Web Application Security Project (OWASP) als veelvoorkomende beveiliging kwetsbaarheden, welke in dit document worden besproken.
Het WordPress Security Team, samen met het WordPress Core Leadership Team en ondersteund door de wereldwijde WordPress community, werkt aan het identificeren en oplossen van beveiligingsproblemen in de core software die beschikbaar is voor distributie en installatie op WordPress.org. Daarnaast bevelen ze de aan en documenteren ze beste beveiligingsoplossingen en werkwijze voor plugin en thema auteurs van derde partijen.
Websiteontwikkelaars en beheerders moeten bijzondere aandacht besteden aan het juiste gebruik van de core API's en de onderliggende serverconfiguratie, welke de oorzaak zijn van veelvoorkomende kwetsbaarheden, als ook ervoor te zorgen dat alle gebruikers sterke wachtwoorden gebruiken om toegang te krijgen tot WordPress.
Een overzicht van WordPress
WordPress is een gratis en open source content managementsysteem (CMS). Het is de meest gebruikte CMS-software ter wereld en draait op meer dan 43% van de top 10 miljoen websites1, en heeft daarmee een geschat 62% marktaandeel van alle websites die met een CMS gemaakt zijn.
WordPress is gelicenseerd onder de General Public License (GPLv2 of later), die vier kernvrijheden biedt en kan worden beschouwd als de WordPress “bill of rights”:
- De vrijheid om het programma te draaien voor welk doen dan ook.
- De vrijheid om het programme te bestuden en aan te passen zodat het doet wat jij wilt.
- De vrijheid om te herdistribueren.
- De vrijheid om kopies van jouw aangepaste versies te verspreiden naar anderen.
Het WordPress Core Leadership Team
Het WordPress-project is een meritocratie, geleid door een core leadership team en geleid door zijn founder, Matt Mullenweg. Het team beheert alle aspecten van het project, inclusief core-ontwikkeling, WordPress.org en community initiatieven.
Het Core leadership team bestaat uit Matt Mullenweg, vijf hoofdontwikkelaars en meer dan twaalf core ontwikkelaars met permanente commit toegang. Deze ontwikkelaars hebben de uiteindelijke autoriteit over technische beslissingen en leiden architectuurdiscussies en implementatie-inspanningen.
WordPress heeft een aantal bijdragende ontwikkelaars. Sommige hiervan zijn voormalige of huidige committers, en sommige zijn mogelijk toekomstige committers. Deze bijdragende ontwikkelaars zijn vertrouwde en ervaren bijdragers aan WordPress die veel respect hebben verdiend onder de core ontwikkelaars. Indien nodig heeft WordPress ook gastcommitters, individuen die commit-toegang krijgen, soms voor een specifiek onderdeel, op tijdelijke of proefbasis.
De core en bijdragende ontwikkelaars begeleiden in eerste instantie de ontwikkeling van WordPress. Met elke versie, dragen honderden ontwikkelaars code bij aan WordPress. Deze core bijdragers zijn vrijwilligers die op de één of andere manier bijdragen aan de core codebase.
De WordPress Release Cyclus
Elke WordPress releasecyclus wordt geleid door een of meer van de belangrijkste WordPress ontwikkelaars. Een releasecyclus duurt meestal ongeveer 4 maanden vanaf de eerste scoping vergadering tot de lancering van de versie.
Een release cycle volgt de volgende stappen2:
- Fase 1: het plannen en vastleggen van team leiders. Dit wordt gedaan in de #core chat room op Slack. De release lead bespreekt features voor de volgende release van WordPress met WordPress contributors. De release lead bepaalt dan teamleiders voor elke van deze features.
- Fase 2: het ontwikkelen begint. Teamleiders verzamelen teams en werken aan hun toegekende functies. Er worden regelmatig chats ingeroosterd om er voor te zorgen dat het ontwikkelen voortgang blijft houden.
- Fase 3: Beta. Beta's worden vrijgegeven en beta testers worden verzocht om bugs te rapporteren. Er worden geen commits meer gedaan voor nieuwe verbeteringen of functie aanvragen vanaf deze fase. Plugin en thema auteurs van derde partij worden aangeraden om hun code te testen tegenover de aankomende wijzigingen.
- Fase 4: Release Candidate. Er is een string freeze voor vertaalstrings vanaf dit moment. Het werk heeft vanaf dit moment enkel een focus op regressies en blockers.
- Fase 5: Lancering. De nieuwe WordPress versie wordt vrijgegeven en beschikbaar gemaakt in het WordPress Dashboard voor updates.
Versie nummering Security Releases
Een belangrijke WordPress-versie wordt gedicteerd door de eerste twee reeksen. 3.5 is bijvoorbeeld een belangrijke release, evenals 3.6, 3.7 of 4.0. Er is geen “WordPress 3” of “WordPress 4” en elke major release wordt aangeduid met de nummering, bijvoorbeeld “WordPress 3.9.”
Grote releases kunnen nieuwe gebruikersfuncties en ontwikkelaar APIs toevoegen. Hoewel meestal in de softwarewereld, een “grote” versie betekent dat je compatibiliteit met eerdere versies kan verbreken, WordPress streeft ernaar nooit compatibiliteit met eerdere versies te beëindigen. Backwards compatibiliteit is een van de belangrijkste filosofieën van het project, met het doel om updates veel gemakkelijker te maken voor zowel gebruikers als ontwikkelaars.
Een kleine WordPress-versie wordt gedicteerd door de derde reeks. Versie 3.5.1 is een kleine release, net als 3.4.23. Een kleine release is gereserveerd voor het oplossen van beveiligingskwetsbaarheden en alleen voor het aanpakken van kritieke fouten. Omdat nieuwe versies van WordPress zo vaak worden uitgebracht — het doel is om de 4-5 maanden voor een belangrijke release, en kleine releases vinden plaats wanneer dat nodig is — is er enkel een behoefte aan major en minor releases.
Versie Backwards Compatibility
Het WordPress project is sterk gericht op backwards compatibiliteit. Deze toewijding betekent dat thema's, plugins en aangepaste code blijven functioneren wanneer de core software van WordPress wordt bijgewerkt, waardoor websitebeheerders en eigenaren worden aangemoedigd hun WordPress versie bij te werken naar de nieuwste veilige versie.
WordPress en beveiliging
Het WordPress Security Team
Het WordPress Security Team bestaat ongeveer uit 50 experts waaronder hoofdontwikkelaars en beveiligingsonderzoekers — ongeveer de helft zijn medewerkers van Automattic (makers van WordPress.com, het eerste en grootste WordPress hostingplatform op het web) en een aantal werken op het gebied van webbeveiliging. Het team overlegt met bekende en vertrouwde beveiligingsonderzoekers en hostingbedrijven3.
Het WordPress Security Team werkt vaak samen met andere beveiligingsteams om problemen in gemeenschappelijke afhankelijkheden aan te pakken, zoals het oplossen van de kwetsbaarheid in de PHP XML parser, gebruikt door de XML-RPC API die wordt geleverd met WordPress, in WordPress 3.9.24. Deze kwetsbaarheidsresolutie was het resultaat van een gezamenlijke inspanning van zowel WordPress als Drupal beveiligingsteams.
WordPress veiligheidsrisico's, processen en geschiedenis
Het WordPress Security Team gelooft in verantwoordelijke openbaarmaking door het beveiligingsteam onmiddellijk op de hoogte te stellen van mogelijke kwetsbaarheden. Potentiële kwetsbaarheden in de beveiliging kunnen via het netwerk worden gemeld aan het Beveiligingsteam WordPress HackerOne5. Het Beveiligingsteam communiceert onderling via een privé Slack kanaal en werkt aan een ommuurde, persoonlijke Trac voor het traceren, testen en oplossen van bugs en beveiligingsproblemen.
Elk beveiligingsrapport wordt bij ontvangst bevestigd en het team werkt aan het verifiëren van de kwetsbaarheid en het vaststellen van de ernst ervan. Als dit wordt bevestigd, plant het beveiligingsteam vervolgens een patch om het probleem op te lossen dat kan worden gepleegd voor een komende release van de WordPress software of kan worden gepusht als een onmiddellijke beveiligingsrelease, afhankelijk van de ernst van het probleem.
Voor een onmiddellijke beveiligingsrelease wordt door het beveiligingsteam een advies gepubliceerd op de WordPress.org News website6 als aankondiging van de release en detaillering van de wijzigingen. Credit voor de verantwoordelijke bekendmaker van een kwetsbaarheid wordt in het advies gegeven om verdere verantwoordelijke rapportage in de toekomst te stimuleren en te versterken.
Beheerders van de WordPress software zien een melding op het dashboard van hun website om te upgraden wanneer een nieuwe release beschikbaar is en na de handmatige upgrade worden gebruikers geredirect naar het Over WordPress scherm waarin de wijzigingen worden beschreven. Als beheerders automatische achtergrondupdates hebben ingeschakeld, ontvangen ze een e-mail nadat een upgrade is afgerond.
Automatische Updates op de achtergrond voor Security Releases
Vanaf versie 3.7 introduceerde WordPress geautomatiseerde achtergrondupdates voor alle kleine releases7, zoals 3.7.1 en 3.7.2. Het WordPress Security Team kan geautomatiseerde beveiligingsverbeteringen voor WordPress identificeren, repareren en pushen zonder dat de eigenaar van de website iets hoeft te doen aan zijn kant, de beveiligingsupdate zal automatisch worden geïnstalleerd.
Wanneer een beveiligingsupdate wordt gepubliceerd voor de huidige stabiele versie van WordPress, zal het core team ook beveiligingsupdates publiceren voor alle releases die achtergrondupdates kunnen verwerken (sinds WordPress 3.7). Daarmee ontvangen deze oudere, maar nog steeds recente versies van WordPress, nog steeds beveiligingsverbeteringen.
Individuele website eigenaren kunnen ervoor kiezen om automatische achtergrondupdates te deactiveren middels een eenvoudige wijziging in hun configuratiebestand, maar het in stand houden van deze functionaliteit wordt sterk aanbevolen door het core team, evenals het draaien van de laatste stabiele release van WordPress.
2013 OWASP Top 10
Het Open Web Application Security Project (OWASP) is een online community die zich richt op beveiliging van webtoepassingen. De OWASP top 10 lijst8 richt zich op het identificeren van de serieuste beveiligingsrisico's van applicaties voor een breed scala aan organisaties. De top 10 items worden geselecteerd en geprioriteerd in combinatie met consensus schattingen van de exploiteerbaarheid, detecteerbaarheid en impactinschattingen.
In de volgende secties worden de API's, bronnen en beleidsregels besproken die WordPress gebruikt om de kernsoftware en plugins en thema's van derden te versterken tegen deze potentiële risico's.
A1 - Injection
Er zijn een reeks functies en APIs beschikbaar in WordPress om ontwikkelaars te helpen te voorkomen dat niet-geautoriseerde code kan worden geïnjecteerd en om te helpen gegevens te valideren en op te schonen. Beste werkwijzen en documentatie zijn beschikbaar9 over hoe deze APIs te gebruiken om in- en uitvoer gegevens te valideren en opschonen in HTML, URLs, HTTP headers en bij interactie met de database en het bestandssysteem. Beheerders kunnen ook verder beheren welke bestandstypes kunnen worden geüpload via filters.
A2 - Broken Authentication and Session Management
WordPress core-software beheert gebruikersaccounts en verificatie alsook details zoals het gebruikers-ID, de naam en het wachtwoord worden op de server opgeslagen, evenals de authenticatiecookies. Wachtwoorden worden beschermd in de database met behulp van standaard salting en stretching technieken. Bestaande sessies worden bij het uitloggen vernietigd vanaf WordPress 4.0.
A3 - Cross Site Scripting (XSS)
WordPress biedt een reeks functies die ervoor kunnen zorgen dat door gebruikers geleverde gegevens veilig is10. Vertrouwde gebruikers dat betekent de beheerders en redacteuren op een WordPress installatie en superbeheerders in een WordPress Multisite, kunnen ongefilterde HTML of JavaScript publiceren in een bericht of pagina. Onvertrouwde gebruikers en door gebruikers ingediende inhoud worden standaard gefilterd om gevaarlijke entiteiten te verwijderen, met behulp van de KSES library via de wp_kses
functie.
Als een voorbeeld merkte het core team van WordPress vóór de release van WordPress 2.3 op dat de functie the_search_query()
verkeerd werd gebruikt door de meeste themabouwers door de output van die functie niet te escapen in de HTML. In een zeer zeldzaam geval van enigszins backwards compatability te verbreken werd de uitvoer van de functie in WordPress 2.3 gewijzigd zodat de output automatisch werd geëscaped.
A4 - Insecure Direct Object Reference
WordPress biedt regelmatig directe objectreferentie, zoals unieke numerieke IDs van gebruikersaccounts of inhoud die beschikbaar is in de URL- of formuliervelden. Hoewel deze IDs directe systeeminformatie bevatten, is WordPress haar rijke rechten en toegang controlesystemen voorkomen ongeautoriseerde aanvragen.
A5 - Security Misconfiguration
Het merendeel van de WordPress beveiligingsconfiguratiewerkzaamheden zijn beperkt tot één bevoegde beheerder. Standaardinstellingen voor WordPress worden continu geëvalueerd door het WordPress Core team en dit team biedt documentatie en aanbevolen procedures aan om de beveiliging in serverconfiguraties voor het draaien van een WordPress website aan te scherpen11.
A6 - Gevoelige Data Exposure
WordPress wachtwoorden voor gebruikersaccounts worden salted en gehashed op basis van het Portable PHP Password Hashing Framework12. WordPress haar toestemmingssysteem wordt gebruikt om toegang tot privé-informatie te regelen zoals geregistreerde gebruikers PII, e-mailadressen van reageerders, privé gepubliceerde inhoud, enz. In WordPress 3.7 werd een wachtwoordsterktemeter toegevoegd tot de core software waarmee aanvullende informatie aan gebruikers word verstrekt tijdens het instellen van wachtwoorden en hints over het vergroten van de sterkte hiervan. WordPress heeft ook een optionele configuratie instelling voor het vereisen van HTTPS.
A7 - Ontbrekende Function Level Access Control
WordPress controleert eerst de juiste autorisatie en toestemmingen voor toegangverzoeken op alle functieniveaus vooraleer de actie wordt uitgevoerd. Toegang of visualisatie van administratieve URL's, menu's en pagina's zonder de juiste authenticatie is nauw geïntegreerd met het authenticatiesysteem om toegang door onbevoegde gebruikers te voorkomen.
A8 - Cross Site Request Forgery (CSRF)
WordPress maakt gebruik van cryptografische tokens, nonces genaamd13, om de geldigheid van verzoeken van geautoriseerde gebruikers te beschermen tegen mogelijke CSRF bedreigingen. WordPress biedt een API voor het genereren en verifiëren van unieke en tijdelijke tokens. Het token is beperkt tot een specifieke gebruiker, een specifieke actie, een specifiek object en een specifieke tijdsperiode, die toegevoegd kan worden aan formulieren en URL's indien nodig. Daarnaast worden alle nonces ongeldig gemaakt bij het afmelden.
A9 -Het gebruik van Components met Known Vulnerabilities
Het core team van WordPress volgt nauwgezet de weinige opgenomen libraries en frameworks die WordPress integreert voor core functionaliteit. In het verleden heeft het core team bijdragen aan verschillende onderdelen van derden om deze beter te beveiligen, zoals de update naar een cross-site kwetsbaarheden in TinyMCE in WordPress 3.5.214.
Indien nodig kan het coreteam beslissen kritieke externe componenten te forken of te vervangen. Bijvoorbeeld wanneer de SWFUpload-library officieel werd vervangen door de Plupload-library in 3.5.2 en een veilige vork van SWFUpload beschikbaar werd gesteld door het beveiligingsteam <15voor die plugins die SWFUpload op korte termijn bleven gebruiken.
A10 - Ongevalideerde Redirects en Forwards
Het interne toegangs- en authenticatiesysteem van WordPress beschermt tegen pogingen om gebruikers naar ongewenste bestemingen door te sturen. Deze functionaliteit is ook beschikbaar gemaakt voor plugin ontwikkelaars via de wp_safe_redirect()
16 API.
Verdere veiligheidsrisico's en -zorgen
XXE (XML eXternal Entity) processing attacks
Bij het verwerken van XML schakelt WordPress het laden van aangepaste XML entiteiten uit om aanvallen van zowel de External Entity and Entity Expansion te voorkomen. Naast PHP haar kernfunctionaliteit, biedt WordPress geen extra beveiligde XML verwerking API voor plugin auteurs.
SSRF (Server Side Request Forgery) aanvallen
HTTP aanvragen door WordPress worden gefilterd om toegang tot loopback en privé IP adressen te voorkomen. Daarnaast is toegang alleen toegestaan voor bepaalde HTTP poorten.
WordPress plugin en thema veiligheid
Het standaard thema
WordPress vereist dat een thema in inhoud zichtbaar in de frontend kan redeneren. Het standaard thema dat met WordPress komt (momenteel "Twenty Twenty-Two") is intensief beoordeeld en getest om veiligheidsredenen, zowel door het team van thema ontwikkelaars en het core ontwikkelaars team.
Het standaard thema kan dienen als een startpunt voor custom thema ontwikkeling, en site ontwikkelaars kunnen subthema's bouwen die aanpassingen bevatten maar terugvallen op het standaard thema voor de meeste functionaliteit en veiligheid. Het standaard thema kan gemakkelijk verwijderd worden door een beheerder, als het niet nodig is.
WordPress.org Thema en Plugin repositories
Er zijn ongeveer 50.000+ plugins en 5.000 thema's beschikbaar op de WordPress.org site. Deze thema's en plugins worden ingezonden voor opname en worden handmatig beoordeeld door vrijwilligers voordat ze beschikbaar worden gemaakt op de repository.
Plugins en thema's zijn niet gevrijwaard van van veiligheidslekken wanneer ze in de repository staan. Er zijn richtlijnen voor plugin auteurs om te raadplegen voor inzending naar de repository17, en uitgebreide documentatie over WordPress thema ontwikkeling18 is beschikbaar op de WordPress.org website.
Elke plugin en thema kan door de plugin- of thema eigenaar verder ontwikkeld worden. Elke fix of ontwikkelde feature kan worden geüpload naar de repository en beschikbaar worden gemaakt voor gebruikers met die plugin of thema en een omschrijving van de verandering. Website beheerders worden op de hoogte gesteld van plugins die geüpdate moeten worden via hun admin panel.
Wanneer het WordPress veiligheidsteam een veiligheidslek in een plugin ontdekt, nemen ze contact op met de plugin auteur om samen te werken aan de oplossing en het uitbrengen van een veilige versie van de plugin. Als de plugin auteur niet reageert, of het een ernstig veiligheidslek betreft. wordt de plugin/thema uit de publieke map gehaald en, in sommige gevallen, direct gerepareerd en geüpload door het veiligheidsteam.
Het Thema Review Team
Het Theme Review Team is a groep van vrijwilligers, geleid door gerenommeerde leden van de WordPress community, die nieuwe thema's die ingediend zijn bij de officiële WordPress Thema directory reviewen en goedkeuren. Het Theme Review Team onderhoudt ook de officiële Theme Review Guidelines19, de Theme Unit Test Datas20, de Theme Check Plugins21 en onderhoud de WordPress Theme developer community met betrekking tot best practices voor het ontwikkelen van thema's. Ledenbeheer is gemodereerd door core committers van het WordPress ontwikkel team.
De rol van het webhostingbedrijf m.b.t. WordPress Security
WordPress kan geïnstalleerd worden op een grote verscheidenheid van platformen. Ondanks dat de WordPress core software op vele manieren een veilige web applicatie verzorgd, is de configuratie van de server software bij een web host minstens zo belangrijk als het gaat om WordPress applicaties veilig te houden.
Een opmerking over WordPress.com en WordPress security
WordPress.com is de grootste WordPress installatie ter wereld en is van Automattic, Inc., opgericht door Matt Mullenweg, de mede-oprichter van het WordPress project. WordPress.com draait op de core WordPress software, en heeft haar eigen veiligheidsprocessen, risico's en oplossingen22. Dit document verwijst naar veiligheid met betrekking tot de zelf gehoste en downloadbare open source WordPress software beschikbaar vanaf WordPress.org welke op elke server in de wereld geïnstalleerd kan worden.
Appendix
Core WordPress API's
De WordPress Core Application Programming Interface (API) bestaat uit verschillende APIs23. Samen vormen ze de project interface door middel van plugins en thema's met de WordPress core functionaliteit interacteren op een veilige manier.
Elke WordPress API verzorgt best practices en biedt gestandariseerde manieren om met de WordPress core software te werken, maar de volgende WordPress API's zijn het meest belangrijk als het gaat om het implementeren van WordPress security:
Database API
De Database API24, toegevoegd in WordPress 0.71, verzorgd de correcte methode om gegevens zoals named values uit de database laag te halen.
Filesystem API
De Filesystem API25, toegevoegd in WordPress 2.626, was oorspronkelijk geschreven voor de automatische updates van WordPress zelf. De Filesystem API regelt de functionaliteit die er nodig is om veilig bestanden te lezen en weg te schrijven in het lokale bestandsysteem voor een grote verscheidenheid van hosting configuraties.
Het doet dit door middel van het WP_Filesystem_Base
class, en verschillende subclasses die verschillende manieren implementeren om te verbinden met het lokale bestandssysteem, rekening houdend met je server. Elk thema of plugins die lokaal bestanden wil wegschrijven moet dit doen met de WP_Filesystem verzameling van classes.
HTTP API
De HTTP API27, toegevoegd in WordPress 2.728 en uitgebreid in WordPress 2.8, standariseert de HTTP requests voor WordPress. De API behandeld cookies, gzip encoding en decoding, chunk decoding (indien HTTP 1.1), en overige andere HTTP protocol implementaties. De API standariseert requests, test elke method voordat het verstuurd en, gebaseerd op je serverconfiguratie, gebruikte de correcte method om het request te doen.
Rechten en huidige gebruiker API
De toegangsrechten en current-user-API29 bestaat uit een verzameling van functies die de rechten van een gebruiker verifiëren wanneer er deze een taak wil uitvoeren. Op worden acties die buiten de toegestane rechten vallen tegengehouden.
Whitepaper inhoud licentie
De tekst in dit document (exclusief het WordPress logo of handelsmerk) valt onder het CC0 1.0 Universal (CC0 1.0) Public Domain Dedication handelsmerk. Je kan het kopiëren, bewerken en verspreiden, zelfs voor commerciële doeleinden, zonder dat je hiervoor toestemming nodig hebt.
Een speciaal dankwoord voor het whitepaper over veiligheidvan Drupal, voor de geboden inspiratie.
Extra leesmateriaal
- WordPress nieuws https://wordpress.org/news/
- WordPress Security releases https://wordpress.org/news/category/security/
- Bronnen voor WordPress ontwikkelaars https://developer.wordpress.org/
Geschreven door Sara Rosso
Bijdragen van Barry Abrahamson, Michael Adams, Jon Cave, Helen Hou-Sandí, Dion Hulse, Mo Jangda en Paul Maiorana
Versie 1.0 Maart 2015
Voetnoten
- [1] https://w3techs.com/, as of December 2019
- [2] https://make.wordpress.org/core/handbook/about/release-cycle/
- [3] https://make.wordpress.org/core/handbook/about/release-cycle/version-numbering/
- [4] https://wordpress.org/news/2014/08/wordpress-3-9-2/
- [5] https://hackerone.com/wordpress
- [6] https://wordpress.org/news/
- [7] https://wordpress.org/news/2013/10/basie/
- [8] https://www.owasp.org/index.php/Top_10_2013-Top_10
- [9] https://developer.wordpress.org/plugins/security/
- [10] https://codex.wordpress.org/Data_Validation#HTML.2FXML
- [11] https://wordpress.org/support/article/hardening-wordpress/
- [12] https://www.openwall.com/phpass/
- [13] https://developer.wordpress.org/plugins/security/nonces/
- [14] https://wordpress.org/news/2013/06/wordpress-3-5-2/
- [15] https://make.wordpress.org/core/2013/06/21/secure-swfupload/
- [16] https://developer.wordpress.org/reference/functions/wp_safe_redirect/
- [17] https://wordpress.org/plugins/developers/
- [18] https://developer.wordpress.org/themes/getting-started/
- [19] https://make.wordpress.org/themes/handbook/review/
- [20] https://codex.wordpress.org/Theme_Unit_Test
- [21] https://wordpress.org/plugins/theme-check/
- [22] https://automattic.com/security/
- [23] https://codex.wordpress.org/WordPress_APIs
- [24] https://developer.wordpress.org/apis/handbook/database/
- [25] https://codex.wordpress.org/Filesystem_API
- [26] https://wordpress.org/support/wordpress-version/version-2-6/
- [27] https://developer.wordpress.org/plugins/http-api/
- [28] https://wordpress.org/support/wordpress-version/version-2-7/
- [29] https://developer.wordpress.org/reference/functions/current_user_can/