Ուղեցույցներ

AI-ով կառուցված հավելվածների անվտանգության ստուգաթերթ. ինչ ստուգել մինչև գործարկումը

Իրական մարդկանց կողմից ձեր AI-ով կառուցած հավելվածն օգտագործելուց առաջ ստուգեք յոթ բան. յուրաքանչյուր էջ և API ստուգում է, թե ով է օգտատերը և ինչ կարող է անել. գաղտնի բանալիները գտնվում են սերվերում, երբեք բրաուզերում կամ զրույցում. ամբողջ մուտքագրումը վալիդացվում է սերվերում. յուրաքանչյուր օգտատեր կարող է մատչել միայն իր գրառումներին. մուտքը և թանկ արժող վերջնակետերը ունեն սահմանաչափ. կախվածությունները թարմ են. և կարող եք վերականգնել ձեր տվյալները, եթե ինչ-որ բան սխալ ընթանա։ Ստորև ստուգաթերթը այդ յուրաքանչյուրը վերածում է կոնկրետ փորձարկումների, որոնք կարող եք կատարել առանց կոդը կարդալու։

AI հավելվածի կառուցիչները լավ են աշխատող գործառույթներ ստեղծելու մեջ։ Նրանք ինքնաբերաբար զգույշ չեն, քանի որ «զգուշությունը» հազվադեպ է հրահանգի մեջ։ Ստորև ներկայացված խնդիրների մեծ մասը գալիս է այն բաներից, որոնք ոչ ոք չի պահանջել, ուստի լուծումը սովորաբար այն է, որ հարցնեք։

Ինչպես օգտագործել այս ստուգաթերթը

Անցեք դրա միջով հերթականությամբ, և յուրաքանչյուր կետի համար արեք երկու բան. հարցրեք AI-ին, որ այն ապահովված լինի, և փորձարկեք ինքներդ։ AI-ն կարող է գրել թույլտվության ստուգում. միայն փորձարկումը ցույց է տալիս, որ այն աշխատում է։ Կետերը նշված են այսպես.

  • Պարտադիր — արեք սա, մինչև որևէ մեկը այլ օգտագործի հավելվածը։
  • Խորհուրդ — արեք սա, մինչև ունենաք իրական օգտատերեր կամ իրական տվյալներ։
  • Հետո — արժե անել հավելվածի աճի հետ մեկտեղ։

Եթե ունեք միայն մեկ ժամ, արեք բոլոր Պարտադիր կետերը։

1. Նույնականացում. ո՞վ է սա

Նույնականացումը նշանակում է հաստատել, թե ով է որևէ մեկը՝ սովորաբար մուտքը։ Տե՛ս ինչ է նույնականացումը՝ հիմունքների համար և ինչպես ավելացնել մուտք ձեր հավելվածին՝ տարբերակների համար։

  • Պարտադիր. Յուրաքանչյուր էջ, որը ցույց է տալիս մասնավոր տվյալներ, պահանջում է մուտք։ Փորձարկում. դուրս եկեք հաշվից, ապա տեղադրեք մասնավոր էջի URL-ը բրաուզերում ուղղակիորեն։
  • Պարտադիր. Այդ էջերի հետևում գտնվող յուրաքանչյուր API վերջնակետ նույնպես պահանջում է մուտք, ոչ միայն էջը։ Փորձարկում. դուրս եկեք հաշվից, բացեք բրաուզերի ցանցային ներդիրը և կրկնեք հարցումը, որը հավելվածն արեց մուտք գործած ժամանակ։
  • Պարտադիր. Գաղտնաբառերը պահվում են հեշված՝ դանդաղ գաղտնաբառի հեշավորման ալգորիթմով, երբեք սովորական տեքստով։ OWASP-ի գաղտնաբառերի պահպանման ուղեցույցը առաջարկում է նախ Argon2id, իսկ այլընտրանքներ՝ scrypt, bcrypt կամ PBKDF2։ Հարցրեք. «Ինչպե՞ս են պահվում գաղտնաբառերը»։
  • Խորհուրդ. Գաղտնաբառի վերականգնման հղումները լրանում են և աշխատում են միայն մեկ անգամ։
  • Խորհուրդ. Սեսիայի cookie-ները նշված են Secure, HttpOnly և SameSite, և դուրս գալը ավարտում է սեսիան սերվերում։
  • Հետո. Առաջարկեք երկգործոն նույնականացում կամ մուտք մատակարարի միջոցով, որն այն ունի։

