Листа за безбедност за апликации изградени со AI: што да проверите пред лансирање

Пред вистинските луѓе да ја користат апликација што сте ја изградиле со AI, проверете седум работи: секоја страница и секој API проверуваат кој е корисникот и што смее да направи; тајните клучеви живеат на серверот, никогаш во прелистувачот или во разговорот; целиот внес се проверува на серверот; секој корисник може да пристапи само до своите записи; најавата и скапите крајни точки имаат ограничување на барањата; зависностите се ажурни; и можете да ги вратите податоците ако нешто тргне наопаку. Листата подолу ја претвора секоја од овие работи во конкретни тестови што можете да ги извршите без да читате код.

Градителите со AI се добри во тоа да ги направат функциите да работат. Тие не се автоматски внимателни, бидејќи „внимателно“ ретко се наведува во барањето. Повеќето проблеми подолу доаѓаат од работи што никој не ги побарал, па поправката обично е да се побара.

Како да ја користите оваа листа

Минете низ неа по редослед и за секоја точка направете две работи: прашајте го AI да се увери дека е решено и тестирајте го сами. AI може да напише проверка на дозвола; само тест ви кажува дека работи. Точките се означени вака:

• Мора — направете го пред да го користи некој друг апликацијата.
• Треба — направете го пред да имате вистински корисници или вистински податоци.
• Подоцна — вреди да се направи како што апликацијата расте.

Ако имате само еден час, направете ги сите Мора.

1. Автентикација: кој е ова?

Автентикацијата значи потврдување кој е некој — обично најава. Видете што е автентикација за основите и како да додадете најава во вашата апликација за опциите.

• Мора: Секоја страница што прикажува приватни податоци бара најава. Тест: одјавете се, па залепете го URL-то на приватната страница директно во прелистувачот.
• Мора: Секоја API крајна точка зад тие страници исто така бара најава — не само страницата. Тест: одјавете се, отворете го таб за мрежа во прелистувачот и повторете барање што апликацијата го направила додека бевте најавени.
• Мора: Лозинките се чуваат хеширани со бавен алгоритам за хеширање на лозинки, никогаш во обичен текст. Упатството на OWASP за чување лозинки препорачува Argon2id прво, со scrypt, bcrypt или PBKDF2 како алтернативи. Прашајте: „Како се чуваат лозинките?“
• Треба: Линковите за промена на лозинка истекуваат и работат само еднаш.
• Треба: Колачињата за сесија се означени со Secure, HttpOnly и SameSite, а одјавувањето ја прекинува сесијата на серверот.
• Подоцна: Понудете двофакторска автентикација или најава преку добавувач што ја има.

Проверете секоја API рута и страница што враќа податоци на корисникот. Секоја мора да ги отфрла барањата од корисници што не се најавени, на серверот, не само во кодот на страницата. Наведете ги рутите што ги проверивте.

2. Авторизација: што смеат да прават?

Авторизацијата е чекор по најавата: одлучување што смее овој конкретен корисник да види и промени. Тука апликациите изградени со AI најчесто имаат сериозни дупки, бидејќи апликацијата изгледа точно — таблата на секој корисник ги покажува само неговите податоци — додека серверот ќе ги предаде туѓите податоци ако директно се побара.

• Мора: Секое читање, ажурирање и бришење проверува дека записот му припаѓа на тековниот корисник (или на неговиот тим), на серверот.
• Мора: Тестирајте го: создајте две сметки, А и Б. Како А, отворете еден од записите на А и забележете го ID-то во URL-то или во барањето од мрежата. Најавете се како Б и побарајте истото ID. Б мора да добие грешка, не податоците на А.
• Мора: Административните страници и административните API крајни точки ја проверуваат улогата на корисникот на серверот. Скривањето на административната врска не е заштита.
• Мора: Корисниците не можат да ги променат сопствената улога, цена, салдо или полиња за сопственик со уредување на барањето. Тест: во табот за мрежа, погледнете што испраќа ажурирањето на профилот. Ако вклучува полиња како role или isAdmin, прашајте го AI да ги игнорира од клиентот.
• Треба: ID-јата во URL-адресите се тешки за погодување (случајни ID-а, а не 1, 2, 3). Ова не е замена за проверки на дозволи, но ја ограничува штетата кога една недостасува.

