{"id":30214,"date":"2025-10-29T10:16:09","date_gmt":"2025-10-29T08:16:09","guid":{"rendered":"https:\/\/www.kaspersky.it\/blog\/?p=30214"},"modified":"2025-10-29T10:16:09","modified_gmt":"2025-10-29T08:16:09","slug":"vibe-coding-2025-risks","status":"publish","type":"post","link":"https:\/\/www.kaspersky.it\/blog\/vibe-coding-2025-risks\/30214\/","title":{"rendered":"I pericoli nascosti nello scrivere codice con l&#8217;IA"},"content":{"rendered":"<p>Sebbene i vantaggi degli assistenti IA sul posto di lavoro <a href=\"https:\/\/www.kaspersky.it\/blog\/shadow-ai-3-policies\/30059\/\" target=\"_blank\" rel=\"noopener\">siano sottoposti a scrutinio<\/a>, l\u2019area in cui vengono adottati con pi\u00f9 baldanza \u00e8 proprio lo sviluppo software. Qui gli LLM svolgono molti ruoli dal refactoring alla documentazione, passando dalla creazione di intere applicazioni. I tradizionali problemi di sicurezza delle informazioni nello sviluppo software sono di fatto aggravati dalle vulnerabilit\u00e0 tutte specifiche dei modelli di IA. Da questo incrocio di mondi emergono pressoch\u00e9 settimanalmente nuovi bug e problemi.<\/p>\n<h2>Codice vulnerabile generato dall\u2019IA<\/h2>\n<p>Quando un LLM genera codice, pu\u00f2 includere bug o falle di sicurezza. Dopotutto, questi modelli vengono addestrati in base a dati pubblicamente disponibili provenienti da Internet, inclusi migliaia di righe di codice di bassa qualit\u00e0. Un recente <a href=\"https:\/\/www.veracode.com\/blog\/genai-code-security-report\/\" target=\"_blank\" rel=\"noopener nofollow\">studio<\/a> di Veracode ha rilevato che i principali modelli di IA oggi producono codice compilato correttamente il 90% delle volte. Meno di due anni fa, questa cifra era inferiore al 20%. Tuttavia, la sicurezza nelle righe di codice non \u00e8 migliorata: il 45% contiene ancora vulnerabilit\u00e0 classiche dell\u2019elenco <a href=\"https:\/\/owasp.org\/www-project-top-ten\/\" target=\"_blank\" rel=\"noopener nofollow\">OWASP Top-10<\/a>, senza sostanziali modifiche negli ultimi due anni. Lo studio ha riguardato oltre cento popolari LLM e frammenti di codice in Java, Python, C# e JavaScript. Pertanto, indipendentemente dal fatto che un LLM venga utilizzato per il \u201ccompletamento del codice\u201d in Windsurf o per il \u201c<a href=\"https:\/\/it.wikipedia.org\/wiki\/Vibe_coding\" target=\"_blank\" rel=\"noopener nofollow\">vibe coding<\/a>\u201d in Loveable, l\u2019applicazione finale deve essere sottoposta a test di vulnerabilit\u00e0 approfonditi. Ma nella pratica questo accade di rado: secondo uno <a href=\"https:\/\/www.wiz.io\/blog\/common-security-risks-in-vibe-coded-apps\" target=\"_blank\" rel=\"noopener nofollow\">studio di Wiz<\/a>, il 20% delle app con vibe coding presenta vulnerabilit\u00e0 gravi o errori di configurazione.<\/p>\n<p>Come esempio di tali difetti viene spesso citato il caso dell\u2019app di incontri per sole donne Tea, diventata famosa dopo <a href=\"https:\/\/www.bleepingcomputer.com\/news\/security\/tea-app-leak-worsens-with-second-database-exposing-user-chats\/\" target=\"_blank\" rel=\"noopener nofollow\">due importanti fughe di dati<\/a>. Tuttavia, questa app \u00e8 precedente al vibe coding. Se l\u2019errore di Tea \u00e8 dovuto all\u2019IA sar\u00e0 <a href=\"https:\/\/news.bloomberglaw.com\/bloomberg-law-analysis\/analysis-trouble-brews-for-tea-app-amid-vibe-coding-allegations\" target=\"_blank\" rel=\"noopener nofollow\">determinato in tribunale<\/a>. Nel caso della startup Enrichlead, invece, il colpevole accertato \u00e8 l\u2019IA. Il suo fondatore <a href=\"https:\/\/twitter.com\/leojr94_\/status\/1900767509621674109\" target=\"_blank\" rel=\"noopener nofollow\">si \u00e8 vantato<\/a> sui social media che il 100% del codice della piattaforma fosse scritto da Cursor AI, con \u201czero codice scritto a mano\u201d. Pochi giorni dopo il lancio, \u00e8 risultato essere <a href=\"https:\/\/twitter.com\/leojr94_\/status\/1901560276488511759?ref_src=twsrc%5etfw\" target=\"_blank\" rel=\"noopener nofollow\">pieno di falle di sicurezza degne di uno sviluppatore novellino<\/a>, che consentivano a chiunque di accedere a funzionalit\u00e0 a pagamento o di alterare i dati. Il progetto \u00e8 stato interrotto dopo che il fondatore non \u00e8 riuscito a portare il codice a uno standard di sicurezza accettabile utilizzando Cursor. Tuttavia, rimane imperterrito nella propria condotta e da allora ha avviato nuovi progetti basati sul vibe coding.<\/p>\n<h2>Vulnerabilit\u00e0 comuni nel codice generato dall\u2019IA<\/h2>\n<p>Sebbene la programmazione assistita dall\u2019IA esista solo da un anno o due, abbiamo gi\u00e0 dati sufficienti per identificarne gli <a href=\"https:\/\/www.wiz.io\/blog\/common-security-risks-in-vibe-coded-apps\" target=\"_blank\" rel=\"noopener nofollow\">errori pi\u00f9 comuni<\/a>. In genere si tratta di:<\/p>\n<ul>\n<li>Mancanza di convalida dell\u2019input, mancata pulizia da caratteri estranei nell\u2019input dell\u2019utente e altri errori di base che conducono a vulnerabilit\u00e0 classiche come cross-site scripting (XSS) e iniezioni SQL.<\/li>\n<li>Chiavi API e altri segreti codificati direttamente nella pagina Web e visibili agli utenti nel relativo codice.<\/li>\n<li>Logica di autenticazione implementata interamente lato client, direttamente nel codice del sito in esecuzione nel browser. Questa logica pu\u00f2 essere facilmente modificata per aggirare qualsiasi controllo.<\/li>\n<li>Errori di log: da un filtro di scrittura insufficiente alla completa assenza di log.<\/li>\n<li>Funzioni eccessivamente potenti e pericolose: i modelli di IA sono ottimizzati per generare codice che risolve un\u2019attivit\u00e0 nel modo pi\u00f9 breve possibile. Ma la via pi\u00f9 breve \u00e8 spesso la meno sicura. Un esempio da manuale \u00e8 l\u2019uso della <a href=\"https:\/\/cloudsecurityalliance.org\/blog\/2025\/07\/09\/understanding-security-risks-in-ai-generated-code\" target=\"_blank\" rel=\"noopener nofollow\">funzione eval<\/a> per operazioni matematiche sull\u2019input dell\u2019utente, che apre le porte all\u2019esecuzione di codice arbitrario nell\u2019applicazione generata.<\/li>\n<li>Dipendenze obsolete o inesistenti. Il codice generato dall\u2019IA spesso fa riferimento a versioni precedenti delle librerie, effettua chiamate API obsolete o non sicure o tenta persino di <a href=\"https:\/\/www.kaspersky.com\/blog\/ai-slopsquatting-supply-chain-risk\/53327\/\" target=\"_blank\" rel=\"noopener nofollow\">importare librerie fittizie<\/a>. Quest\u2019ultimo caso \u00e8 particolarmente pericoloso perch\u00e9 utenti malintenzionati possono creare una libreria dannosa con un nome \u201cplausibile\u201d e l\u2019agente di intelligenza artificiale la includer\u00e0 senza tante storie in un progetto reale.<\/li>\n<\/ul>\n<p>Uno studio sistematico ha <a href=\"https:\/\/arxiv.org\/pdf\/2412.15004\" target=\"_blank\" rel=\"noopener nofollow\">scansionato il codice generato dall\u2019IA<\/a> per individuare i punti deboli inclusi nell\u2019elenco dei <a href=\"https:\/\/cwe.mitre.org\/top25\/\" target=\"_blank\" rel=\"noopener nofollow\">top 25 di MITRE CWE<\/a>. I problemi pi\u00f9 comuni sono stati CWE-94 (iniezione di codice), CWE-78 (iniezione di comando del sistema operativo), CWE-190 (integer overflow), CWE-306 (authenticator mancante) e CWE-434 (caricamento di file senza restrizioni).<\/p>\n<p>Un esempio lampante di CWE-94 \u00e8 stata la recente compromissione della piattaforma Nx, <a href=\"https:\/\/www.kaspersky.com\/blog\/nx-build-s1ngularity-supply-chain-attack\/54223\/\" target=\"_blank\" rel=\"noopener nofollow\">di cui abbiamo gi\u00e0 parlato<\/a>. Gli aggressori sono riusciti a trojanizzare un popolare strumento di sviluppo rubando un token che consentiva loro di pubblicare nuove versioni del prodotto. Il furto di token sfruttava una vulnerabilit\u00e0 <a href=\"https:\/\/github.com\/nrwl\/nx\/pull\/32458\" target=\"_blank\" rel=\"noopener nofollow\">introdotta da un semplice frammento di codice generato dall\u2019IA<\/a>.<\/p>\n<h2>Suggerimenti pericolosi<\/h2>\n<p>Il noto detto tra gli sviluppatori \u201cfatto esattamente secondo le specifiche\u201d si applica anche quando si lavora con un assistente AI. Se la richiesta di creazione di una funzione o di un\u2019applicazione \u00e8 vaga e non menziona aspetti di protezione, la probabilit\u00e0 di generare codice vulnerabile aumenta notevolmente. <a href=\"https:\/\/arxiv.org\/pdf\/2502.06039\" target=\"_blank\" rel=\"noopener nofollow\">Da uno studio dedicato<\/a> \u00e8 emerso che anche osservazioni generiche come \u201cassicurarsi che il codice segua le migliori pratiche di protezione\u201d hanno ridotto della met\u00e0 il tasso di vulnerabilit\u00e0.<\/p>\n<p>L\u2019approccio pi\u00f9 efficace, tuttavia, consiste nell\u2019utilizzare dettagliate linee guida di protezione specifiche per linguaggio e che fanno riferimento agli elenchi di errori MITRE o OWASP. Un\u2019ampia raccolta di tali istruzioni di sicurezza di Wiz Research \u00e8 disponibile in <a href=\"https:\/\/github.com\/wiz-sec-public\/secure-rules-files\" target=\"_blank\" rel=\"noopener nofollow\">GitHub<\/a>; \u00e8 consigliabile aggiungerle ai prompt di sistema degli assistenti IA tramite file come <em>claude.md<\/em>, <em>.windsurfrules<\/em> o simili.<\/p>\n<h2>Degrado della sicurezza in fase di revisione<\/h2>\n<p>Quando il codice generato dall\u2019IA viene rivisto ripetutamente tramite prompt di follow-up, la sua sicurezza peggiora. Un recente <a href=\"https:\/\/arxiv.org\/abs\/2506.11022\" target=\"_blank\" rel=\"noopener nofollow\">studio<\/a> ha consentito a GPT-4o di modificare il codice scritto in precedenza fino a 40 volte, mentre i ricercatori scansionavano ogni versione alla ricerca di vulnerabilit\u00e0 a ogni giro. Dopo sole cinque iterazioni, il codice conteneva il 37% di vulnerabilit\u00e0 critiche in pi\u00f9 rispetto alla versione iniziale. Lo studio ha testato quattro strategie di prompting, tre delle quali con un\u2019enfasi diversa su (i) prestazioni, (ii) sicurezza e (iii) nuove funzionalit\u00e0; la quarta strategia usava volontariamente suggerimenti poco chiari.<\/p>\n<p>Quando il prompt si concentrava sull\u2019aggiunta di nuove funzionalit\u00e0, sono comparse 158 vulnerabilit\u00e0, di cui 29 critiche. Quando il prompt si concentrava sulla protezione del codice, il numero \u00e8 diminuito in modo significativo, ma includeva comunque 38 nuove vulnerabilit\u00e0, sette delle quali critiche.<\/p>\n<p>\u00c8 interessante notare che i prompt \u201cincentrati sulla sicurezza\u201d hanno comportato la percentuale pi\u00f9 alta di errori nelle funzioni di criptaggio.<\/p>\n<h2>Ignorare il contesto del settore<\/h2>\n<p>In settori quali finanza, assistenza sanitaria e logistica vigono requisiti tecnici, organizzativi e legali che devono essere considerati durante lo sviluppo di un\u2019app. Gli assistenti IA non sono a conoscenza di questi vincoli. Questo problema \u00e8 spesso chiamato \u201cprofondit\u00e0 mancante\u201d. Di conseguenza, i metodi di archiviazione ed elaborazione dei dati personali, medici e finanziari richiesti dalle normative locali o di settore non si rifletteranno nel codice generato dall\u2019IA. Ad esempio, un assistente potrebbe scrivere una funzione matematicamente corretta per il calcolo degli interessi sul deposito, ma ignorare le regole di arrotondamento imposte dalle autorit\u00e0 di regolamentazione. Le normative sui dati sanitari spesso richiedono una registrazione dettagliata di ogni tentativo di accesso, un\u2019attivit\u00e0 che l\u2019IA non implementer\u00e0 automaticamente al livello di dettaglio adeguato.<\/p>\n<h2>Errata configurazione dell\u2019applicazione<\/h2>\n<p>Le vulnerabilit\u00e0 non si limitano al vibe coding. Le applicazioni create tramite il vibe coding sono spesso create da utenti inesperti, che non configurano affatto l\u2019ambiente di runtime o lo fanno in base ai consigli della stessa IA. Questo porta a pericolosi errori di configurazione:<\/p>\n<ul>\n<li>I database richiesti dall\u2019applicazione vengono creati con autorizzazioni di accesso esterno eccessivamente ampie. Questo si traduce in fughe di notizie come nel caso Tea\/<a href=\"https:\/\/therecord.media\/brazil-lesbian-dating-app-shuts-down-vulnerability\" target=\"_blank\" rel=\"noopener nofollow\">Sapphos<\/a>, in cui l\u2019utente malintenzionato non ha nemmeno bisogno di utilizzare l\u2019applicazione per scaricare o eliminare l\u2019intero database.<\/li>\n<li>Le applicazioni aziendali interne vengono lasciate accessibili al pubblico senza autenticazione.<\/li>\n<li>Alle applicazioni vengono concesse autorizzazioni elevate per l\u2019accesso ai database critici. Insieme alle vulnerabilit\u00e0 del codice generato dall\u2019IA, questo semplifica le iniezioni SQL e attacchi simili.<\/li>\n<\/ul>\n<h2>Vulnerabilit\u00e0 della piattaforma<\/h2>\n<p>La maggior parte delle piattaforme di vibe coding esegue le applicazioni generate dai prompt direttamente nei propri server. Questo lega gli sviluppatori alla piattaforma, inclusa l\u2019esposizione alle relative vulnerabilit\u00e0 e la dipendenza dalle pratiche di sicurezza. Ad esempio, a luglio \u00e8 stata <a href=\"https:\/\/www.wiz.io\/blog\/critical-vulnerability-base44\" target=\"_blank\" rel=\"noopener nofollow\">scoperta una vulnerabilit\u00e0 nella piattaforma Base44<\/a> che consentiva a utenti malintenzionati non autenticati di accedere a qualsiasi applicazione privata.<\/p>\n<h2>Minacce in fase di sviluppo<\/h2>\n<p>La presenza stessa di un assistente con ampi diritti di accesso nel computer dello sviluppatore crea rischi. Ecco alcuni esempi:<\/p>\n<p>La vulnerabilit\u00e0 CurXecute (<a href=\"https:\/\/github.com\/cursor\/cursor\/security\/advisories\/GHSA-4cxx-hrm3-49rm\" target=\"_blank\" rel=\"noopener nofollow\">CVE-2025-54135<\/a>) consentiva agli utenti malintenzionati di ordinare a Cursor, il popolare strumento di sviluppo per l\u2019IA, di eseguire comandi arbitrari nel computer dello sviluppatore. Tutto ci\u00f2 di cui aveva bisogno era un server MCP (Model Context Protocol) attivo connesso a Cursor, che un utente esterno potesse utilizzare per l\u2019accesso. Questa \u00e8 una situazione tipica: i server MCP consentono agli agenti di intelligenza artificiale di accedere ai messaggi Slack, ai problemi di Jira e cos\u00ec via. L\u2019iniezione di prompt pu\u00f2 essere eseguita tramite uno qualsiasi di questi canali.<\/p>\n<p>La vulnerabilit\u00e0 EscapeRoute (<a href=\"https:\/\/github.com\/modelcontextprotocol\/servers\/security\/advisories\/GHSA-q66q-fx2p-7w4m\" target=\"_blank\" rel=\"noopener nofollow\">CVE-2025-53109<\/a>) consentiva la lettura e la scrittura di file arbitrari sul disco dello sviluppatore. La falla si presentava nel popolare server MCP di Anthropic, che consente agli agenti di IA di scrivere e leggere i file nel sistema. Le restrizioni di accesso del server semplicemente non funzionavano.<\/p>\n<p>Un <a href=\"https:\/\/thehackernews.com\/2025\/09\/first-malicious-mcp-server-found.html\" target=\"_blank\" rel=\"noopener nofollow\">server MCP dannoso<\/a> che consentiva agli agenti di intelligenza artificiale di inviare e ricevere e-mail tramite Postmark inoltrava contemporaneamente tutta la corrispondenza a un indirizzo nascosto. Avevamo previsto l\u2019emergere di tali <a href=\"https:\/\/securelist.com\/model-context-protocol-for-ai-integration-abused-in-supply-chain-attacks\/117473\/\" target=\"_blank\" rel=\"noopener\">server MCP dannosi<\/a> a settembre.<\/p>\n<p>Una vulnerabilit\u00e0 nell\u2019interfaccia della riga di comando di Gemini consentiva <a href=\"https:\/\/github.com\/google-gemini\/gemini-cli\/pull\/4795\" target=\"_blank\" rel=\"noopener nofollow\">l\u2019esecuzione arbitraria di comandi<\/a> quando uno sviluppatore chiedeva semplicemente all\u2019assistente IA di analizzare il codice di un nuovo progetto. L\u2019inserimento di contenuti dannosi veniva attivato da un file <em>readme.md<\/em>.<\/p>\n<p>L\u2019estensione Q Developer di Amazon per Visual Studio Code ha contenuto per breve tempo <a href=\"https:\/\/www.bleepingcomputer.com\/news\/security\/amazon-ai-coding-agent-hacked-to-inject-data-wiping-commands\/\" target=\"_blank\" rel=\"noopener nofollow\">istruzioni per cancellare tutti i dati<\/a> dal computer di uno sviluppatore. Un utente malintenzionato ha sfruttato un errore degli sviluppatori di Amazon ed \u00e8 riuscito a inserire questo prompt dannoso nel codice pubblico dell\u2019assistente senza privilegi speciali. Fortunatamente, un piccolo errore di codifica ne ha impedito l\u2019esecuzione.<\/p>\n<p>Una vulnerabilit\u00e0 nell\u2019agente Claude Code (<a href=\"https:\/\/embracethered.com\/blog\/posts\/2025\/claude-code-exfiltration-via-dns-requests\/\" target=\"_blank\" rel=\"noopener nofollow\">CVE-2025-55284<\/a>) ha consentito l\u2019esfiltrazione dei dati dal computer di uno sviluppatore tramite richieste DNS. L\u2019iniezione di prompt, basata su utilit\u00e0 comuni eseguite automaticamente senza conferma, poteva essere incorporata in qualsiasi codice analizzato dall\u2019agente.<\/p>\n<p>L\u2019agente di intelligenza artificiale autonomo Replit <a href=\"https:\/\/twitter.com\/jasonlk\/status\/1946069562723897802\" target=\"_blank\" rel=\"noopener nofollow\">ha eliminato i database primari di un progetto<\/a> in via di sviluppo perch\u00e9 aveva deciso che il database richiedeva una pulitura. Ci\u00f2 ha violato un\u2019istruzione diretta che vietava le modifiche (blocco del codice). Dietro questo comportamento inaspettato dell\u2019IA si nasconde un difetto architetturale: all\u2019epoca Replit <a href=\"https:\/\/x.com\/jasonlk\/status\/1947765754050580959\" target=\"_blank\" rel=\"noopener nofollow\">non aveva separazione<\/a> tra database di test e database di produzione.<\/p>\n<p>Una prompt injection inserita in un commento al codice sorgente ha spinto l\u2019ambiente di sviluppo Windsurf a <a href=\"https:\/\/embracethered.com\/blog\/posts\/2025\/windsurf-spaiware-exploit-persistent-prompt-injection\/\" target=\"_blank\" rel=\"noopener nofollow\">memorizzare automaticamente istruzioni dannose nella propria memoria a lungo termine<\/a>, agevolando il furto di dati dal sistema nell\u2019arco di mesi.<\/p>\n<p>Nell\u2019<a href=\"https:\/\/www.kaspersky.com\/blog\/nx-build-s1ngularity-supply-chain-attack\/54223\/\" target=\"_blank\" rel=\"noopener nofollow\">incidente di compromissione Nx<\/a> sono stati utilizzati gli strumenti della riga di comando per Claude, Gemini e Q per cercare password e chiavi passibili di furto da un sistema infetto.<\/p>\n<h2>Come usare l\u2019intelligenza artificiale in modo sicuro<\/h2>\n<p>Il livello di rischio dovuto al codice generato dall\u2019IA pu\u00f2 essere ridotto in modo significativo, anche se non completamente, tramite una combinazione di misure organizzative e tecniche:<\/p>\n<ul>\n<li>Implementare la revisione automatica del codice generato dall\u2019IA cos\u00ec come viene scritto utilizzando strumenti <a href=\"https:\/\/en.wikipedia.org\/wiki\/Static_application_security_testing\" target=\"_blank\" rel=\"noopener nofollow\">SAST<\/a> ottimizzati.<\/li>\n<li>Integrare i requisiti di sicurezza nei prompt di sistema di tutti gli ambienti di IA.<\/li>\n<li>Fare in modo che specialisti umani eseguano revisioni dettagliate del codice, supportate da strumenti di analisi della sicurezza basati sull\u2019intelligenza artificiale per aumentarne l\u2019efficacia.<\/li>\n<li>Addestrare gli sviluppatori a scrivere prompt protetti e, pi\u00f9 in generale, a fornire loro <a href=\"https:\/\/k-asap.com\/it\/?icid=it_kdailyplacehold_acq_ona_smm__onl_b2b_kasperskydaily_wpplaceholder____kasap___\" target=\"_blank\" rel=\"noopener\">Kaspersky Automated Security Awareness Platform<\/a>.<\/li>\n<\/ul>\n<input type=\"hidden\" class=\"category_for_banner\" value=\"kasap\">\n","protected":false},"excerpt":{"rendered":"<p>Come la scrittura di codice generato dall&#8217;IA sta cambiando la sicurezza informatica e cosa dovrebbero aspettarsi sviluppatori e &#8220;vibe coder&#8221;.<\/p>\n","protected":false},"author":2722,"featured_media":30216,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2364,2955,2956],"tags":[1516,2620,3892,3724,45],"class_list":{"0":"post-30214","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-ai","11":"tag-ia","12":"tag-llm","13":"tag-machine-learning","14":"tag-sicurezza"},"hreflang":[{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/vibe-coding-2025-risks\/30214\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/vibe-coding-2025-risks\/29724\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/vibe-coding-2025-risks\/24794\/"},{"hreflang":"ar","url":"https:\/\/me.kaspersky.com\/blog\/vibe-coding-2025-risks\/12914\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/vibe-coding-2025-risks\/29613\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/vibe-coding-2025-risks\/28663\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/vibe-coding-2025-risks\/31557\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/vibe-coding-2025-risks\/40659\/"},{"hreflang":"tr","url":"https:\/\/www.kaspersky.com.tr\/blog\/vibe-coding-2025-risks\/13915\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/vibe-coding-2025-risks\/54584\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/vibe-coding-2025-risks\/23307\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/vibe-coding-2025-risks\/32829\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/vibe-coding-2025-risks\/29817\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/vibe-coding-2025-risks\/35557\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/vibe-coding-2025-risks\/35179\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.it\/blog\/tag\/ai\/","name":"AI"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/30214","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/users\/2722"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/comments?post=30214"}],"version-history":[{"count":1,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/30214\/revisions"}],"predecessor-version":[{"id":30218,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/30214\/revisions\/30218"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media\/30216"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media?parent=30214"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/categories?post=30214"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/tags?post=30214"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}