Ստուգեք յուրաքանչյուր API երթուղի և էջ, որը վերադարձնում է օգտատիրոջ տվյալներ։ Յուրաքանչյուրը պետք է մերժի այն հարցումները, որոնք գալիս են մուտք չգործած օգտատերերից, սերվերում, ոչ միայն էջի կոդում։ Թվարկեք ստուգած երթուղիները։

2. Թույլտվություն. ի՞նչ են իրավունք ունեն անել

Թույլտվությունը մուտքից հետո եկող քայլն է. որոշում է, թե այս կոնկրետ օգտատերը ինչ կարող է տեսնել և փոխել։ Հենց այստեղ են AI-ով կառուցված հավելվածները հաճախ ունենում լուրջ բացեր, քանի որ հավելվածը ճիշտ է երևում՝ յուրաքանչյուր օգտատիրոջ վահանակը ցույց է տալիս միայն իր տվյալները, մինչդեռ սերվերը ուրախությամբ կտա որևէ մեկի տվյալները, եթե ուղղակիորեն խնդրվի։

  • Պարտադիր. Յուրաքանչյուր կարդալու, թարմացնելու և ջնջելու գործողություն սերվերում ստուգում է, որ գրառումը պատկանում է ընթացիկ օգտատիրոջը (կամ նրա թիմին)։
  • Պարտադիր. Փորձարկեք. ստեղծեք երկու հաշիվ՝ A և B։ A-ով մուտք գործած՝ բացեք A-ի գրառումներից մեկը և նշեք ID-ն URL-ում կամ ցանցային հարցման մեջ։ Մուտք գործեք որպես B և պահանջեք նույն ID-ն։ B-ն պետք է ստանա սխալ, ոչ թե A-ի տվյալները։
  • Պարտադիր. Ադմինիստրատորի էջերը և ադմինիստրատորի API վերջնակետերը սերվերում ստուգում են օգտատիրոջ դերը։ Ադմին հղումը թաքցնելը պաշտպանություն չէ։
  • Պարտադիր. Օգտատերերը չեն կարող փոխել իրենց դերը, գինը, մնացորդը կամ սեփականատիրոջ դաշտերը՝ խմբագրելով հարցումը։ Փորձարկում. ցանցային ներդիրում նայեք, թե ինչ է ուղարկում պրոֆիլի թարմացումը։ Եթե այնտեղ կան այնպիսի դաշտեր, ինչպիսիք են role կամ isAdmin, խնդրեք AI-ին դրանք անտեսել կլիենտից։
  • Խորհուրդ. URL-ներում ID-ները դժվար գուշակելի են (պատահական ID-ներ, այլ ոչ թե 1, 2, 3)։ Սա թույլտվության ստուգումների փոխարինող չէ, բայց սահմանափակում է վնասը, երբ ստուգումը բացակայում է։

Յուրաքանչյուր վերջնակետի համար, որը կարդում կամ փոխում է գրառում, ստուգեք սերվերում, որ մուտք գործած օգտատերը պատկանում է դրան կամ իրավունք ունի մատչելու։ Եթե ոչ, վերադարձրեք 404։ Այնուհետև ցույց տվեք, թե ինչպես կփորձարկեիք սա երկու հաշիվներով։

3. Տողերի մակարդակի մատչելիությունը տվյալների բազայում

«Տողերի մակարդակի մատչելիություն» նշանակում է, որ աղյուսակի յուրաքանչյուր տող (մեկ ամրագրում, մեկ հաշիվ-ապրանքագիր) տեսանելի է միայն այն օգտատերերին, որոնց է պատկանում։ Այն ապահովելու երկու սովորական եղանակ կա.