За секоја крајна точка што чита или менува запис, проверете на серверот дали најавениот корисник е сопственик или има пристап. Ако не, вратете 404. Потоа покажете ми како би го тестирале ова со две сметки.

3. Пристап на ниво на ред во базата на податоци

„Пристап на ниво на ред“ значи дека секој ред од табела (една резервација, една фактура) е видлив само за корисниците на кои припаѓа. Постојат два вообичаени начини да се спроведе:

Еден од двата може да се направи добро. Важно е:

• Мора: Ако прелистувачот директно комуницира со базата на податоци (некои хостирани производи за бази на податоци го дозволуваат тоа), правилата на ниво на ред се вклучени за секоја табела. Без нив, секој со јавниот клуч може да ја чита целата табела.
• Мора: Барањата филтрираат по тековниот корисник или тим, а не по ID што ја испраќа прелистувачот.
• Треба: Заедничките податоци (проекти на тим) имаат јасно правило за тоа кој е во тимот, спроведено на едно место.

4. Тајни и API клучеви

API клучот е лозинка за една услуга. Stripe, е-пошта и AI добавувачите сите ги користат. За основите, видете што се променливи на средината и тајни.

• Мора: Клучевите се чуваат во променливите на средината или тајните на проектот, никогаш запишани во кодот.
• Мора: Клучевите што можат да трошат пари или да читаат приватни податоци се користат само на серверот. Тест: отворете ја вашата жива страница, погледнете го изворниот код на страницата и JavaScript датотеките во алатките за програмери и побарајте го почетокот на вашиот клуч (на пр. sk_). Не смее да се појави.
• Мора: Клучевите никогаш не се залепени во разговор, јавен репозиториум или снимка од екранот. Ако биле, ротирајте го кај добавувачот (создајте нов, избришете го стариот).
• Треба: Користете ограничени или ограничени по опсег клучеви таму каде добавувачот ги нуди. Stripe, на пример, препорачува ограничени клучеви кои имаат само дозволите што ги потребува вашата интеграција.
• Треба: Тестовите и живите клучеви се одделни, а живата апликација ги користи живите клучеви само кога сте подготвени.

Некои клучеви се наменети да бидат јавни — publishable клучот на Stripe (pk_…) или клуч за карти ограничен на вашиот домен. Правилото се однесува на клучевите што даваат моќ, а не на секоја низа што личи на клуч.

5. Проверка на внесот

Секое нешто што корисникот го испрати — полиња од форма, прикачени датотеки, параметри во URL-адресата — може да биде што било, не само она што го дозволува вашата форма.

• Мора: Проверката се прави на серверот, не само во прелистувачот. Проверките во прелистувачот се за удобност; секој може да ги прескокне.
• Мора: Барањата до базата на податоци користат параметри, а не текст залепен од внесот на корисникот (ова спречува SQL инјекција). Прашајте го AI да потврди.
• Мора: Текстот што корисниците го внесуваат се прикажува како текст, а не се извршува како HTML. Тест: внесете <b>hello</b> како ваше име. Треба да ги видите ознаките, не задебелен текст.
• Треба: Прикачувањата на датотеки проверуваат тип и големина, а прикачените датотеки не се служат од главниот домен на апликацијата како извршни страници.
• Треба: Грешките прикажани на корисниците се едноставни („Нешто тргна наопаку“); деталните грешки одат само во дневниците на серверот.
• Треба: Webhook-овите од услуги како Stripe ја проверуваат потписот на добавувачот пред да дејствуваат. Видете што е 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 нема панел за безбедносно скенирање, па листата погоре е процесот што треба да го следите. Некои работи што помагаат:

• Тајни на проектот. Чувајте клучеви под поставки на проектот → Тајни, или преку картичката со тајни што агентот ја прикажува во разговорот, за да останат надвор од вашиот код и пораки. По промена на тајна за жива апликација, објавете повторно.
• Режими Plan и Ask. Замолете го агентот да ги прегледа дозволите без уредување: „Во режимот Ask, наведи ја секоја API рута и каква проверка на дозвола прави.“
• /test го натера агентот да кликнува низ вашиот преглед како корисник — корисно за тестот со две сметки од делот 2.
• Checkpoints ви овозможуваат да вратите промена што нешто скршила.

Видете Безбедност за апликациите што ги градите и Променливи на средината и тајни во документацијата. Ако следно додавате кориснички сметки, прочитајте како да додадете најава во вашата апликација.

Прашања