AI-ээр бүтээсэн аппуудын аюулгүй байдлын шалгах хуудас: нээхээс өмнө юуг шалгах вэ

Хүмүүс AI-ээр бүтээсэн аппаа ашиглахаас өмнө долоон зүйлийг шалга: хуудас болон API бүр хэн нэвтэрсэн, юу хийж болохыг шалгадаг; нууц түлхүүрүүд серверт байдаг, хөтөч эсвэл чатад хэзээ ч байдаггүй; бүх оролт серверт баталгааждаг; хэрэглэгч бүр зөвхөн өөрийн бичлэгт хүрч чаддаг; нэвтрэлт болон үнэтэй endpoint-ууд хязгаартай; хамаарлууд шинэчлэгдсэн; мөн алдаа гарвал өгөгдлөө сэргээж чадна. Доорх шалгах хуудас эдгээр зүйлсийг кодыг уншихгүйгээр ажиллуулж болох тодорхой туршилтууд болгон хувиргана.

AI апп бүтээгчид зүйлсийг ажиллуулахад сайн. Тэд автоматаар болгоомжтой байдаггүй, учир нь “болгоомжтой” гэдэг нь ихэвчлэн хүсэлтэд бичигддэггүй. Доорх асуудлуудын ихэнх нь хэн ч асуугаагүй зүйлээс үүдэлтэй тул засах арга нь ихэвчлэн асуух явдал.

Энэ шалгах хуудсыг хэрхэн ашиглах вэ

Дараалалтай нь явж, зүйл бүрт хоёр зүйл хийгээрэй: AI-аас асуугаад тэр зүйл шийдэгдсэнийг баталгаажуулж, мөн өөрөө туршина. AI эрхийн шалгалтыг бичиж чадна; зөвхөн туршилт л ажиллаж байгааг харуулна. Зүйлүүд дараах байдлаар тэмдэглэгдэнэ:

• Заавал — хэн нэгэнд ашиглуулахаас өмнө хийгээрэй.
• Зүгээр бол — жинхэнэ хэрэглэгч, жинхэнэ өгөгдөлтэй болохоос өмнө хийгээрэй.
• Дараа — апп өсөх тусам хийх нь зүйтэй.

Хэрэв танд нэг цаг л байвал бүх Заавал зүйлийг хийгээрэй.

1. Нэвтрэлт: энэ хэн бэ?

Нэвтрэлт гэдэг нь хэн нэгнийг хэн болохыг баталгаажуулахыг хэлнэ — ихэвчлэн нэвтрэх. Үндсийг нь нэвтрэлт гэж юу вэ гэснээс, сонголтуудыг нь аппдаа нэвтрэлт нэмэх арга-аас үзнэ үү.

• Заавал: Хувийн өгөгдөл харуулдаг хуудас бүр нэвтрэлт шаарддаг. Туршилт: гарч, хувийн хуудасны URL-ийг хөтөчид шууд буулгаарай.
• Заавал: Тэдгээр хуудсуудын ард байгаа API endpoint бүр мөн нэвтрэлт шаарддаг — зөвхөн хуудас биш. Туршилт: гарсны дараа хөтчийн сүлжээний tab-аар нэвтэрсэн үедээ апп илгээсэн хүсэлтийг дахин илгээгээрэй.
• Заавал: Нууц үгийг удаан нууц үгийн hash алгоритмаар хадгалдаг, цэвэр текстээр хэзээ ч биш. OWASP-ийн нууц үг хадгалах заавар нь эхлээд Argon2id, бусад нь scrypt, bcrypt, PBKDF2-г санал болгодог. Асуух: “Нууц үгийг хэрхэн хадгалдаг вэ?”
• Зүгээр бол: Нууц үг сэргээх холбоос хугацаа дуусдаг бөгөөд зөвхөн нэг удаа ажилладаг.
• Зүгээр бол: Session cookie-д Secure, HttpOnly, SameSite тэмдэглэгдсэн, гарах үед session серверт дуусдаг.
• Дараа: Хоёр шатлалт баталгаажуулалт санал болгох, эсвэл үүнийг дэмждэг үйлчилгээ үзүүлэгчээр нэвтрүүлэх.

Хэрэглэгчийн өгөгдөл буцаадаг API маршрут бүр болон хуудас бүрийг шалгаарай. Тус бүр нэвтрээгүй хэрэглэгчдийн хүсэлтийг серверт татгалзах ёстой, зөвхөн хуудасны кодод биш. Шалгасан маршрутуудаа жагсаа.

2. Эрх: тэд юу хийж болох вэ?