ՄոտեցումԻնչպես է աշխատումԻնչին ուշադրություն դարձնել
Ձեր սերվերի կոդումՅուրաքանչյուր հարցում ներառում է ֆիլտր, օրինակ՝ «որտեղ սեփականատերը ընթացիկ օգտատերն է»Մեկ մոռացված ֆիլտրը բացում է ամեն ինչ
Տվյալների բազայում (օրինակ՝ Postgres row-level security)Ինքը տվյալների բազան մերժում է այն տողերը, որոնք օգտատերը չի կարող տեսնելԱվելի շատ կարգավորում. սերվերը պետք է միանա որպես ճիշտ օգտատեր

Ամենը կարող է լավ արվել։ Կարևորն է հետևյալը.

  • Պարտադիր. Եթե բրաուզերը ուղղակիորեն խոսում է տվյալների բազայի հետ (որոշ հոստավորվող տվյալների բազայի արտադրանքներ թույլ են տալիս դա), տողերի մակարդակի կանոնները միացված են յուրաքանչյուր աղյուսակի համար։ Առանց դրանց՝ ցանկացած մարդ հանրային բանալիով կարող է կարդալ ամբողջ աղյուսակը։
  • Պարտադիր. Հարցումները ֆիլտրվում են ընթացիկ օգտատիրոջ կամ թիմի հիման վրա, ոչ թե բրաուզերի ուղարկած ID-ով։
  • Խորհուրդ. Համօգտագործվող տվյալները (թիմի նախագծերը) ունեն հստակ կանոն, թե ով է թիմում, որը կիրառվում է մեկ տեղում։

4. Գաղտնիքներ և API բանալիներ

API բանալին ծառայության գաղտնաբառ է։ Stripe-ը, էլ. փոստը և AI մատակարարները բոլորն էլ օգտագործում են դրանք։ Ֆոնային տեղեկության համար տե՛ս ինչ են միջավայրի փոփոխականները և գաղտնիքները։

  • Պարտադիր. Բանալիները պահվում են նախագծի միջավայրի փոփոխականներում կամ գաղտնիքներում, երբեք կոդում գրված։
  • Պարտադիր. Այն բանալիները, որոնք կարող են գումար ծախսել կամ կարդալ մասնավոր տվյալներ, օգտագործվում են միայն սերվերում։ Փորձարկում. բացեք ձեր կենդանի կայքը, դիտեք էջի աղբյուրը և JavaScript ֆայլերը developer tools-ում և որոնեք ձեր բանալիի սկիզբը (օրինակ՝ sk_)։ Այն չպետք է երևա։
  • Պարտադիր. Բանալիները երբեք չեն տեղադրվել զրույցում, հանրային պահոցում կամ սքրինշոթում։ Եթե տեղադրվել են, փոխեք (rotate) դրանք մատակարարի մոտ (ստեղծեք նորը, ջնջեք հինը)։
  • Խորհուրդ. Օգտագործեք սահմանափակ կամ շրջանակավորված բանալիներ, որտեղ մատակարարն առաջարկում է դրանք։ Օրինակ՝ Stripe-ը խորհուրդ է տալիս սահմանափակ բանալիներ, որոնք ունեն միայն ձեր ինտեգրացիայի համար անհրաժեշտ թույլտվությունները։
  • Խորհուրդ. Թեստային և կենդանի բանալիները առանձին են, և կենդանի հավելվածը օգտագործում է կենդանի բանալիներ միայն այն ժամանակ, երբ պատրաստ եք։

Որոշ բանալիներ նախատեսված են հանրային լինելու համար. Stripe-ի հրապարակային բանալին (pk_…) կամ քարտեզների բանալին, որը սահմանափակված է ձեր տիրույթով։ Կանոնը վերաբերում է այն բանալիներին, որոնք իշխանություն են տալիս, ոչ թե յուրաքանչյուր տողի, որը նման է բանալու։

5. Մուտքագրման վալիդացիա

