WordPress.org

About

Security

Seguretat

Més informació sobre la seguretat del programari del nucli del WordPress en aquesta documentació. També podeu baixar-la en format PDF.

Resum

Aquest document és una anàlisi i explicació del desenvolupament del programari principal del WordPress i els processos de seguretat relacionats, així com un examen de la seguretat inherent integrada directament al programari. Els qui prenen decisions que avaluen el WordPress com un sistema d’administració de contingut o un entorn de treball d’aplicació web, han d’usar aquest document en l’anàlisi i presa de decisions, i els desenvolupadors referir-se a ell per familiaritzar-se amb els components de seguretat i les millors pràctiques del programari.

La informació en aquest document està actualitzada per a l’última versió estable del programari, el WordPress 4.7 al moment de la publicació, però ha de considerar-se rellevant també per a les versions més recents del programari, ja que la compatibilitat amb versions anteriors és un enfocament important per a l’Equip de desenvolupament de WordPress. Les mesures de seguretat específiques i els canvis s’anotaran a mesura que s’hagin afegit al nucli del programari en versions específiques. Es recomana encaridament executar sempre l’última versió estable del WordPress per garantir l’experiència més segura possible.

Resum executiu

WordPress és un sistema dinàmic de gestió de contingut de codi obert que s’utilitza per impulsar milions de llocs web, aplicacions web i blocs. Actualment, alimenta més de 43% dels 10 milions de llocs web més importants d’Internet. La usabilitat, l’extensibilitat i la madura comunitat de desenvolupament de WordPress el converteixen en una opció popular i segura per a llocs web de totes les mides.

Des de la seva ideació l’any 2003, el WordPress ha anat millorant de manera constant de forma que el nucli del programari pugui resoldre i mitigar amenaces de seguretat comunes, incloses les 10 identificades a la llista de l’Open Web Application Security Project (OWASP) com a vulnerabilitats de seguretat comunes, que es discuteixen en aquest document.

L’equip de seguretat del WordPress, en coŀlaboració amb l’equip de lideratge dels components centrals del WordPress i recolzat per la comunitat global del WordPress, treballa per identificar i resoldre els problemes de seguretat al programari principal, disponible per a la distribució i instaŀlació a WordPress.org, així com per recomanar i documentar les millors pràctiques de seguretat per als autors d’extensions i temes de tercers.

Els desenvolupadors i administradors del lloc han de prestar especial atenció a l’ús correcte de les API principals i la configuració del servidor subjacent que han estat l’origin de vulnerabilitats comuns, així com garantir que tots els usuaris emprin contrasenyes segures per accedir al WordPress.

Una visió general del WordPress

WordPress és un sistema de gestió de continguts (CMS) de codi obert i gratuït. És el programari CMS més utilitzat al món i alimenta més de 43% dels 10 milions de llocs web principals1, donant-li una quota de mercat estimada del 62% de tots els llocs que utilitzen un CMS.

El WordPress està llicenciat sota la Llicència Pública General (GPLv2 o posterior), que proporciona quatre llibertats fonamentals, i es pot considerar com la “declaració de drets” del WordPress:

  1. La llibertat d’executar el programa, per a qualsevol propòsit.
  2. La llibertat d’estudiar com funciona el programa i canviar-ho perquè faci el que vulgueu.
  3. La llibertat de redistribuir.
  4. La llibertat de distribuir còpies de les versions modificades a uns altres.

L’equip que lidera el nucli del WordPress

El projecte WordPress es basa en la meritocràcia: executat per un equip de lideratge principal i dirigit pel co-creador i desenvolupador líder, Matt Mullenweg. L’equip determina tots els aspectes del projecte, incloen el desenvolupament del nucli, WordPress.org i les iniciatives de la comunitat.

L’equip de direcció del Core, o del nucli, consisteix de Matt Mullenweg, cinc desenvolupadors líders i més de mitja dotzena de desenvolupadors del nucli amb accés permanent per a fer canvis. Aquests desenvolupadors tenen autoritat final en decisions tècniques, i lideren les discussions d’arquitectura i els esforços d’implementació.