Эрх гэдэг нь нэвтрэлтийн дараагийн алхам: энэ тодорхой хэрэглэгч юуг харах, өөрчлөх эрхтэйг шийдэх. AI-ээр бүтээсэн аппуудад хамгийн ихээр ноцтой нүх гардаг газар энэ юм, учир нь апп зөв харагддаг — хэрэглэгч бүрийн хяналтын самбар зөвхөн өөрийн өгөгдлийг харуулдаг — гэвч сервер хэн нэгэн шууд асахад хэн ч өгөгдөлд хандуулж өгдөг.

• Заавал: Уншихад, шинэчлэхэд, устгахад бүр бичлэг одоогийн хэрэглэгчийнх (эсвэл түүний багийнх) эсэхийг серверт шалгана.
• Заавал: Туршиж үзээрэй: хоёр бүртгэл А ба Б үүсгэ. А-аар А-ийн бичлэгийн ID-г URL эсвэл сүлжээний хүсэлтээс тэмдэглэ. Б-ээр нэвтэрч тэр ID-г хүс. Б алдаа авах ёстой, А-ийн өгөгдөл биш.
• Заавал: Админ хуудас ба админ API endpoint-ууд хэрэглэгчийн дүрийг серверт шалгана. Админ холбоосыг нуух нь хамгаалалт биш.
• Заавал: Хэрэглэгч хүсэлтийг засаж өөрийн дүр, үнэ, үлдэгдэл эсвэл эзэмшигчийн талбарыг өөрчилж чадахгүй. Туршилт: сүлжээний tab-д профайл шинэчлэх хүсэлтэд юу илгээж байгааг хар. Хэрэв role эсвэл isAdmin гэх мэт талбарууд байвал, клиентээс эдгээрийг үл тоохыг AI-аас асуу.
• Зүгээр бол: URL дахь ID-ууд таахад хэцүү байдаг (1, 2, 3 биш санамсаргүй ID). Энэ нь эрхийн шалгалтын орлуулагч биш, харин дутуу байхад хор хөнөөлийг бууруулна.

Бичлэг унших эсвэл өөрчилдөг endpoint бүрт серверт нэвтэрсэн хэрэглэгч тухайн бичлэгийн эзэмшигч эсвэл хандах эрхтэй эсэхийг шалга. Үгүй бол 404 буцаа. Дараа нь хоёр бүртгэлээр яаж туршихаа харуул.

3. Өгөгдлийн санд мөр тус бүрийн хандалт

“Мөр тус бүрийн хандалт” гэдэг нь өгөгдлийн санд мөр бүр (нэг захиалга, нэг нэхэмжлэх) зөвхөн түүнд хамаарах хэрэглэгчдэд харагдахыг хэлнэ. Үүнийг хэрэгжүүлэх хоёр түгээмэл арга байдаг:

Аль нь ч сайн хийгдэж болно. Хамгийн чухал зүйлс:

• Заавал: Хөтөч өгөгдлийн сантай шууд холбогддог бол (зарим hosted өгөгдлийн сангийн бүтээгдэхүүн зөвшөөрдөг) мөр тус бүрийн дүрмийг хүснэгт бүрт асаасан байх. Үгүй бол нийтийн түлхүүртэй хэн ч бүх хүснэгтийг унших боломжтой.
• Заавал: Асуулгууд одоогийн хэрэглэгч эсвэл багаар шүүгдэх, хөтчийн илгээсэн ID-аар биш.
• Зүгээр бол: Хуваалцсан өгөгдөл (багийн төслүүд) нэг газар хэрэгжүүлэгдсэн, хэн багт багтахыг тодорхой дүрэмтэй байх.

4. Нууц ба API түлхүүрүүд

API түлхүүр бол үйлчилгээний нууц үг. Stripe, имэйл, AI үйлчилгээ үзүүлэгчид бүгд үүнийг ашигладаг. Суурь мэдээлэл авах бол орчны хувьсагч ба нууц гэж юу вэ-ийг үзнэ үү.

• Заавал: Түлхүүрүүд төслийн орчны хувьсагч эсвэл нууцад хадгалагдсан, кодонд хэзээ ч бичигдээгүй.
• Заавал: Мөнгө зарцуулах эсвэл хувийн өгөгдөл унших чадвартай түлхүүрүүдийг зөвхөн серверт ашигладаг. Туршилт: амьд сайтаа нээж, хуудасны эх код болон JavaScript файлуудыг devtools-д үзээд түлхүүрийнхээ эхлэлийг (жишээ нь sk_) хай. Энэ нь гарч болохгүй.
• Заавал: Түлхүүрүүд чатад, нийтийн репозиторид, дэлгэцийн зурагт хэзээ ч буулгагдаагүй. Хэрэв буулгагдсан бол үйлчилгээ үзүүлэгч дээр сольж (шинэ үүсгээд, хуучныг устгах).
• Зүгээр бол: Үйлчилгээ үзүүлэгч боломжтой үед хязгаарлагдмал эсвэл зөвхөн хэрэгтэй эрхтэй түлхүүр ашигла. Жишээлбэл Stripe нь интеграцидаа хэрэгтэй эрхтэй хязгаарлагдсан түлхүүрүүдийг зөвлөдөг.
• Зүгээр бол: Туршилтын болон амьд түлхүүрүүд тусдаа, амьд аппад амьд түлхүүр зөвхөн бэлэн болсон үед ашиглагдана.

