Llista de comprovació de seguretat per a aplicacions creades amb IA: què revisar abans del llançament

Abans que la gent real faci servir una app que has creat amb IA, comprova set coses: cada pàgina i cada API comprova qui és l'usuari i què li està permès fer; les claus secretes viuen al servidor, mai al navegador ni al xat; tota l'entrada es valida al servidor; cada usuari només pot accedir als seus propis registres; el login i els endpoints costosos tenen límit de peticions; les dependències estan actualitzades; i pots restaurar les dades si alguna cosa va malament. La llista de sota converteix cadascuna d'aquestes coses en proves concretes que pots fer sense llegir el codi.

Els constructors d'apps amb IA són bons fent que les funcions funcionin. No són automàticament prudents, perquè la «prudència» gairebé mai és al prompt. La majoria dels problemes de sota vénen de coses que ningú no ha demanat, així que la solució normalment és demanar-les.

Com fer servir aquesta llista

Treballa-la en ordre i, per a cada element, fes dues coses: demana a la IA que s'asseguri que està resolt, i prova-ho tu mateix. La IA pot escriure una comprovació de permisos; només una prova et diu que funciona. Els elements estan marcats així:

• Imprescindible — fes-ho abans que ningú més faci servir l'app.
• Recomanable — fes-ho abans de tenir usuaris reals o dades reals.
• Més endavant — val la pena fer-ho a mesura que l'app creixi.

Si només tens una hora, fes tots els Imprescindibles.

1. Autenticació: qui és aquest?

L'autenticació vol dir confirmar qui és algú, normalment amb l'inici de sessió. Consulta què és l'autenticació per als conceptes bàsics i com afegir inici de sessió a la teva app per a les opcions.

• Imprescindible: Cada pàgina que mostra dades privades exigeix l'inici de sessió. Prova: tanca la sessió i enganxa directament a la barra del navegador la URL d'una pàgina privada.
• Imprescindible: Cada endpoint d'API darrere d'aquestes pàgines també exigeix l'inici de sessió, no només la pàgina. Prova: tanca la sessió, obre la pestanya de xarxa del navegador i repeteix una petició que l'app va fer mentre tenies la sessió iniciada.
• Imprescindible: Les contrasenyes s'emmagatzemen amb hash fent servir un algorisme de hash de contrasenyes lent, mai en text pla. La guia d'OWASP per a l'emmagatzematge de contrasenyes recomana Argon2id en primer lloc, amb scrypt, bcrypt o PBKDF2 com a alternatives. Pregunta: «Com s'emmagatzemen les contrasenyes?»
• Recomanable: Els enllaços de restabliment de contrasenya caduquen i només funcionen una vegada.
• Recomanable: Les cookies de sessió estan marcades com a Secure, HttpOnly i SameSite, i tancar la sessió acaba la sessió també al servidor.
• Més endavant: Ofereix l'autenticació de dos factors, o l'inici de sessió a través d'un proveïdor que la tingui.

Revisa cada ruta d'API i pàgina que retorna dades d'usuari. Cadascuna ha de rebutjar les peticions d'usuaris que no han iniciat sessió, al servidor, no només al codi de la pàgina. Enumera les rutes que has revisat.

2. Autorització: què els està permès fer?

L'autorització és el pas després del login: decidir què pot veure i canviar aquest usuari concret. És aquí on les apps fetes amb IA tenen més sovint forats greus, perquè l'app sembla correcta (el tauler de cada usuari només mostra les seves pròpies dades) mentre el servidor lliurarà les dades de qualsevol si se li demanen directament.

• Imprescindible: Cada lectura, actualització i eliminació comprova que el registre pertany a l'usuari actual (o al seu equip), al servidor.
• Imprescindible: Prova-ho: crea dos comptes, A i B. Com a A, obre un dels registres d'A i anota l'identificador de la URL o de la petició de xarxa. Inicia sessió com a B i demana el mateix identificador. B ha de rebre un error, no les dades d'A.
• Imprescindible: Les pàgines d'administració i els endpoints d'API d'administració comproven el rol de l'usuari al servidor. Amagar l'enllaç d'administració no és protecció.
• Imprescindible: Els usuaris no poden canviar el seu propi rol, preu, saldo o camps de propietari editant la petició. Prova: a la pestanya de xarxa, mira què envia una actualització del perfil. Si inclou camps com role o isAdmin, demana a la IA que els ignori des del client.
• Recomanable: Els identificadors a les URL són difícils d'endevinar (identificadors aleatoris en lloc de 1, 2, 3). Això no substitueix les comprovacions de permisos, però limita el dany quan una falta.