El WordPress té una sèrie de desenvolupadors contribuents. Alguns d’aquests són antics o actuals que pugen canvis, i alguns són probablement futurs desenvolupadors que pujaran. Aquests desenvolupadors contribuents són coŀlaboradors confiables i veterans del WordPress que s’han guanyat un gran respecte entre els seus companys. Segons sigui necessari, el WordPress també compta amb convidats que pugen canvis, persones a les quals se’ls atorga accés per pujar canvis, de vegades per a un component específic, de forma temporal o de prova.

Els desenvolupadors principals i contribuents guien principalment el desenvolupament del WordPress. Cada versió, centenars de desenvolupadors contribueixen amb el codi de WordPress. Aquests col·laboradors principals són voluntaris que contribueixen d’alguna manera al codi.

El cicle de versions del WordPress

Cada cicle de llançament del WordPress està dirigit per un o més dels desenvolupadors centrals del WordPress. Un cicle de llançament generalment dura al voltant de 4 mesos des de la reunió inicial d’abast fins al llançament de la versió.

Un cicle de versió segueix el patró següent2:

  • Fase 1: Planificació i assegurament de líders d’equip. Això es fa a la sala de xat #core en Slack. El líder de la versió analitza les característiques de la propera versió del WordPress. Els coŀlaboradors de WordPress s’involucren amb aquesta discussió. El líder de llançament identificarà els líders de l’equip per a cadascuna de les funcions.
  • Fase 2: comença el treball de desenvolupament. Els líders d’equip reuneixen equips i treballen en les funcions assignades. Els xats regulars estan programats per garantir que el desenvolupament segueixi avançant.
  • Fase 3: Beta. Es llancen betes i se’ls demana als beta-testers que comencin a reportar errors. A partir d’aquesta fase, no es realitzen més confirmacions per a millores o sol·licituds de funcions noves. Es recomana als autors d’extensions i temes de tercers que provin el seu codi en relació amb els propers canvis.
  • Fase 4: Versió candidata. Hi ha una congelació de cadenes per a cadenes traduïbles a partir d’aquest punt. El treball està dirigit a regressions i bloquejadors solament.
  • Fase 5: Llançament. La versió de WordPress es llança i es posa a disposició en l’administrador de WordPress per a actualitzacions.

Numeració de versions i versions de seguretat

Una versió major del WordPress ve determinada per les dues primeres seqüències. Per exemple, la 3.5 és una versió major, igual que la 3.6, la 3.7 o la 4.0. No hi ha un «WordPress 3» o un «WordPress 4» i cada versió major es denomina pel seu número, per exemple, «WordPress 3.9».

Les versions principals poden afegir noves funcions d’usuari i API de desenvolupador. Tot i que normalment al món del programari, una versió “major” significa que podeu trencar la compatibilitat cap enrere, WordPress s’esforça per no trencar mai la compatibilitat cap enrere. La compatibilitat cap enrere és una de les filosofies més importants del projecte, amb l’objectiu de facilitar molt les actualitzacions tant als usuaris com als desenvolupadors.

Una versió menor del WordPress ve determinada per la tercera seqüència. La versió 3.5.1 és una versió menor, igual que la 3.4.23. Una versió menor es reserva només per a la correcció de vulnerabilitats de seguretat i la resolució d’errors crítics. Com les noves versions del WordPress es publiquen amb tanta freqüència — l’objectiu és fer una versió principal cada 4-5 mesos i les versions menors es publiquen quan cal — només hi ha la necessitat de versions principals i menors.

Compatibilitat amb versions anteriors

El projecte WordPress té un compromís molt fort amb la compatibilitat cap enrere. Aquest compromís vol dir que temes, extensions i codi personalitzat continuarà funcionant quan s’actualitzi el nucli del WordPress, encoratjant els propietaris de llocs web a mantenir la seva versió de WordPress actualitzada a l’última versió segura.

WordPress i seguretat

L’equip de seguretat del WordPress

L’equip de seguretat del WordPress està format per aproximadament 50 experts, inclosos desenvolupadors principals i investigadors de seguretat: aproximadament la meitat són empleats d’Automattic (fabricants de WordPress.com, la primera i més gran plataforma d’allotjament de WordPress a la web), i diversos treballen en el camp de la seguretat web. L’equip consulta amb investigadors de seguretat coneguts i de confiança i empreses d’allotjament3.

