És segur el vibe coding? Els riscos reals i què comprovar abans de publicar

El vibe coding és segur per a eines personals i prototips, i pot ser segur per a aplicacions reals amb usuaris reals, però només si hi afegeixes les comprovacions que el «descriu-ho i mira si funciona» salta. Els problemes perillosos són invisibles des de la pantalla: usuaris que poden obrir les dades de cadascú, claus secretes que es troben al navegador i formularis públics sense límits. Aquesta guia explica els riscos que realment causen problemes, com gestionar els secrets, quanta revisió necessites i una revisió de 30 minuts per fer abans de publicar.

Per a la llista tècnica completa, consulta la nostra llista de comprovació de seguretat per a aplicacions fetes amb IA. Aquesta pàgina és la versió més curta i pràctica, per a persones que no llegeixen codi.

Per què el vibe coding té riscos propis

Quan fas vibe coding, jutges l'aplicació fent-la servir. Això detecta botons que no funcionen i dissenys lletjos. No detecta problemes que només apareixen quan algú fa servir l'aplicació d'una manera diferent de la teva: un desconegut, un bot, un usuari curiós que edita una adreça web.

Les IA escriuen codi plausible, i la major part és correcta. Però optimitzen per al que els demanes —«fes que el tauler mostri els meus projectes»— i potser no afegeixen la protecció que no els has demanat —«i només els meus»—. La solució no és deixar de fer vibe coding. És demanar explícitament les proteccions i després provar-les.

Quin risc té la teva aplicació? Una escala ràpida

Sigues honest sobre en quina fila ets. Moltes aplicacions comencen a la primera fila i acaben a la tercera sense que ningú no ho hagi decidit.

Els riscos que realment causen problemes

1. Els usuaris poden veure les dades dels altres

Aquest és el problema greu més habitual en aplicacions fetes amb IA. La pàgina mostra a cada usuari només els seus registres, així que sembla correcte. Però el servidor retornarà qualsevol registre si algú canvia l'ID a la barra d'adreces o en una sol·licitud. Com que sempre proves com a tu mateix, mai no ho veus.

Com comprovar-ho: crea dos comptes. Inicia sessió com a usuari A, obre un dels registres d'A i anota l'adreça. Inicia sessió com a usuari B en una finestra privada i enganxa aquesta adreça. Hauries de veure «no trobat», mai les dades d'A.

Prompt:

Revisa cada endpoint del servidor que llegeix, modifica o elimina dades d'usuaris. Cadascun ha de confirmar que l'usuari que ha iniciat sessió té permís per accedir a aquest registre concret. Llista els endpoints, explica com comprova cadascun i corregeix els que no ho facin.

2. Secrets al lloc equivocat

Un secret és qualsevol cosa que concedeix accés: una clau API d'un servei d'IA o de correu electrònic, una contrasenya de la base de dades, la clau secreta d'un proveïdor de pagaments. Si és en codi que s'executa al navegador, qualsevol pot obrir les eines de desenvolupador i copiar-la. Si es puja a un repositori públic, els bots la troben en qüestió d'hores.

Com comprovar-ho: pregunta a la IA.

Llista cada clau API, token i contrasenya que fa servir aquesta aplicació. Per a cadascuna, digues on s'emmagatzema i si mai s'envia al navegador. Mou a secrets del servidor qualsevol que estigui al codi o al frontend.

3. Formularis i endpoints públics sense límits

Els formularis de contacte, els registres i les funcions d'IA són trobats pels bots. Sense límits, reps spam, comptes falsos o una factura gran d'una API d'IA cridada milers de vegades.

Prompt:

Afegeix límits de sol·licituds al registre, a l'inici de sessió, al formulari de contacte i a cada endpoint que crida un servei d'IA. Afegeix un camp trampa (honeypot) als formularis públics. Digues quins límits has escollit.

4. Confiar en el navegador

Qualsevol cosa que decideixi el navegador la pot canviar l'usuari: preus, descomptes, respostes d'un test, marques de «és administrador». Les regles que importen s'han d'aplicar al servidor.

Prompt:

Troba qualsevol lloc on el navegador decideix alguna cosa que hauria de decidir el servidor: preus, totals, permisos, rols, puntuacions. Mou aquestes comprovacions al servidor.

5. Sense manera de tornar enrere

Un canvi dolent, o una persona malintencionada, pot esborrar dades. Si no hi ha còpia de seguretat ni manera de desfer els canvis, un petit error es converteix en un error permanent. Assegura't que la teva eina tingui punts de control per al codi i còpies de seguretat per a la base de dades. Consulta com fer una còpia de seguretat de la base de dades de la teva aplicació.

Gestionar els secrets com toca

Els secrets causen més danys evitables que qualsevol altra cosa, així que aquestes són les regles en un sol lloc:

• Mai no enganxis una clau real al xat. Els xats s'emmagatzemen, es comparteixen i es fan captures de pantalla. Posa les claus als secrets o a les variables d'entorn de la teva eina. (Què són les variables d'entorn i els secrets.)
• Crida els serveis de pagament des del servidor. El navegador demana al teu servidor; el teu servidor crida el servei d'IA o de pagaments amb la clau.
• Fes servir claus separades per a proves i per a ús real, perquè una clau de prova filtrada no pugui tocar diners reals.
• Estableix límits de despesa als tauler dels proveïdors d'IA i de correu electrònic.
• Rota una clau immediatament si creus que s'ha filtrat. Crea'n una de nova, actualitza el secret i després elimina la vella.

A Mythex, els secrets viuen a la configuració del projecte fora del codi, i l'agent els pot fer servir sense que els valors apareguin al xat. La nostra guia per mantenir segures les claus API cobreix més proveïdors.

Quanta revisió de codi necessites?

Fer vibe coding vol dir que no llegeixes cada línia. No cal que ho facis. Però per a algunes línies, algú hauria de fer-ho.

• Eines personals: cap més enllà de les comprovacions d'aquí.
• Aplicacions amb comptes d'usuari: revisa com funcionen l'inici de sessió i l'accés a les dades. Pots fer-ho demanant a la IA que ho expliqui en paraules senzilles i comprovant que l'explicació coincideix amb el que esperes.
• Aplicacions amb pagaments o dades sensibles: fes que un desenvolupador revisi l'autenticació, els permisos, la gestió de pagaments i qualsevol cosa que emmagatzemi dades personals. Són unes quantes hores del seu temps, no una reescriptura.

Un prompt útil fins i tot sense desenvolupador:

Explica, en paraules senzilles, com decideix aquesta aplicació qui és un usuari i què té permís per veure. Indica els fitxers. Després llista qualsevol cosa que voldries que revisés un especialista en seguretat.

La nostra guia sobre com revisar el codi generat per IA explica què busquen els revisors, i pots donar-la a qui faci la revisió. Si la teva eina et permet exportar el codi o sincronitzar-lo amb GitHub, organitzar aquesta revisió és fàcil; a Mythex, tots dos són part del Pro.

La revisió de 30 minuts abans de publicar

Fes això abans de compartir l'enllaç amb algú fora del teu cercle.

Accés (10 minuts)

1. Dos comptes, dos navegadors: pot B obrir els registres d'A per URL? No hauria de poder-ho.
2. Tanca la sessió i visita directament l'adreça de cada pàgina. Les pàgines privades t'han d'enviar a l'inici de sessió.
3. Com a usuari normal, obre les adreces d'administració. Haurien de ser rebutjades.

Secrets (5 minuts)

1. Demana a la IA on viu cada clau, amb el prompt de dalt.
2. Obre l'aplicació, mira el codi font de la pàgina i cerca «key», «secret» i «token».

Formularis i abús (5 minuts)

1. Envia cada formulari buit, amb textos molt llargs i dues vegades seguides.
2. Confirma que hi ha límits de sol·licituds al registre, a l'inici de sessió i a qualsevol funció d'IA.

Dades i recuperació (5 minuts)

1. Sàpigues on són les dades i com restaurar-les.
2. Comprova que pots tornar el codi a una versió anterior que funcionava.

Legal i bàsic (5 minuts)

1. Si recull dades personals, afegeix una política de privadesa i digues què recullis. Consulta com escriure termes de servei i una política de privadesa.
2. Assegura't que l'aplicació publicada usa HTTPS. La majoria dels constructors, Mythex inclòs, s'ocupen d'això per tu.

Si tot passa, estàs en bona forma per a un llançament inicial. Repeteix els passos 1–5 després de qualsevol canvi gran en l'inici de sessió, els rols o les dades.

Què protegeixen i què no protegeixen les plataformes de vibe coding

Una bona plataforma gestiona molta infraestructura: HTTPS, espais de treball aïllats, una base de dades per projecte, emmagatzematge de secrets, còpies de seguretat i reversió. Mythex dona a cada projecte el seu propi espai de treball privat i base de dades, manté els secrets fora del codi i guarda un punt de control després de cada canvi que surt bé, perquè puguis desfer-lo.

El que cap plataforma pot fer és conèixer les regles de la teva aplicació. Només tu saps que els clients no haurien de veure les factures dels altres, o que un cupó només hauria de funcionar una vegada. Aquestes regles han d'estar als teus prompts i confirmades pels teus tests.

La resposta curta

El vibe coding és tan segur com les comprovacions que hi afegeixes. Per a una eina personal, mantén les claus fora del codi i gaudeix-ne. Per a qualsevol cosa amb dades d'altres persones, fes la revisió de 30 minuts de dalt abans de cada llançament, i demana l'opinió d'un desenvolupador per a pagaments i dades sensibles. Per veure aquests riscos en projectes reals, llegeix els nostres exemples de vibe coding; per construir amb aquestes comprovacions des del principi, segueix com crear una aplicació amb vibe coding.

Preguntes