Per a cada endpoint que llegeix o canvia un registre, comprova al servidor que l'usuari connectat en és propietari o hi té accés. Si no, retorna 404. Després mostra'm com ho provaries amb dos comptes.

3. Accés a nivell de fila a la base de dades

«Accés a nivell de fila» vol dir que cada fila d'una taula (una reserva, una factura) només és visible per als usuaris als quals pertany. Hi ha dues maneres habituals d'aplicar-ho:

Qualsevol de les dues es pot fer bé. El que importa:

• Imprescindible: Si el navegador parla directament amb la base de dades (alguns productes de bases de dades allotjades ho permeten), les regles a nivell de fila estan activades per a cada taula. Sense elles, qualsevol amb la clau pública pot llegir tota la taula.
• Imprescindible: Les consultes filtren per l'usuari o l'equip actual, no per un identificador que envia el navegador.
• Recomanable: Les dades compartides (els projectes d'un equip) tenen una regla clara sobre qui és a l'equip, aplicada en un únic lloc.

4. Secrets i claus d'API

Una clau d'API és una contrasenya per a un servei. Stripe, el correu electrònic i els proveïdors d'IA n'utilitzen. Per a més context, consulta què són les variables d'entorn i els secrets.

• Imprescindible: Les claus s'emmagatzemen a les variables d'entorn o als secrets del projecte, mai escrites al codi.
• Imprescindible: Les claus que poden gastar diners o llegir dades privades només s'usen al servidor. Prova: obre el teu lloc en viu, mira el codi font de la pàgina i els fitxers JavaScript a les eines de desenvolupador, i cerca l'inici de la teva clau (per exemple sk_). No hi ha de ser.
• Imprescindible: Les claus mai no s'han enganxat al xat, a un repositori públic ni en una captura de pantalla. Si ho han estat, rota-les al proveïdor (crea'n una de nova i elimina l'antiga).
• Recomanable: Fes servir claus restringides o amb àmbit limitat quan el proveïdor les ofereixi. Stripe, per exemple, recomana claus restringides que només tinguin els permisos que necessita la teva integració.
• Recomanable: Les claus de prova i les de producció estan separades, i l'app en producció només fa servir claus de producció quan estàs preparat.

Algunes claus estan pensades per ser públiques: la clau publicable de Stripe (pk_…) o una clau de mapes restringida al teu domini. La regla fa referència a les claus que donen poder, no a totes les cadenes que semblen una clau.

5. Validació de l'entrada

Qualsevol cosa que envia un usuari (camps de formulari, pujades de fitxers, paràmetres d'URL) pot ser qualsevol cosa, no només el que permet el teu formulari.

• Imprescindible: La validació es fa al servidor, no només al navegador. Les comprovacions al navegador són per comoditat; qualsevol les pot saltar.
• Imprescindible: Les consultes a la base de dades fan servir paràmetres, no text enganxat a partir de l'entrada de l'usuari (així s'evita la injecció SQL). Demana a la IA que ho confirmi.
• Imprescindible: El text que escriuen els usuaris es mostra com a text, no s'executa com a HTML. Prova: escriu <b>hola</b> com a nom. Hauries de veure les etiquetes, no un text en negreta.
• Recomanable: Les pujades de fitxers comproven el tipus i la mida, i els fitxers pujats no es serveixen des del domini principal de l'app com a pàgines executables.
• Recomanable: Els errors que es mostren als usuaris són simples («Alguna cosa ha fallat»); els detalls van només als registres del servidor.
• Recomanable: Els webhooks de serveis com Stripe verifiquen la signatura del proveïdor abans d'actuar. Consulta què és un webhook.

Afegeix validació al servidor a cada formulari i endpoint d'API: camps obligatoris, longituds, formats i valors permesos. Rebutja qualsevol altra cosa amb un missatge clar. No mostris als usuaris els detalls interns dels errors.

6. Límits de peticions i abús

Un límit de peticions limita quantes peticions pot fer algú en un període. Sense límits, qualsevol pot endevinar contrasenyes tot el dia, inundar el teu formulari de registre o fer pujar la factura d'una API de pagament.

• Imprescindible: El login, el registre i el restabliment de contrasenya tenen límit de peticions per adreça IP i per compte.
• Imprescindible: Qualsevol cosa que et costi diners per crida (peticions a models d'IA, SMS, correu electrònic) té un límit per usuari i requereix inici de sessió.
• Recomanable: Els formularis públics (contacte, llista d'espera) tenen protecció contra spam: un límit de peticions, un camp trampa ocult o un CAPTCHA.
• Recomanable: Estableix límits de despesa o alertes amb els teus proveïdors de pagament, perquè un error o un atacant no pugui generar una factura il·limitada.

7. Dependències

Les apps es construeixen a partir de paquets de codi obert, i de tant en tant els paquets tenen vulnerabilitats conegudes.

• Recomanable: Demana a la IA que comprovi si hi ha vulnerabilitats conegudes (per a projectes JavaScript, npm audit o l'equivalent del teu gestor de paquets) i que actualitzi el que estigui afectat.
• Recomanable: Elimina els paquets que l'app ja no fa servir.
• Recomanable: Desconfia dels paquets amb molt pocs usuaris o amb noms que semblen errors tipogràfics de paquets populars.
• Més endavant: Torna a comprovar-ho cada un o dos mesos, o activa alertes automàtiques si el teu codi és a GitHub.

8. Còpies de seguretat i recuperació

La seguretat inclou poder recuperar-se dels errors, siguin teus, de la IA o d'un atacant.

• Imprescindible: Sabre on són les teves dades i si tenen còpia de seguretat. No ho donis per fet; consulta la documentació del teu proveïdor d'allotjament.
• Recomanable: Mantén una exportació periòdica pròpia de les dades importants (per exemple, una funció d'exportació a CSV o un volcat de la base de dades), guardada en un lloc separat.
• Recomanable: Guarda el codi en un sistema de control de versions, perquè es pugui restaurar qualsevol versió.
• Recomanable: Les accions destructives (eliminar el compte, eliminar el projecte) demanen confirmació, i considera un «esborrat suau» que es pugui desfer durant un temps.
• Més endavant: Prova de restaurar les dades una vegada. Una còpia de seguretat que mai no has restaurat és una esperança, no un pla.

9. Abans del llançament

• Imprescindible: El lloc en viu fa servir HTTPS a tot arreu.
• Imprescindible: Les dades d'exemple, els comptes de prova i les pàgines de depuració del desenvolupament s'han eliminat.
• Recomanable: Una política de privadesa explica quines dades recopiles i per què; en molts llocs és obligatòria si recopiles dades personals. No diguis que tens certificacions (SOC 2, HIPAA) que no tens.
• Recomanable: Tens una manera de ser contactat sobre problemes de seguretat, i saps rotar totes les claus ràpidament.

Per a una revisió prèvia al llançament més àmplia que la seguretat, consulta com portar un prototip d'IA a producció.

Quan demanar una revisió professional

Una llista de comprovació detecta els errors habituals; no substitueix un expert. Considera pagar una revisió si processes números de targeta tu mateix en lloc de fer-ho amb un pagament allotjat, si emmagatzemes dades de salut, financeres o de menors, si vens a empreses que demanen qüestionaris de seguretat, o si una filtració et faria un mal greu. Tenir el codi exportable facilita molt aquesta revisió.

Seguretat quan construeixes amb Mythex

Mythex no inclou un panell d'anàlisi de seguretat, així que la llista de comprovació de dalt és el procés a seguir. Algunes coses que ajuden:

• Secrets del projecte. Guarda les claus a la configuració del projecte → Secrets, o a través de la targeta de secrets que l'agent mostra al xat, perquè quedin fora del teu codi i dels missatges. Després de canviar un secret d'una app en viu, publica-la de nou.
• Modes Plan i Ask. Demana a l'agent que revisi els permisos sense editar: «En mode Ask, enumera cada ruta d'API i quina comprovació de permisos fa».
• /test fa que l'agent faci clic a la teva vista prèvia com a usuari, útil per a la prova de dos comptes de la secció 2.
• Els punts de control permeten desfer un canvi que hagi trencat alguna cosa.

Consulta Seguretat per a les apps que construeixes i Variables d'entorn i secrets a la documentació. Si el següent pas és afegir comptes d'usuari, llegeix com afegir inici de sessió a la teva app.

Preguntes