Օգտատիրոջ ուղարկած ամեն բան՝ ձևի դաշտեր, ֆայլերի վերբեռնումներ, URL պարամետրեր, կարող է լինել ցանկացած բան, ոչ միայն այն, ինչ թույլ է տալիս ձեր ձևը։

  • Պարտադիր. Վալիդացիան կատարվում է սերվերում, ոչ միայն բրաուզերում։ Բրաուզերի ստուգումները հարմարության համար են. ցանկացածը կարող է դրանք շրջանցել։
  • Պարտադիր. Տվյալների բազայի հարցումները օգտագործում են պարամետրեր, ոչ թե օգտատիրոջ մուտքից կպցրած տեքստ (սա կանխում է SQL ներարկումը)։ Հարցրեք AI-ին հաստատելու համար։
  • Պարտադիր. Օգտատերերի մուտքագրած տեքստը ցուցադրվում է որպես տեքստ, ոչ թե կատարվում է որպես HTML։ Փորձարկում. որպես ձեր անուն մուտքագրեք <b>hello</b>։ Պետք է տեսնեք պիտակները, ոչ թե թավ տեքստ։
  • Խորհուրդ. Ֆայլերի վերբեռնումները ստուգում են տիպը և չափը, իսկ վերբեռնված ֆայլերը չեն սպասարկվում ձեր հավելվածի հիմնական տիրույթից որպես աշխատող էջեր։
  • Խորհուրդ. Օգտատերերին ցուցադրվող սխալները պարզ են («Ինչ-որ բան սխալ ընթացավ»). մանրամասն սխալները գնում են միայն սերվերի մատյաններ։
  • Խորհուրդ. Stripe-ի նման ծառայությունների webhook-ները ստուգում են մատակարարի ստորագրությունը նախքան գործելը։ Տե՛ս ինչ է webhook-ը։

Ավելացրեք սերվերային վալիդացիա յուրաքանչյուր ձևի և API վերջնակետի համար. պարտադիր դաշտեր, երկարություններ, ձևաչափեր և թույլատրելի արժեքներ։ Մերժեք ամեն ինչ այլ՝ հստակ հաղորդագրությամբ։ Մի ցույց տվեք ներքին սխալների մանրամասները օգտատերերին։

6. Սահմանաչափեր և չարաշահում

Սահմանաչափը սահմանում է, թե քանի հարցում կարող է արվել որոշակի ժամանակահատվածում։ Առանց դրանց՝ ցանկացած մարդ ամբողջ օրը կարող է գուշակել գաղտնաբառեր, հեղեղել ձեր գրանցման ձևը կամ ծախսել ձեր վճարովի API-ի գումարը։

  • Պարտադիր. Մուտքը, գրանցումը և գաղտնաբառի վերականգնումը սահմանափակված են ըստ IP հասցեի և ըստ հաշվի։
  • Պարտադիր. Ցանկացած բան, որն ամեն կանչի համար արժե ձեզ գումար՝ AI մոդելի հարցումներ, SMS, էլ. փոստ, ունի օգտատիրոջ սահմանաչափ և պահանջում է մուտք։
  • Խորհուրդ. Հանրային ձևերը (կոնտակտ, սպասման ցուցակ) ունեն սպամի պաշտպանություն. սահմանաչափ, թաքնված «մեղրամանի» դաշտ կամ CAPTCHA։
  • Խորհուրդ. Սահմանեք ծախսերի սահմանաչափեր կամ ազդանշաններ ձեր վճարովի մատակարարների մոտ, որպեսզի սխալը կամ հարձակվողը չկարողանա առաջացնել անսահմանափակ հաշիվ։

7. Կախվածություններ

Հավելվածները կառուցվում են բաց կոդով փաթեթներից, և փաթեթներն երբեմն ունեն հայտնի խոցելիություններ։

  • Խորհուրդ. Խնդրեք AI-ին ստուգել հայտնի խոցելիությունները (JavaScript նախագծերի համար՝ npm audit կամ ձեր փաթեթների կառավարչի համարժեքը) և թարմացնել ազդվածները։
  • Խորհուրդ. Հեռացրեք այն փաթեթները, որոնք հավելվածը այլևս չի օգտագործում։
  • Խորհուրդ. Զգույշ եղեք այն փաթեթների նկատմամբ, որոնք ունեն շատ քիչ օգտատերեր կամ անուններ, որոնք նման են հայտնիների տառասխալներին։
  • Հետո. Ստուգեք յուրաքանչյուր մեկ-երկու ամիսը մեկ կամ միացրեք ավտոմատ ազդանշաններ, եթե ձեր կոդը GitHub-ում է։