L’equip de seguretat del WordPress sovint col·labora amb altres equips de seguretat per abordar problemes en dependències comunes, com ara resoldre la vulnerabilitat a l’analitzador XML de PHP, utilitzat per l’API XML-RPC que ve amb WordPress, al WordPress 3.9.24. Aquesta resolució de vulnerabilitats va ser el resultat d’un esforç conjunt dels equips de seguretat de WordPress i Drupal.

Riscs de seguretat, procés i historial del WordPress

L’equip de seguretat del WordPress creu en la divulgació responsable alertant l’equip de seguretat immediatament de qualsevol vulnerabilitat potencial. Les vulnerabilitats de seguretat potencials poden ser indicades a l’equip de seguretat a través del WordPress HackerOne5. L’equip de seguretat es comunica entre si a través d’un canal privat de l’Slack, i treballa en un Trac privat i emmurallat per a seguiment, proves i per a la correcció d’errors i problemes de seguretat.

Cada informe de seguretat es contesta en rebre’l i l’equip treballa per verificar la vulnerabilitat i determinar-ne la severitat. Si es confirma, l’equip programa la correcció del problema, la qual es publicarà a la propera versió del WordPress o, si es tracta d’un a vulnerabilitat greu, prepararà una versió de seguretat immediata.

Per a la publicació immediata d’una versió de seguretat, l’equip de seguretat publica un avís a la secció de notícies de WordPress.org6 anunciant la versió i detallant els canvis. En l’avís es dona crèdit per a la divulgació responsable d’una vulnerabilitat per a encoratjar i reforçar la presentació continuada d’informes responsables en el futur.

Els administradors d’un WordPress veuen una notificació a l’escriptori recomanant-los actualitzar el lloc web quan hi ha una nova versió disponible. Després d’una actualització manual, es redirigeix a l’usuari a una pàgina amb informació detallada sobre els canvis. Si les actualitzacions automàtiques estan activades, els administradors rebran un correu en completar-se una actualització notificant-los-hi.

Actualitzacions automàtiques en segon pla per a les versions de seguretat

A partir de la versió 3.7, el WordPress va introduir actualitzacions automatitzades en segon pla per a totes les versions menors7, com ara 3.7.1 i 3.7.2. L’equip de seguretat del WordPress pot identificar, arreglar i llançar millores de seguretat automatitzades per al WordPress sense que el propietari del lloc web hagi de fer res, d’aquesta manera l’actualització de seguretat s’instal·larà automàticament.

Quan es publica una actualització de seguretat per a la versió actual del WordPress, l’equip del nucli també publica actualitzacions de seguretat per a totes aquelles versions que suporten les actualitzacions automàtiques (des de la 3.7) per tal que totes les versions recents rebin les millores de seguretat.

Els propietaris de llocs web poden desactivar les actualitzacions automàtiques canviant una opció del fitxer de configuració, però es recomana mantenir-les activades, així com executar la versió estable més actual del WordPress.

Top 10 de l’OWASP 2013

El Open Web Application Security Project (OWASP) és una comunitat en línia dedicada a la seguretat de les aplicacions web. La llista OWASP Top 108 se centra en identificar els riscos de seguretat més greus per a una àmplia gamma d’organitzacions. Els 10 elements principals són seleccionats i prioritzats en combinació amb les estimacions de consens d’explotabilitat, detectabilitat i impacte.

Les següents seccions tracten les API, recursos i polítiques que utilitza el WordPress per protegir el nucli i les extensions i temes d’aquests riscos potencials.

A1 – Injecció

Hi ha un conjunt de funcions i API disponibles al WordPress per ajudar els desenvolupadors a assegurar-se que no es posible injectar codi no autoritzat, i ajudar-los a validar i sanejar les dades. Hi ha disponibles bones pràctiques i documentació9 sobre com utilitzar aquestes API per protegir, validar o sanejar les dades d’entrada i sortida en l’HTML, URL, capçaleres HTTP, i quan s’interactua amb la base de dades i el sistema de fitxers. Els administradors també poden restringir els tipus de fitxers que es poden pujar a través de filtres.

A2 – Gestió de sessions i autenticació trencada

