Listă de verificare a securității pentru aplicațiile construite cu AI: ce să verifici înainte de lansare

Înainte ca oameni reali să folosească o aplicație construită cu AI, verifică șapte lucruri: fiecare pagină și fiecare API verifică cine este utilizatorul și ce are voie să facă; cheile secrete stau pe server, niciodată în browser sau în conversație; toate datele introduse sunt validate pe server; fiecare utilizator poate ajunge doar la propriile înregistrări; autentificarea și endpoint-urile costisitoare au limite de cereri; dependențele sunt actualizate; iar datele tale pot fi restaurate dacă ceva merge prost. Lista de mai jos transformă fiecare dintre acestea în teste concrete pe care le poți rula fără să citești codul.

Constructorii de aplicații cu AI sunt buni la a face funcțiile să meargă. Nu sunt automat atenți, pentru că „atenția la securitate” rareori apare în prompt. Majoritatea problemelor de mai jos apar din lucruri pe care nimeni nu le-a cerut, deci soluția este de obicei să le ceri.

Cum folosești această listă

Parcurge-o în ordine și, pentru fiecare punct, fă două lucruri: cere AI-ului să se asigure că este tratat și testează-l tu. AI-ul poate scrie o verificare de permisiuni; doar un test îți arată că funcționează. Punctele sunt marcate astfel:

• Obligatoriu — fă asta înainte ca altcineva să folosească aplicația.
• Recomandat — fă asta înainte să ai utilizatori reali sau date reale.
• Mai târziu — merită făcut pe măsură ce aplicația crește.

Dacă ai doar o oră, fă toate punctele Obligatoriu.

1. Autentificare: cine este?

Autentificarea înseamnă a confirma cine este cineva — de obicei prin autentificare (login). Vezi ce este autentificarea pentru noțiunile de bază și cum adaugi autentificare în aplicația ta pentru opțiuni.

• Obligatoriu: Fiecare pagină care afișează date private cere autentificare. Test: deconectează-te, apoi lipește în browser URL-ul unei pagini private.
• Obligatoriu: Fiecare endpoint API din spatele acestor pagini cere și el autentificare — nu doar pagina. Test: deconectează-te, deschide tab-ul de rețea din browser și reia o cerere pe care aplicația a făcut-o cât erai conectat.
• Obligatoriu: Parolele sunt stocate cu hash, cu un algoritm lent de hashing pentru parole, niciodată în text simplu. Ghidul OWASP pentru stocarea parolelor recomandă Argon2id pe primul loc, cu scrypt, bcrypt sau PBKDF2 ca alternative. Întreabă: „Cum sunt stocate parolele?”
• Recomandat: Link-urile de resetare a parolei expiră și funcționează o singură dată.
• Recomandat: Cookie-urile de sesiune sunt marcate Secure, HttpOnly și SameSite, iar deconectarea încheie sesiunea și pe server.
• Mai târziu: Oferă autentificare în doi pași sau autentificare printr-un furnizor care o are.

Verifică fiecare rută API și fiecare pagină care returnează date ale utilizatorilor. Fiecare trebuie să respingă cererile de la utilizatorii neconectați, pe server, nu doar în codul paginii. Listează rutele pe care le-ai verificat.

2. Autorizare: ce are voie să facă?

Autorizarea este pasul de după autentificare: decide ce poate vedea și modifica acest utilizator anume. Aici aplicațiile construite cu AI au cel mai des găuri serioase, pentru că aplicația arată corect — tabloul de bord al fiecărui utilizator afișează doar datele lui — în timp ce serverul va da datele oricui dacă sunt cerute direct.

• Obligatoriu: Fiecare citire, actualizare și ștergere verifică pe server că înregistrarea aparține utilizatorului curent (sau echipei lui).
• Obligatoriu: Testează: creează două conturi, A și B. Ca A, deschide una dintre înregistrările lui A și notează ID-ul din URL sau din cererea de rețea. Autentifică-te ca B și cere același ID. B trebuie să primească o eroare, nu datele lui A.
• Obligatoriu: Paginile de administrare și endpoint-urile API de administrare verifică rolul utilizatorului pe server. Ascunderea linkului de admin nu este protecție.
• Obligatoriu: Utilizatorii nu își pot schimba singuri rolul, prețul, soldul sau câmpurile de proprietar modificând cererea. Test: în tab-ul de rețea, uită-te la ce trimite o actualizare de profil. Dacă include câmpuri precum role sau isAdmin, cere AI-ului să le ignore când vin de la client.
• Recomandat: ID-urile din URL sunt greu de ghicit (ID-uri aleatorii, nu 1, 2, 3). Asta nu înlocuiește verificările de permisiuni, dar limitează paguba când una lipsește.