8. Պահուստներ և վերականգնում

Անվտանգությունը ներառում է սխալներից վերականգնվելու ունակությունը՝ ձերից, AI-ի կամ հարձակվողի։

  • Պարտադիր. Իմացեք, թե որտեղ են ձեր տվյալները և արդյոք դրանք պահուստավորված են։ Մի ենթադրեք. ստուգեք ձեր հոստի փաստաթղթերը։
  • Խորհուրդ. Պահեք ձեր սեփական պարբերական արտահանումը կարևոր տվյալների (օրինակ՝ CSV արտահանման գործառույթ կամ տվյալների բազայի դամփ), առանձին տեղում։
  • Խորհուրդ. Պահեք ձեր կոդը տարբերակների կառավարման համակարգում, որպեսզի ցանկացած տարբերակ վերականգնվի։
  • Խորհուրդ. Ոչնչացնող գործողությունները (հաշվի ջնջում, նախագծի ջնջում) պահանջում են հաստատում, և դիտարկեք «փափուկ ջնջում», որը կարելի է հետ բերել որոշ ժամանակ։
  • Հետո. Մեկ անգամ փորձարկեք իրական վերականգնում։ Պահուստը, որը երբեք չեք վերականգնել, հույս է, ոչ թե պլան։

9. Գործարկումից առաջ

  • Պարտադիր. Կենդանի կայքը ամենուր օգտագործում է HTTPS։
  • Պարտադիր. Զարգացման ժամանակ ստեղծված նմուշային տվյալները, թեստային հաշիվները և վրիպազերծման էջերը հեռացված են։
  • Խորհուրդ. Գաղտնիության քաղաքականությունը նշում է, թե ինչ տվյալներ եք հավաքում և ինչու. շատ երկրներում դա պարտադիր է, եթե հավաքում եք անձնական տվյալներ։ Մի հայտարարեք սերտիֆիկացումներ (SOC 2, HIPAA), որոնք չունեք։
  • Խորհուրդ. Ունեք միջոց՝ անվտանգության խնդիրների մասին կապ հաստատելու համար, և գիտեք, թե ինչպես արագ փոխել յուրաքանչյուր բանալի։

Ավելի լայն նախագործարկային ստուգման համար՝ անվտանգությունից դուրս, տե՛ս ինչպես տանել AI նախատիպը արտադրություն։

Երբ պետք է մասնագիտական վերանայում

Ստուգաթերթը բռնում է սովորական սխալները, բայց չի փոխարինում փորձագետին։ Մտածեք վերանայման վճարելու մասին, եթե դուք ինքներդ եք մշակում քարտերի համարները՝ փոխանակ վճարվող հաճախորդի միջոցով, պահում եք առողջական, ֆինանսական կամ երեխաների տվյալներ, վաճառում եք ընկերություններին, որոնք անվտանգության հարցաթերթիկներ են պահանջում, կամ կարող եք լրջորեն վնասվել արտահոսքից։ Եթե ձեր կոդը արտահանելի է, այդ վերանայումը շատ ավելի հեշտ է։

Անվտանգություն Mythex-ով կառուցելիս