El nucli del WordPress gestiona els comptes d’usuari i l’autenticació, de tal manera que els detalls d’un usuari com el seu ID, el nom o la contrasenya es gestionen al propi servidor. Les contrasenyes es protegeixen a la base de dades utilitzant els mètodes habituals de «salting» i «stretching». A partir de la versió 4.0, les sessions actives es destrueixen en tancar la sessió.

A3 – Cross Site Scripting (XSS)

El WordPress proporciona una gamma de funcions que poden ajudar a garantir que les dades subministrades per l’usuari siguin segures10. Els usuaris de confiança, és a dir, administradors i editors en una instal·lació individual del WordPress, i els administradors de la xarxa només per al WordPress multilloc, poden publicar HTML o JavaScript segons ho necessitin, com ara dins d’una entrada o pàgina. Els usuaris no fiables i el contingut enviat per l’usuari es filtra per defecte per eliminar entitats perilloses, utilitzant la biblioteca KSES a través de la funció wp_kses 

Per exemple, l’equip del nucli del WordPress es va adonar abans del llançament del WordPress 2.3 que la funció the_search_query() estava sent mal emprada per a la majoria dels autors de temes, que no escapaven de la sortida de la funció per al seu ús en HTML. En un cas molt rar de trencar lleugerament la compatibilitat amb versions anteriors, la sortida de la funció es va canviar al WordPress 2.3 per a ser escapada prèviament.

A4 – Referència directa insegura a un objecte

El WordPress sovint proporciona referències directes a objectes, com ara identificadors numèrics únics de comptes d’usuari o contingut disponible en els camps d’URL o formulari. Mentre que aquests identificadors revelen informació directa del sistema, els permisos enriquits del WordPress i el sistema de control d’accés eviten sol·licituds no autoritzades.

A5 – Mala configuració de seguretat

La majoria de les operacions de configuració de seguretat del WordPress es limiten a un únic administrador autoritzat. La configuració per defecte del WordPress és contínuament avaluada per l’equip del nucli. L’equip del nucli del WordPress proporciona documentació i un recull de les pràctiques recomanades per a reforçar la seguretat de la configuració del servidor per executar un lloc web del WordPress11.

A6 – Exposició a dades sensibles

Les contrasenyes del compte d’usuari del WordPress són processades per una funció de hash salat basat en el Portable PHP Password Hashing Framework12. El sistema de permisos del WordPress s’utilitza per controlar l’accés a la informació privada, com ara PII dels usuaris registrats, adreces de correu electrònic dels comentaris, contingut publicat de forma privada, etc. Al WordPress 3.7, es va incloure un mesurador de robustesa de la contrasenya en el programari principal que proporciona informació addicional als usuaris que estableixen les seves contrasenyes i suggereix una robustesa creixent. El WordPress també té una configuració opcional per a requerir HTTPS.

A7 – Manca de control d’accés al nivell de funcions

El WordPress comprova que es disposi de l’autorització i els permisos necessaris per a accedir a qualsevol funcionalitat abans que les accions s’executin. L’accés o visualització de les adreces d’administració, menús o pàgines sense els permisos adequats està fortament lligat amb el sistema d’autenticació per tal d’evitar que usuaris no autoritzats pugin accedir-hi.

A8 – Cross Site Request Forgery (CSRF)

El WordPress utilitza testimonis criptogràfics, anomenats nonces13, per a validar els intents de sol·licituds d’acció dels usuaris autoritzats per protegir-se contra possibles amenaces de CSRF. El WordPress proporciona una API per a la generació d’aquests testimonis per crear i verificar testimonis únics i temporals. El testimoni es limita a un usuari específic, una acció específica, un objecte específic i un període de temps específic, que es pot afegir als formularis i als URL segons sigui necessari. A més, tots els nonces són invalidats en tancar la sessió.

A9 – Ús de components amb vulnerabilitats conegudes

L’equip del nucli del WordPress controla de prop les poques biblioteques incloses i els frameworks amb els quals el WordPress s’integra per a la funcionalitat del nucli. En el passat, l’equip del nucli ha fet contribucions a diversos components de tercers per fer-los més segurs, com ara l’actualització per corregir una vulnerabilitat entre llocs al TinyMCE per al WordPress 3.5.214.