Pentru fiecare endpoint care citește sau modifică o înregistrare, verifică pe server că utilizatorul conectat o deține sau are voie să o acceseze. Returnează 404 dacă nu. Apoi arată-mi cum ai testa asta cu două conturi.

3. Acces la nivel de rând în baza de date

„Acces la nivel de rând” înseamnă că fiecare rând dintr-un tabel (o rezervare, o factură) este vizibil doar utilizatorilor cărora le aparține. Există două moduri frecvente de a-l aplica:

Ambele pot fi făcute bine. Ce contează:

• Obligatoriu: Dacă browserul vorbește direct cu baza de date (unele produse de baze de date găzduite permit asta), regulile la nivel de rând sunt activate pentru fiecare tabel. Fără ele, oricine are cheia publică poate citi tot tabelul.
• Obligatoriu: Interogările filtrează după utilizatorul sau echipa curentă, nu după un ID trimis de browser.
• Recomandat: Datele partajate (proiectele unei echipe) au o regulă clară privind cine face parte din echipă, aplicată într-un singur loc.

4. Secrete și chei API

O cheie API este o parolă pentru un serviciu. Stripe, e-mailul și furnizorii de AI folosesc toți chei de acest fel. Pentru context, vezi ce sunt variabilele de mediu și secretele.

• Obligatoriu: Cheile sunt stocate în variabilele de mediu sau secretele proiectului, niciodată scrise în cod.
• Obligatoriu: Cheile care pot cheltui bani sau citi date private sunt folosite doar pe server. Test: deschide site-ul live, vizualizează sursa paginii și fișierele JavaScript în instrumentele pentru dezvoltatori și caută începutul cheii tale (de exemplu sk_). Nu trebuie să apară.
• Obligatoriu: Cheile nu au fost lipite niciodată în conversație, într-un repository public sau într-o captură de ecran. Dacă au fost, rotește-le la furnizor (creează una nouă, șterge-o pe cea veche).
• Recomandat: Folosește chei restricționate sau limitate în domeniu acolo unde furnizorul le oferă. Stripe, de exemplu, recomandă chei restricționate care au doar permisiunile necesare integrării tale.
• Recomandat: Cheile de test și cele live sunt separate, iar aplicația live folosește chei live doar când ești pregătit.

Unele chei sunt concepute să fie publice — cheia publicabilă Stripe (pk_…) sau o cheie de hărți restricționată la domeniul tău. Regula se referă la cheile care acordă putere, nu la fiecare șir care arată ca o cheie.

5. Validarea datelor introduse

Orice trimite un utilizator — câmpuri de formular, fișiere încărcate, parametri din URL — poate fi orice, nu doar ce permite formularul tău.

• Obligatoriu: Validarea se face pe server, nu doar în browser. Verificările din browser sunt pentru comoditate; oricine le poate ocoli.
• Obligatoriu: Interogările din baza de date folosesc parametri, nu text lipit din datele introduse de utilizator (asta previne injecția SQL). Cere AI-ului să confirme.
• Obligatoriu: Textul introdus de utilizatori este afișat ca text, nu rulat ca HTML. Test: introdu <b>salut</b> ca nume. Ar trebui să vezi tag-urile, nu text îngroșat.
• Recomandat: Fișierele încărcate sunt verificate ca tip și dimensiune, iar fișierele încărcate nu sunt servite de pe domeniul principal al aplicației ca pagini executabile.
• Recomandat: Erorile afișate utilizatorilor sunt simple („A apărut o problemă”); detaliile erorilor merg doar în jurnalele serverului.
• Recomandat: Webhook-urile de la servicii precum Stripe verifică semnătura furnizorului înainte de a acționa. Vezi ce este un webhook.

Adaugă validare pe server pentru fiecare formular și fiecare endpoint API: câmpuri obligatorii, lungimi, formate și valori permise. Respinge orice altceva cu un mesaj clar. Nu afișa utilizatorilor detalii interne ale erorilor.

6. Limite de cereri și abuz

O limită de cereri (rate limit) plafonează câte cereri poate face cineva într-o perioadă. Fără ele, oricine poate ghici parole toată ziua, poate inunda formularul de înregistrare sau poate umfla factura unui API plătit.

