{"id":1127,"date":"2026-02-17T20:00:00","date_gmt":"2026-02-17T19:00:00","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/audit-plugin-wordpress-vulnerabilita-sicurezza\/"},"modified":"2026-02-17T20:00:00","modified_gmt":"2026-02-17T19:00:00","slug":"audit-plugin-wordpress-vulnerabilita-sicurezza","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/audit-plugin-wordpress-vulnerabilita-sicurezza\/","title":{"rendered":"Come Faccio l&#8217;Audit Completo dei Plugin WordPress per Eliminare le Vulnerabilit\u00e0: La Mia Procedura di Sicurezza 2026"},"content":{"rendered":"<p>Se gestisci siti WordPress come me, il dato che sto per darti ti far\u00e0 riflettere: <strong>nel 2026, vengono scoperte in media oltre 250 nuove vulnerabilit\u00e0 nei plugin WordPress ogni settimana<\/strong>. Solo nella prima settimana di gennaio 2026 ne sono emerse 333, di cui 253 riguardanti plugin e 80 temi. Il dettaglio peggiore? Il 71% di queste vulnerabilit\u00e0 risultava <em>ancora senza patch<\/em> al momento della divulgazione. Numeri che ho verificato personalmente monitorando i report settimanali di SolidWP e Patchstack.<\/p>\n<p>Dopo anni passati a gestire server Plesk e a mettere in sicurezza installazioni WordPress per clienti e progetti personali, ho sviluppato una <strong>procedura di audit dei plugin<\/strong> che eseguo regolarmente. Non si tratta solo di aggiornare tutto e sperare per il meglio: \u00e8 un processo sistematico che parte dall&#8217;inventario, passa per la scansione delle vulnerabilit\u00e0 note, e arriva fino all&#8217;eliminazione di tutto il codice superfluo. In questo articolo vi mostro esattamente come faccio.<\/p>\n<p>Se avete gi\u00e0 letto la mia guida su <a href=\"https:\/\/darioiannascoli.it\/blog\/sicurezza-wordpress-brute-force\/\">come mettere in sicurezza WordPress dagli attacchi brute force<\/a>, sapete che la sicurezza \u00e8 un tema che mi sta molto a cuore. L&#8217;audit dei plugin \u00e8 il passo successivo \u2014 e probabilmente il pi\u00f9 importante \u2014 per proteggere davvero un sito WordPress nel 2026.<\/p>\n<h2>Perch\u00e9 l&#8217;Audit dei Plugin WordPress \u00c8 Fondamentale nel 2026<\/h2>\n<p>La superficie d&#8217;attacco di WordPress nel 2026 \u00e8 dominata dai plugin. Secondo i dati aggregati pi\u00f9 recenti, <strong>l&#8217;88% delle vulnerabilit\u00e0 WordPress \u00e8 riconducibile ai plugin<\/strong>, il 12% ai temi e praticamente lo 0% al core. Le tipologie predominanti sono <em>Cross-Site Scripting<\/em> (XSS) al 39% e <em>Broken Access Control<\/em> al 24%. Il dato che pi\u00f9 mi preoccupa \u00e8 che circa il <strong>42% delle vulnerabilit\u00e0 scoperte nel 2026 resta senza patch<\/strong>.<\/p>\n<p>Per darvi un esempio concreto: a febbraio 2026 \u00e8 stata divulgata una <strong>vulnerabilit\u00e0 critica nel plugin WPvivid Backup &amp; Migration<\/strong> (CVE-2026-1357), con score CVSS di 9.8, che permetteva l&#8217;esecuzione di codice remoto senza autenticazione su oltre 900.000 siti. Ho immediatamente verificato tutte le installazioni che gestisco e aggiornato alla versione 0.9.124. Sempre a febbraio, il plugin <em>wpForo Forum<\/em> (CVE-2026-0910) presentava una falla di PHP Object Injection che consentiva il takeover del sito partendo da un semplice account Subscriber.<\/p>\n<p>Questi casi dimostrano perch\u00e9 non basta &#8220;aggiornare quando capita&#8221;: serve una procedura strutturata di audit.<\/p>\n<h2>Step 1: Inventario Completo dei Plugin Installati<\/h2>\n<p>Il primo passo della mia procedura \u00e8 generare un <strong>inventario completo<\/strong> di tutti i plugin presenti sull&#8217;installazione. Uso <em>WP-CLI<\/em> direttamente dalla shell del server (Plesk mi d\u00e0 accesso SSH su tutti i domini):<\/p>\n<pre><code># Lista tutti i plugin con versione e stato\nwp plugin list --format=table\n\n# Esporta in CSV per archivio\nwp plugin list --format=csv &gt; \/home\/backup\/plugin-audit-$(date +%Y%m%d).csv<\/code><\/pre>\n<p>Questo mi d\u00e0 una visione chiara di:<\/p>\n<ul>\n<li>Quanti plugin sono installati (attivi e inattivi)<\/li>\n<li>Quale versione \u00e8 in uso<\/li>\n<li>Se ci sono plugin <strong>disattivati ma ancora presenti<\/strong> nel filesystem<\/li>\n<li>Plugin <em>must-use<\/em> (mu-plugins) che spesso vengono dimenticati<\/li>\n<\/ul>\n<p><strong>Regola d&#8217;oro:<\/strong> ogni plugin installato aumenta la superficie d&#8217;attacco, anche se disattivato. Il codice \u00e8 comunque raggiungibile dal web se non si prendono precauzioni a livello server.<\/p>\n<h2>Step 2: Identificare ed Eliminare Plugin Abbandonati<\/h2>\n<p>Un plugin non aggiornato da oltre 2 anni \u00e8 considerato <strong>abbandonato<\/strong> dalla community WordPress.org. Nella mia esperienza, questi plugin sono le mine antiuomo della sicurezza WordPress: nessuno li patcher\u00e0 mai, ma gli attaccanti conoscono benissimo le loro vulnerabilit\u00e0.<\/p>\n<p>Per identificarli controllo:<\/p>\n<ol>\n<li>La data dell&#8217;ultimo aggiornamento su wordpress.org\/plugins<\/li>\n<li>Il numero di problemi di supporto aperti senza risposta<\/li>\n<li>Se il plugin \u00e8 stato rimosso dal repository ufficiale<\/li>\n<li>Se lo sviluppatore ha altri progetti attivi<\/li>\n<\/ol>\n<p>Se un plugin \u00e8 abbandonato, lo rimuovo immediatamente e cerco un&#8217;alternativa mantenuta attivamente. Se non esiste un&#8217;alternativa, valuto se la funzionalit\u00e0 \u00e8 davvero necessaria o se posso implementarla con codice custom nel <em>functions.php<\/em> del tema child.<\/p>\n<h2>Step 3: Scansione Vulnerabilit\u00e0 con WPScan CLI<\/h2>\n<p>Il cuore del mio audit \u00e8 <strong>WPScan<\/strong>, lo scanner a riga di comando che interroga il database di vulnerabilit\u00e0 WordPress pi\u00f9 completo disponibile. Lo uso dalla shell del mio server (\u00e8 preinstallato su Kali, ma si installa facilmente ovunque con Ruby):<\/p>\n<pre><code># Scansione base con API token per dati vulnerabilit\u00e0\nwpscan --url https:\/\/miosito.it --api-token IL_TUO_TOKEN --enumerate vp,vt\n\n# Scansione aggressiva di tutti i plugin\nwpscan --url https:\/\/miosito.it --api-token IL_TUO_TOKEN --plugins-detection aggressive\n\n# Enumerazione utenti (verifica esposizione username)\nwpscan --url https:\/\/miosito.it --enumerate u<\/code><\/pre>\n<p>WPScan funziona come un <em>black box scanner<\/em>: simula un attaccante esterno e verifica versioni di WordPress, plugin e temi contro il suo database di vulnerabilit\u00e0 note. Il piano gratuito offre 25 richieste API al giorno, sufficienti per la maggior parte dei siti (una richiesta per WordPress + una per ogni plugin\/tema).<\/p>\n<p>All&#8217;inizio non funzionava come mi aspettavo perch\u00e9 il WAF del server bloccava le richieste di WPScan. Ho dovuto temporaneamente whitelistare l&#8217;IP del mio scanner nelle regole di <a href=\"https:\/\/darioiannascoli.it\/blog\/configurare-fail2ban-plesk\/\">Fail2Ban che avevo configurato su Plesk<\/a>. Un dettaglio che molti dimenticano.<\/p>\n<h3>Alternativa: WP-CLI Vulnerability Scanner<\/h3>\n<p>Per chi preferisce restare dentro l&#8217;ecosistema WP-CLI, c&#8217;\u00e8 un ottimo pacchetto di 10up che interroga i database di WPScan, Patchstack o Wordfence Intelligence:<\/p>\n<pre><code># Installazione\nwp package install 10up\/wpcli-vulnerability-scanner:dev-stable\n\n# Scansione completa\nwp vuln status\n\n# Output in JSON per automazione\nwp vuln status --format=json<\/code><\/pre>\n<p>Lo trovo perfetto per integrarlo nei <a href=\"https:\/\/darioiannascoli.it\/blog\/cronjob-plesk-backup-manutenzione-server\/\">cronjob automatizzati su Plesk<\/a> e ricevere report periodici via email.<\/p>\n<h2>Step 4: Audit dei Permessi e delle Capability<\/h2>\n<p>Molte vulnerabilit\u00e0 del 2026 sfruttano il <strong>Broken Access Control<\/strong>: plugin che non verificano correttamente i permessi utente. Un esempio recente \u00e8 il CVE-2026-1671 del plugin WP System Log, dove un utente con ruolo Subscriber poteva accedere ai log di sistema contenenti dati sensibili.<\/p>\n<p>Nella mia procedura verifico sempre:<\/p>\n<ul>\n<li>Che la <strong>registrazione utenti<\/strong> sia disabilitata se non necessaria<\/li>\n<li>Che il ruolo predefinito sia impostato su <em>Subscriber<\/em> (mai su Editor o superiore)<\/li>\n<li>Che non esistano <strong>account dormienti<\/strong> con privilegi elevati<\/li>\n<li>Che ogni plugin che gestisce form, upload o AJAX abbia controlli di capability adeguati<\/li>\n<\/ul>\n<pre><code># Verifica utenti con ruolo amministratore\nwp user list --role=administrator --format=table\n\n# Cerca utenti creati di recente (potenziali backdoor)\nwp user list --orderby=registered --order=desc --format=table<\/code><\/pre>\n<p>Come ho spiegato anche nell&#8217;articolo sulla <a href=\"https:\/\/darioiannascoli.it\/blog\/controllo-permessi-app-android-rimuovere-pericolose\/\">gestione dei permessi su Android<\/a>, il principio del <em>least privilege<\/em> vale ovunque: ogni utente e ogni plugin devono avere solo i permessi strettamente necessari.<\/p>\n<h2>Step 5: Verifica Integrit\u00e0 File e Malware Scan<\/h2>\n<p>Dopo la scansione delle vulnerabilit\u00e0 note, passo alla <strong>verifica dell&#8217;integrit\u00e0 dei file<\/strong>. WordPress ha un meccanismo built-in che pochi conoscono:<\/p>\n<pre><code># Verifica integrit\u00e0 del core WordPress\nwp core verify-checksums\n\n# Verifica checksum dei plugin dal repository\nwp plugin verify-checksums --all<\/code><\/pre>\n<p>Questi comandi confrontano i file presenti sul server con quelli originali del repository. Qualsiasi differenza potrebbe indicare una <strong>modifica non autorizzata<\/strong> o un&#8217;iniezione di codice malevolo.<\/p>\n<p>Per una scansione malware pi\u00f9 approfondita, uso <strong>Wordfence<\/strong> (versione free) direttamente dal pannello WordPress, che esegue scansione basata su firme e analisi comportamentale. Lo affianco a controlli manuali lato server:<\/p>\n<pre><code># Cerca file PHP modificati di recente (ultimi 7 giorni)\nfind \/var\/www\/vhosts\/miosito.it\/httpdocs\/wp-content\/ -name \"*.php\" -mtime -7\n\n# Cerca pattern sospetti nei file PHP\ngrep -r \"eval(base64_decode\" \/var\/www\/vhosts\/miosito.it\/httpdocs\/wp-content\/plugins\/\ngrep -r \"exec(\" \/var\/www\/vhosts\/miosito.it\/httpdocs\/wp-content\/plugins\/<\/code><\/pre>\n<h2>Step 6: Implementare Protezione Proattiva Post-Audit<\/h2>\n<p>L&#8217;audit non serve a nulla se non si mettono in atto <strong>misure preventive<\/strong> per il futuro. Ecco cosa configuro sempre dopo un audit completo:<\/p>\n<h3>Aggiornamenti Automatici Selettivi<\/h3>\n<pre><code>\/\/ In wp-config.php - abilita auto-update per plugin di sicurezza\ndefine('WP_AUTO_UPDATE_CORE', 'minor');\n\n\/\/ In functions.php del tema child\nadd_filter('auto_update_plugin', function($update, $item) {\n    \/\/ Lista plugin da aggiornare automaticamente\n    $auto_update_plugins = array(\n        'wordfence\/wordfence.php',\n        'sucuri-scanner\/sucuri.php',\n    );\n    if (in_array($item-&gt;plugin, $auto_update_plugins)) {\n        return true;\n    }\n    return $update;\n}, 10, 2);<\/code><\/pre>\n<h3>Hardening del wp-content<\/h3>\n<pre><code># Blocca esecuzione PHP nelle directory uploads (Nginx su Plesk)\nlocation ~* \/wp-content\/uploads\/.*.php$ {\n    deny all;\n}\n\n# Proteggi directory mu-plugins\nlocation ~* \/wp-content\/mu-plugins\/.*.php$ {\n    internal;\n}<\/code><\/pre>\n<p>Queste direttive Nginx le aggiungo dalla configurazione personalizzata di Plesk, seguendo lo stesso approccio che uso per <a href=\"https:\/\/darioiannascoli.it\/blog\/compressione-brotli-nginx-performance-server\/\">ottimizzare le performance con Brotli su Nginx<\/a> e per <a href=\"https:\/\/darioiannascoli.it\/blog\/http3-quic-plesk-nginx\/\">abilitare HTTP\/3 QUIC su Plesk<\/a>.<\/p>\n<h3>Monitoring Continuo con WP Activity Log<\/h3>\n<p>Installo <strong>WP Activity Log<\/strong> su ogni sito che gestisco. Questo plugin registra ogni azione rilevante per la sicurezza: login, logout, tentativi falliti, modifiche a post, installazione plugin e cambi di configurazione. Lo considero essenziale per la <em>forensics<\/em> post-incidente e per il monitoraggio in tempo reale.<\/p>\n<h2>Step 7: Creare lo Script di Audit Automatizzato<\/h2>\n<p>Per rendere tutto ripetibile, ho creato uno <strong>script bash<\/strong> che eseguo come cronjob settimanale su Plesk:<\/p>\n<pre><code>#!\/bin\/bash\n# audit-wp-plugins.sh - Audit settimanale plugin WordPress\n# Autore: Dario Iannascoli\n\nSITE_PATH=\"\/var\/www\/vhosts\/miosito.it\/httpdocs\"\nREPORT_DIR=\"\/home\/backup\/audit-reports\"\nDATE=$(date +%Y%m%d)\nEMAIL=\"admin@miosito.it\"\n\nmkdir -p $REPORT_DIR\n\necho \"=== AUDIT PLUGIN WORDPRESS - $DATE ===\" &gt; $REPORT_DIR\/audit-$DATE.txt\n\n# 1. Lista plugin\ncd $SITE_PATH\nwp plugin list --format=table &gt;&gt; $REPORT_DIR\/audit-$DATE.txt 2&gt;&amp;1\n\n# 2. Verifica checksum core\necho -e \"n=== VERIFICA INTEGRIT\u00c0 CORE ===\" &gt;&gt; $REPORT_DIR\/audit-$DATE.txt\nwp core verify-checksums &gt;&gt; $REPORT_DIR\/audit-$DATE.txt 2&gt;&amp;1\n\n# 3. Verifica checksum plugin\necho -e \"n=== VERIFICA INTEGRIT\u00c0 PLUGIN ===\" &gt;&gt; $REPORT_DIR\/audit-$DATE.txt\nwp plugin verify-checksums --all &gt;&gt; $REPORT_DIR\/audit-$DATE.txt 2&gt;&amp;1\n\n# 4. Scansione vulnerabilit\u00e0 (richiede 10up\/wpcli-vulnerability-scanner)\necho -e \"n=== SCANSIONE VULNERABILIT\u00c0 ===\" &gt;&gt; $REPORT_DIR\/audit-$DATE.txt\nwp vuln status &gt;&gt; $REPORT_DIR\/audit-$DATE.txt 2&gt;&amp;1\n\n# 5. Cerca file sospetti\necho -e \"n=== FILE PHP MODIFICATI ULTIMI 7 GIORNI ===\" &gt;&gt; $REPORT_DIR\/audit-$DATE.txt\nfind $SITE_PATH\/wp-content\/ -name \"*.php\" -mtime -7 &gt;&gt; $REPORT_DIR\/audit-$DATE.txt 2&gt;&amp;1\n\n# Invia report via email\nmail -s \"[AUDIT WP] Report settimanale - $DATE\" $EMAIL &lt; $REPORT_DIR\/audit-$DATE.txt<\/code><\/pre>\n<p>Lo schedulo nei <a href=\"https:\/\/darioiannascoli.it\/blog\/cronjob-plesk-backup-manutenzione-server\/\">cronjob di Plesk<\/a> ogni luned\u00ec mattina alle 6:00. Se il report evidenzia anomalie, intervengo immediatamente.<\/p>\n<h2>Checklist Rapida per l&#8217;Audit Plugin WordPress<\/h2>\n<p>Ecco la mia <strong>checklist sintetica<\/strong> che stampo e tengo sulla scrivania:<\/p>\n<ol>\n<li><strong>Inventario:<\/strong> esporta lista completa plugin con versioni<\/li>\n<li><strong>Pulizia:<\/strong> elimina plugin inattivi, abbandonati e duplicati<\/li>\n<li><strong>Scansione CVE:<\/strong> verifica ogni plugin contro database vulnerabilit\u00e0<\/li>\n<li><strong>Aggiornamenti:<\/strong> applica tutte le patch disponibili<\/li>\n<li><strong>Permessi:<\/strong> verifica ruoli utente e capability<\/li>\n<li><strong>Integrit\u00e0:<\/strong> controlla checksum core e plugin<\/li>\n<li><strong>Malware:<\/strong> scansione file sospetti e pattern malevoli<\/li>\n<li><strong>Hardening:<\/strong> blocca esecuzione PHP in uploads, proteggi wp-config<\/li>\n<li><strong>Monitoring:<\/strong> attiva logging e notifiche<\/li>\n<li><strong>Backup:<\/strong> verifica che il <a href=\"https:\/\/darioiannascoli.it\/blog\/plesk-backup-remoto-s3-wasabi\/\">backup remoto su Wasabi<\/a> sia aggiornato e funzionante<\/li>\n<\/ol>\n<h2>FAQ<\/h2>\n<h3>Ogni quanto devo fare l&#8217;audit dei plugin WordPress?<\/h3>\n<p>Nella mia esperienza, un audit completo va eseguito <strong>almeno una volta al mese<\/strong>, con scansioni automatiche settimanali. Dopo ogni aggiornamento major di WordPress o dopo l&#8217;installazione di nuovi plugin, eseguo sempre un audit aggiuntivo. Con oltre 250 nuove vulnerabilit\u00e0 scoperte ogni settimana nel 2026, la frequenza \u00e8 fondamentale.<\/p>\n<h3>Posso fare l&#8217;audit dei plugin senza accesso SSH al server?<\/h3>\n<p>S\u00ec, ma con limitazioni. Puoi usare plugin come <strong>Wordfence<\/strong> o <strong>Sucuri Security<\/strong> direttamente dal pannello WordPress per scansioni malware e vulnerabilit\u00e0. Tuttavia, per un audit completo raccomando l&#8217;accesso SSH con WP-CLI e WPScan: la visibilit\u00e0 lato server \u00e8 incomparabile rispetto ai soli strumenti da dashboard.<\/p>\n<h3>I plugin disattivati sono un rischio di sicurezza?<\/h3>\n<p>Assolutamente s\u00ec. Un plugin disattivato resta fisicamente sul server e il suo codice PHP pu\u00f2 essere raggiunto direttamente via URL, senza passare dal bootstrap di WordPress. Se quel codice ha una vulnerabilit\u00e0, un attaccante pu\u00f2 sfruttarla. <strong>La regola \u00e8 semplice: se non lo usi, cancellalo.<\/strong><\/p>\n<h3>WPScan \u00e8 gratuito? Quante scansioni posso fare?<\/h3>\n<p>WPScan CLI \u00e8 gratuito per uso non commerciale. Il piano free dell&#8217;API offre <strong>25 richieste al giorno<\/strong>: una per la versione WordPress, una per ogni plugin e una per ogni tema. Considerando che il sito medio ha circa 22 plugin, il piano gratuito copre la maggior parte delle esigenze per un singolo sito.<\/p>\n<h3>Cosa faccio se trovo un plugin vulnerabile senza patch disponibile?<\/h3>\n<p>Questo \u00e8 lo scenario peggiore e pi\u00f9 frequente: nel 2026 circa il 42% delle vulnerabilit\u00e0 resta senza fix. La mia procedura \u00e8: <strong>1)<\/strong> disattivare e rimuovere immediatamente il plugin, <strong>2)<\/strong> cercare un&#8217;alternativa mantenuta, <strong>3)<\/strong> se il plugin \u00e8 critico, implementare <em>virtual patching<\/em> tramite regole WAF personalizzate su Nginx o con un servizio come Patchstack. Nel frattempo, monitoro i log per segni di compromissione.<\/p>\n<h2>Conclusione: L&#8217;Audit dei Plugin WordPress Non \u00c8 Opzionale<\/h2>\n<p>Con 1.558 vulnerabilit\u00e0 WordPress censite nel 2026, l&#8217;88% delle quali nei plugin, fare un <strong>audit completo dei plugin WordPress<\/strong> non \u00e8 pi\u00f9 un&#8217;opzione: \u00e8 una necessit\u00e0 operativa. La procedura che vi ho mostrato \u2014 dall&#8217;inventario alla scansione, dall&#8217;hardening al monitoring automatizzato \u2014 \u00e8 quella che uso quotidianamente per proteggere i siti che gestisco.<\/p>\n<p>Il concetto chiave \u00e8 la <strong>difesa in profondit\u00e0<\/strong>: non basta un singolo plugin di sicurezza. Serve combinare strumenti lato server (WPScan, Fail2Ban, regole Nginx), plugin WordPress dedicati (Wordfence, WP Activity Log) e buone pratiche operative (aggiornamenti tempestivi, principio del minimo privilegio, backup verificati).<\/p>\n<p>Se questo articolo vi \u00e8 stato utile, vi consiglio anche la mia guida su <a href=\"https:\/\/darioiannascoli.it\/blog\/sicurezza-wordpress-brute-force\/\">come proteggere WordPress dai brute force<\/a> e quella sulla <a href=\"https:\/\/darioiannascoli.it\/blog\/configurare-fail2ban-plesk\/\">configurazione di Fail2Ban su Plesk<\/a>. La sicurezza \u00e8 un processo continuo, non un traguardo. <strong>Avete domande sulla vostra procedura di audit? Scrivetemi nei commenti!<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"<p>La mia procedura completa per fare l&#8217;audit dei plugin WordPress, identificare vulnerabilit\u00e0 e proteggere il sito nel 2026 con WPScan, WP-CLI e hardening.<\/p>\n","protected":false},"author":1,"featured_media":1286,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"Audit Plugin WordPress: Procedura Sicurezza 2026","_seopress_titles_desc":"Scopri come faccio l'audit completo dei plugin WordPress per eliminare vulnerabilit\u00e0. Procedura step-by-step con WPScan, WP-CLI e script automatizzati.","_seopress_robots_index":"","footnotes":""},"categories":[2],"tags":[238,241,240,237,242,239],"class_list":["post-1127","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-wordpress","tag-audit-plugin","tag-hardening-wordpress","tag-vulnerabilita-wordpress","tag-wordpress-security","tag-wp-cli","tag-wpscan"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/1127","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/comments?post=1127"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/1127\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/1286"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=1127"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=1127"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=1127"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}