Si és necessari, l’equip central pot decidir bifurcar o reemplaçar components externs crítics, com quan la biblioteca SWFUpload va ser substituïda oficialment per la biblioteca Plupload 3.5.2, i una bifurcació de seguretat per a SWFUpload va ser alliberada per l’equip de seguretat15;nbsp;per a les extensions que van continuar utilitzant SWFUpload a curt termini.

A10 – Redireccions i reenviaments no validats

El control d’accés intern i el sistema d’autenticació del WordPress protegiran contra els intents de dirigir els usuaris a destinacions no desitjades o redireccions automàtiques. Aquesta funcionalitat també està disponible per a desenvolupadors d’extensions a través de la API, wp_safe_redirect()16.

Altres riscos i preocupacions de seguretat

Atacs de processament XXE (XML eXternal Entity)

En processar XML, el WordPress inhabilita la càrrega d’entitats XML personalitzades per evitar atacs d’entitats externes i d’expansió d’entitats. Més enllà de la funcionalitat bàsica de PHP, WordPress no proporciona una API de processament XML segura addicional per als autors d’extensions.

Atacs SSRF (Server Side Request Forgery)

Les sol·licituds HTTP emeses per WordPress es filtren per evitar l’accés a les adreces IP privades i de bucle invertit. A més, l’accés només està permès a certs ports HTTP estàndard.

Seguretat dels temes i extensions del WordPress

El tema per defecte

WordPress requereix que un tema estigui habilitat per fer visible el contingut a la portada. El tema predeterminat que s’inclou amb el nucli del WordPress (actualment “Twenty Twenty-Three”) ha estat revisat i provat vigorosament per raons de seguretat tant per l’equip de desenvolupadors de temes com per l’equip de desenvolupament del nucli.

El tema predeterminat pot servir com a punt de partida per al desenvolupament d’un tema personalitzat, i els desenvolupadors del lloc poden crear un tema secundari que inclogui certa personalització, però torni al tema predeterminat per a la major part de la funcionalitat i la seguretat. El tema predeterminat pot ser eliminat fàcilment per un administrador si no és necessari.

Repositoris de temes i extensions de WordPress.org

Hi ha aproximadament més de 50.000 extensions i 5.000 temes llistats al lloc web de WordPress.org. Aquests temes i extensions s’envien per a la seva inclusió i són revisats manualment per voluntaris abans de posar-los a disposició de tothom al repositori.

La inclusió d’extensions i temes al repositori no és una garantia que estiguin lliures de vulnerabilitats de seguretat. Es proporcionen directrius perquè els autors d’extensions les consultin abans de l’enviament per incloure-les al repositori17, i es proporciona documentació extensa sobre com fer el desenvolupament de temes de WordPress18 al lloc WordPress.org.

Cada extensió i tema té la capacitat de ser desenvolupat contínuament pel propietari del mateix o del tema, ​​qualsevol correcció posterior o desenvolupament de característiques es pot penjar al repositori i posar a disposició dels usuaris aquesta extensió o tema instaŀlat amb una descripció d’aquest canvi. Els administradors del lloc són notificats dels complements que han d’actualitzar-se a través del tauler d’administració.

Quan l’equip de seguretat de WordPress descobreix una vulnerabilitat en una extensió, es posa en contacte amb l’autor de l’extensió i treballen junts per corregir i llançar-ne una versió segura. Si hi ha una falta de resposta per part de l’autor de l’extensió o si la vulnerabilitat és greu, l’extensió o tema s’extreu del directori públic i, en alguns casos, l’equip de seguretat ho corregeix i actualitza directament.

L’equip de revisió de temes

L’equip de revisió de temes és un grup de voluntaris, dirigits per membres clau i establerts de la comunitat del WordPress, que revisen i aproven els temes enviats per incloure’ls al directori oficial de temes del WordPress. L’equip de revisió de temes manté les directrius oficials de revisió de temes19, les dades de prova de la unitat de tema20 i les extensions de comprovació de temes21, i intenta implicar i educar la comunitat de desenvolupadors de temes de WordPress sobre les millors pràctiques de desenvolupament. La inclusió en el grup és moderada pels responsables principals de l’equip de desenvolupament del WordPress.

El rol del proveïdor d’allotjament en la seguretat del WordPress