Mythex-ն չունի անվտանգության սկանավորման վահանակ, ուստի վերևի ստուգաթերթն է հետևելու գործընթացը։ Մի քանի բան, որոնք օգնում են.

  • Նախագծի գաղտնիքներ. Պահեք բանալիները նախագծի կարգավորումներ → Secrets բաժնում կամ գործակալի զրույցում ցուցադրվող գաղտնիքների քարտի միջոցով, որպեսզի դրանք մնան ձեր կոդից և հաղորդագրություններից դուրս։ Կենդանի հավելվածի գաղտնիքը փոխելուց հետո նորից հրապարակեք։
  • Plan և Ask ռեժիմներ. Խնդրեք գործակալին վերանայել թույլտվությունները՝ առանց խմբագրելու. «Ask ռեժիմում թվարկիր յուրաքանչյուր API երթուղի և թե ինչ թույլտվության ստուգում է անում»։
  • /test թույլ է տալիս գործակալին սեղմել ձեր նախադիտման միջով որպես օգտատեր. օգտակար է բաժին 2-ում նշված երկու հաշիվների փորձարկման համար։
  • Checkpoint-ները թույլ են տալիս հետ գլորել փոփոխությունը, որը ինչ-որ բան կոտրել է։

Տե՛ս Անվտանգություն ձեր կառուցած հավելվածների համար և Միջավայրի փոփոխականներ և գաղտնիքներ փաստաթղթերում։ Եթե հաջորդը ավելացնում եք օգտատիրոջ հաշիվներ, կարդացեք ինչպես ավելացնել մուտք ձեր հավելվածին։

Հարցեր

Արդյո՞ք AI-ով կառուցված հավելվածները պակաս ապահով են

Ինքնին ոչ, բայց AI կառուցիչները օպտիմիզացված են այնպես, որ բաները աշխատեն, և անվտանգության ստուգումները հեշտ է բաց թողնել, երբ որևէ մեկը դրանք չի պահանջում։ Ամենատարածված բացերն են սերվերում թույլտվության ստուգումների բացակայությունը և API բանալիներ այնտեղ, որտեղ բրաուզերը կարող է դրանք կարդալ։

Ո՞րն է AI-ով կառուցված հավելվածի ամենակարևոր անվտանգության ստուգումը

Մուտք գործեք որպես մեկ օգտատեր և փորձեք դիտել կամ փոխել մեկ այլ օգտատիրոջ տվյալները՝ և հավելվածի էջերի միջոցով, և URL-երում ID-ները փոխելով։ Թույլտվության նման խափանված վերահսկումը OWASP Top 10:2025 ցանկում վեբ հավելվածների անվտանգության ռիսկերի առաջին տեղում է։

Որտե՞ղ պետք է դնել API բանալիները AI-ով կառուցված հավելվածում

Նախագծի միջավայրի փոփոխականներում կամ գաղտնիքներում, որոնք օգտագործվում են միայն սերվերային կոդի կողմից։ Այն բանալիները, որոնք կարող են գումար ծախսել կամ կարդալ մասնավոր տվյալներ, երբեք չպետք է հայտնվեն բրաուզերի կոդում, զրույցում կամ Git պահոցում։

Արդյո՞ք գործարկումից առաջ անհրաժեշտ է անվտանգության աուդիտ

Փոքր հավելվածի համար ցածր ռիսկի տվյալներով՝ այս տիպի ստուգաթերթով աշխատելը ողջամիտ սկիզբ է։ Եթե անմիջապես մշակում եք վճարումներ, առողջության, ֆինանսական կամ երեխաների տվյալներ, կամ ունեք պայմանագրային անվտանգության պահանջներ, ապա թող որակավորված անձը վերանայի այն։

Mythex · Pricing · Կառուցեք ամեն ինչ AI-ով · Կաղապարներ կայքերի և հավելվածների համար · Mythex-ի համեմատությունները · AI-ով հավելվածների ստեղծման բառարան · Անվճար գործիքներ AI-ով հավելվածներ ստեղծելու համար · English

English አማርኛ العربية Български বাংলা Bosanski Català Čeština Dansk Deutsch Ελληνικά Español Español (España) Eesti فارسی Suomi Français Français (Canada) ગુજરાતી हिन्दी Hrvatski Magyar Bahasa Indonesia Íslenska Italiano 日本語 ქართული Қазақ тілі ಕನ್ನಡ 한국어 Lietuvių Latviešu Македонски മലയാളം Монгол मराठी Bahasa Melayu မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Русский Slovenčina Slovenščina Soomaali Shqip Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)