Зарим түлхүүрүүд нийтэд зориулагдсан — Stripe-ийн нийтийн түлхүүр (pk_…) эсвэл домэйндээ хязгаарлагдсан газрын зургийн түлхүүр. Дүрэм нь эрх өгдөг түлхүүрүүдэд хамаарна, түлхүүр шиг харагддаг бүх мөрөнд биш.

5. Оролтын баталгаажуулалт

Хэрэглэгчийн илгээх аливаа зүйл — маягтын талбар, файл байршуулалт, URL параметр — таны маягтын зөвшөөрсөнөөс бусад ямар ч байж болно.

• Заавал: Баталгаажуулалт серверт явагддаг, зөвхөн хөтчид биш. Хөтчийн шалгалт нь хялбар зориулалттай; хэн ч үүнийг алгасаж болно.
• Заавал: Өгөгдлийн сангийн асуулгууд параметр ашигладаг, хэрэглэгчийн оролтоос текст наасан биш (SQL injection-ээс сэргийлнэ). AI-аас баталгаажуулахыг асуу.
• Заавал: Хэрэглэгчийн оруулсан текст нь текст хэлбэрээр харуулагдана, HTML-ээр ажиллахгүй. Туршилт: нэрийнхээ оронд <b>hello</b> оруул. Та тэмдгүүдийг харах ёстой, тод үсэг биш.
• Зүгээр бол: Файл байршуулалт төрөл, хэмжээг шалгана, мөн байршуулсан файлууд аппын үндсэн домэйнээс ажиллах хуудас болгон үйлчлэгдэхгүй.
• Зүгээр бол: Хэрэглэгчдэд харуулах алдаанууд энгийн байна (“Алдаа гарлаа”); дэлгэрэнгүй алдаа зөвхөн серверийн логт.
• Зүгээр бол: Stripe гэх мэт үйлчилгээний webhook-ууд үйлдэл хийхээсээ өмнө provider-ийн гарын үсгийг баталгаажуулдаг. Харна уу: webhook гэж юу вэ.

Маягт болон API endpoint бүрт серверийн талын баталгаажуулалт нэм: шаардлагатай талбарууд, урт, формат, зөвшөөрөгдсөн утгууд. Бусдыг тодорхой мессежтэй татгалз. Хэрэглэгчдэд дотоод алдааны мэдээлэл бүү харуул.

6. Хязгаар ба урвуу ашиглалт

Хязгаар (rate limit) нь тодорхой хугацаанд хүсэлтийн тоог хязгаарладаг. Хязгаар байхгүй бол хэн ч нууц үг өдөржин таах, бүртгэлийн маягтыг үерлэх, төлбөртэй API дээр таны мөнгийг нэмэгдүүлэх боломжтой.

• Заавал: Нэвтрэх, бүртгүүлэх, нууц үг сэргээхийг IP хаяг болон бүртгэл тус бүрээр хязгаарлаж байгаарай.
• Заавал: Дуудлага бүрт мөнгө зарцуулдаг зүйл — AI загварын хүсэлт, SMS, имэйл — хэрэглэгч тус бүрийн хязгаартай, нэвтрэлт шаардана.
• Зүгээр бол: Нийтэд нээлттэй маягтууд (холбоо барих, waitlist) спам хамгаалалттай: хязгаар, нуугдсан honeypot талбар эсвэл CAPTCHA.
• Зүгээр бол: Төлбөртэй үйлчилгээ үзүүлэгчдээрээ зардлын дээд хязгаар эсвэл сэрэмжлүүлэг тавьж, алдаа эсвэл халдагч хязгааргүй нэхэмжлэх үүсгэж чадахгүй байх.

7. Хамаарлууд

Аппууд нээлттэй эхийн багцуудаас бүтдэг бөгөөд багцууд заримдаа мэдэгдэж буй сул талтай байдаг.