• Obligatoriu: Autentificarea, înregistrarea și resetarea parolei au limită de cereri pe adresă IP și pe cont.
• Obligatoriu: Orice lucru care te costă bani pe apel — cereri către modele AI, SMS, e-mail — are o limită per utilizator și cere autentificare.
• Recomandat: Formularele publice (contact, listă de așteptare) au protecție anti-spam: o limită de cereri, un câmp ascuns de tip capcană sau un CAPTCHA.
• Recomandat: Stabilește plafoane de cheltuieli sau alerte la furnizorii plătiți, ca un bug sau un atacator să nu poată produce o factură nelimitată.

7. Dependențe

Aplicațiile sunt construite din pachete open-source, iar pachetele au uneori vulnerabilități cunoscute.

• Recomandat: Cere AI-ului să verifice vulnerabilitățile cunoscute (pentru proiectele JavaScript, npm audit sau echivalentul pentru managerul tău de pachete) și să actualizeze ce este afectat.
• Recomandat: Elimină pachetele pe care aplicația nu le mai folosește.
• Recomandat: Fii atent la pachetele cu foarte puțini utilizatori sau cu nume care arată a greșeli de scriere ale unora populare.
• Mai târziu: Reverifică la fiecare una-două luni sau activează alerte automate dacă codul tău este pe GitHub.

8. Backup-uri și recuperare

Securitatea include și capacitatea de a te recupera după greșeli — ale tale, ale AI-ului sau ale unui atacator.

• Obligatoriu: Știi unde se află datele tale și dacă sunt salvate. Nu presupune; verifică documentația găzduitorului tău.
• Recomandat: Păstrează un export periodic propriu al datelor importante (de exemplu, o funcție de export CSV sau un dump al bazei de date), stocat separat.
• Recomandat: Ține codul sub control de versiune, ca orice versiune să poată fi restaurată.
• Recomandat: Acțiunile distructive (ștergerea contului, ștergerea proiectului) cer confirmare, iar poți lua în calcul o „ștergere soft” care poate fi anulată o vreme.
• Mai târziu: Testează o dată efectiv o restaurare. Un backup pe care nu l-ai restaurat niciodată este o speranță, nu un plan.

9. Înainte de lansare

• Obligatoriu: Site-ul live folosește HTTPS peste tot.
• Obligatoriu: Datele exemplu, conturile de test și paginile de depanare din dezvoltare sunt eliminate.
• Recomandat: O politică de confidențialitate spune ce date colectezi și de ce — cerută în multe locuri dacă colectezi date personale. Nu afirma certificări (SOC 2, HIPAA) pe care nu le ai.
• Recomandat: Ai o modalitate prin care să poți fi contactat pentru probleme de securitate și știi cum să rotești rapid fiecare cheie.

Pentru o verificare mai largă înainte de lansare, dincolo de securitate, vezi cum duci un prototip AI în producție.

Când să apelezi la o revizuire profesională

O listă de verificare prinde greșelile frecvente; nu înlocuiește un expert. Ia în calcul să plătești o revizuire dacă procesezi direct numere de carduri în loc să folosești un checkout găzduit, dacă stochezi date medicale, financiare sau despre copii, dacă vinzi către companii care cer chestionare de securitate sau dacă ai avea de suferit serios dintr-o scurgere de date. Faptul că poți exporta codul face o astfel de revizuire mult mai ușoară.

Securitatea când construiești pe Mythex

Mythex nu include un panou de scanare a securității, deci lista de mai sus este procesul de urmat. Câteva lucruri care ajută:

• Secretele proiectului. Stochează cheile în setările proiectului → Secrete sau prin cardul de secrete pe care agentul îl afișează în conversație, ca să rămână în afara codului și a mesajelor. După ce schimbi un secret pentru o aplicație live, publică din nou.
• Modurile Plan și Ask. Cere agentului să revizuiască permisiunile fără să editeze: „În modul Ask, listează fiecare rută API și ce verificare de permisiuni face.”
• /test face ca agentul să parcurgă previzualizarea ta ca utilizator — util pentru testul cu două conturi din secțiunea 2.
• Punctele de control îți permit să anulezi o modificare care a stricat ceva.

Vezi Securitatea aplicațiilor pe care le construiești și Variabile de mediu și secrete în documentație. Dacă urmează să adaugi conturi de utilizator, citește cum adaugi autentificare în aplicația ta.

Întrebări