Es pot instal·lar el WordPress a moltes plataformes . Si bé el nucli del WordPress inclou moltes mesures per a garantir una web segura (les quals es tracten en aquest document), la configuració del sistema operatiu i el servidor web on s’executa el WordPress també juguen un paper molt important a l’hora de garantir la seguretat del propi WordPress.

Una nota sobre WordPress.com i la seguretat del WordPress

WordPress.com és la instal·lació de WordPress més gran del món, i és propietat i és gestionada per Automattic, Inc., que va ser fundada per Matt Mullenweg, el cocreador del projecte WordPress. WordPress.com s’executa amb el programari bàsic de WordPress i té els seus propis processos de seguretat, riscos i solucions22. Aquest document fa referència a la seguretat pel que fa al programari WordPress de codi obert autoallotjat i descarregable disponible des de WordPress.org i instal·lable en qualsevol servidor del món.

Apèndix

APIs del nucli del WordPress

La interfície de programació d’aplicacions bàsiques (API) del WordPress es compon de diverses API individuals23, cadascuna de les quals cobreix les funcions involucrades i la utilització d’un conjunt determinat de funcionalitats. Junts, formen la interfície del projecte que permet a les extensions i temes interactuar, alterar i ampliar la funcionalitat bàsica de WordPress de manera segura i segura.

Mentre que cada API de WordPress proporciona les millors pràctiques i maneres estandarditzades d’interactuar i estendre el programari bàsic de WordPress, les següents API de WordPress són les més pertinents per fer complir i reforçar la seguretat de WordPress:

API de base de dades

L’API de bases de dades24, afegida al WordPress 0.71, proporciona el mètode correcte per accedir a les dades com a valors amb nom que s’emmagatzemen a la capa de la base de dades.

API del sistema de fitxers

L’API25 del sistema de fitxers, afegida al WordPress 2.626, es va crear originalment per a la funció d’actualitzacions automàtiques del WordPress. L’API del sistema de fitxers resumeix la funcionalitat necessària per llegir i escriure fitxers locals al sistema de fitxers per fer-los de manera segura, en una varietat de tipus d’amfitrió.

Ho fa a través de la WP_Filesystem_Base classe i de diverses subclasses que implementen diferents maneres de connectar-se al sistema de fitxers local, depenent del suport individual de l’amfitrió. Qualsevol tema o extensió que necessiti escriure fitxers localment hauria de fer-ho utilitzant la família WP_Filesystem de classes.

API HTTP

L’API HTTP27, afegida al WordPress 2.728 i ampliada encara més al WordPress 2.8, estandarditza les peticions HTTP per a WordPress. L’API gestiona les galetes, la codificació i descodificació gzip, la descodificació de trossos (si HTTP 1.1) i diverses altres implementacions de protocols HTTP. L’API estandarditza les sol·licituds, prova cada mètode abans d’enviar-les i, en funció de la configuració del servidor, utilitza el mètode adequat per fer la sol·licitud.

Permisos i API de l’usuari actual

Els permisos i l’APId’usuari actual 29 són un conjunt de funcions que ajudaran a verificar els permisos i l’autoritat de l’usuari actual per realitzar qualsevol tasca o operació que se sol·liciti, i poden protegir encara més contra usuaris no autoritzats que accedeixin o realitzin funcions més enllà de les seves capacitats permeses.

Llicència de contingut de paper blanc

El text d’aquest document (sense incloure el logotip o marca comercial de WordPress) està llicenciat sota CC0 1.0 Universal (CC0 1.0) Public Domain Dedication. Podeu copiar, modificar, distribuir i representar l’obra, fins i tot amb finalitats comercials, tot això sense demanar permís.

Un agraïment especial a  l’informe sobre seguretat del Drupal, que va proporcionar una mica d’inspiració.

Lectures addicionals


Escrit per Sara Rosso

Contribucions de;nbsp;Barry Abrahamson, Michael Adams, Jon Cave, Helen Hou-Sandí, Dion Hulse, Mo Jangda, Paul Maiorana

Versió 1.0 Març de 2015


Notes de peu de pàgina

[1] https://w3techs.com/, a partir de desembre de 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/apis/security/

[10] https://developer.wordpress.org/apis/security/data-validation/

[11] https://wordpress.org/support/article/hardening-wordpress/

[12] https://www.openwall.com/phpass/

[13] https://developer.wordpress.org/apis/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://ca.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://ca.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/