• Зүгээр бол: Мэдэгдэж буй сул талуудыг AI-аас шалгуул (JavaScript төслийн хувьд npm audit эсвэл таны багц менежерийн адил) мөн нөлөөлсөн зүйлсийг шинэчлүүл.
• Зүгээр бол: Аппд хэрэггүй болсон багцуудыг устга.
• Зүгээр бол: Хэрэглэгч маш цөөн багцуудаас, эсвэл алдартай багцуудын алдаатай бичиглэлтэй нэртэй багцуудаас болгоомжил.
• Дараа: Сар эсвэл хоёр сар тутамд дахин шалга, эсвэл кодоо GitHub-д байрлуулсан бол автомат сэрэмжлүүлэг асаа.

8. Нөөцлөлт ба сэргээлт

Аюулгүй байдал нь өөрийн, AI-ийн, эсвэл халдагчийн гаргасан алдаанаас сэргэх чадвартай байхыг мөн багтаана.

• Заавал: Өгөгдөл хаана байдгийг, нөөцлөгдөж байгаа эсэхийг мэд. Бүү таамагла; хостингийн баримт бичгээс шалга.
• Зүгээр бол: Чухал өгөгдлийнхөө үе үе экспорт (жишээ нь CSV экспорт эсвэл өгөгдлийн сангийн dump)-ийг тусдаа газарт хадгал.
• Зүгээр бол: Кодоо хувилбарын удирдлагад байлга, ингэснээр аль ч хувилбарыг сэргээж болно.
• Зүгээр бол: Устгах үйлдлүүд (бүртгэл устгах, төсөл устгах) баталгаажуулалт асуудаг, мөн тодорхой хугацаанд буцаах боломжтой “soft delete”-г авч үзэх.
• Дараа: Сэргээлтийг нэг удаа үнэхээр туршаарай. Хэзээ ч сэргээж үзээгүй нөөцлөлт бол найдвар, төлөвлөгөө биш.

9. Нээхээс өмнө

• Заавал: Амьд сайт бүхэлдээ HTTPS ашигладаг.
• Заавал: Хөгжүүлэлтээс үлдсэн жишээ өгөгдөл, туршилтын бүртгэл, debug хуудсуудыг устгасан.
• Зүгээр бол: Хувийн мэдээлэл цуглуулж байвал олон оронд шаардлагатай, ямар өгөгдөл яагаад цуглуулж байгаагаа хэлсэн нууцлалын бодлоготой байх. Байхгүй гэрчилгээг (SOC 2, HIPAA) бүү зарла.
• Зүгээр бол: Аюулгүй байдлын асуудлаар танд холбогдох арга, мөн бүх түлхүүрийг хурдан сольж мэддэг байх.

Аюулгүй байдлаас гадуурх, нээхийн өмнөх бүрэн шалгалтын талаар AI прототипийг production руу хэрхэн гаргах вэ-ийг үзнэ үү.

Мэргэжлийн хяналт хэзээ хэрэгтэй вэ

Шалгах хуудас нь түгээмэл алдааг олдог, харин мэргэжилтнийг орлохгүй. Хэрэв та картын дугаарыг hosted checkout-ээр биш өөрөө боловсруулдаг, эрүүл мэнд, санхүү эсвэл хүүхдийн өгөгдөл хадгалдаг, аюулгүй байдлын асуулгатай компаниудад борлуулдаг, эсвэл алдагдал таныг ноцтой хохироох бол хяналтанд хөрөнгө оруулах нь зүйтэй. Кодоо экспортлох боломжтой байвал ийм хяналт хамаагүй хялбар болно.

Mythex дээр бүтээхдээ аюулгүй байдал

Mythex-д аюулгүй байдлын скан хийх самбар байдаггүй тул дээрх шалгах хуудас л дагах процесс байна. Туслах зарим зүйлс:

• Төслийн нууцууд. Нууцуудыг төслийн тохиргоо → Нууцууд гэсэн хэсэгт хадгал, эсвэл агентын чатад харагдах нууцын картаар оруулж, ингэснээр код болон мессежээс гадуур байна. Амьд аппын нууцыг өөрчилсний дараа дахин нийтэл.
• Plan ба Ask горим. Агентаас засахгүйгээр эрхийг шалгахыг хүс: “Ask горимд бүх API маршрут болон тэдгээрийн эрхийн шалгалтыг жагсаа.”
• /test нь агентад таны preview-г хэрэглэгчээр дарахыг тушаана — 2-р хэсгийн хоёр бүртгэлийн туршилтад хэрэгтэй.
• Checkpoint нь ямар нэг зүйл эвдэрсэн өөрчлөлтийг буцаах боломж олгоно.

Мөн аппуудад зориулсан аюулгүй байдал болон орчны хувьсагч ба нууцууд баримт бичгийг үзнэ үү. Хэрэв дараагийн алхам болгож хэрэглэгчийн бүртгэл нэмэх бол аппдаа нэвтрэлт нэмэх арга-ыг уншаарай.

Асуултууд