Контролен списък за сигурност за приложения, създадени с AI: какво да проверите преди пускане

Преди реални хора да използват приложение, създадено с AI, проверете седем неща: всяка страница и всеки API проверява кой е потребителят и какво му е позволено да прави; тайните ключове са на сървъра, никога в браузъра или в чата; всички входни данни се валидират на сървъра; всеки потребител може да достига само своите записи; вход и скъпо струващите крайни точки имат лимит на заявките; зависимостите са актуални; и можете да възстановите данните си, ако нещо се обърка. Контролният списък по-долу превръща всяко от тях в конкретни тестове, които можете да направите, без да четете код.

Инструментите за създаване на приложения с AI са добри в това да карат функциите да работят. Те не са автоматично внимателни, защото „внимателност“ рядко присъства в заявката. Повечето от проблемите по-долу идват от неща, които никой не е поискал, затова решението обикновено е да попитате.

Как да използвате този контролен списък

Преминете през него по ред и за всеки пункт направете две неща: попитайте AI дали е обработен, и тествайте сами. AI може да напише проверка на правата; само тест показва, че тя работи. Пунктовете са маркирани така:

• Задължително — направете го, преди някой друг да използва приложението.
• Препоръчително — направете го, преди да имате реални потребители или реални данни.
• По-късно — струва си, когато приложението расте.

Ако имате само час, направете всички задължителни.

1. Удостоверяване: кой е това?

Удостоверяването означава потвърждаване кой е даден човек – обикновено чрез вход. Вижте какво е удостоверяване за основите и как да добавите вход в приложението си за възможностите.

• Задължително: Всяка страница, която показва лични данни, изисква вход. Тест: излезте от профила, после поставете адреса на личната страница директно в браузъра.
• Задължително: Всяка API крайна точка зад тези страници също изисква вход – не само страницата. Тест: излезте от профила, отворете мрежовия раздел на браузъра и повторете заявка, която приложението е направило, докато сте били влезли.
• Задължително: Паролите се съхраняват хеширани с бавен алгоритъм за хеширане на пароли, никога в чист текст. Насоките на OWASP за съхранение на пароли препоръчват първо Argon2id, а като алтернативи – scrypt, bcrypt или PBKDF2. Попитайте: „Как се съхраняват паролите?“
• Препоръчително: Линковете за смяна на парола изтичат и работят само веднъж.
• Препоръчително: Бисквитките на сесията са маркирани с Secure, HttpOnly и SameSite, а изходът от профила прекратява сесията на сървъра.
• По-късно: Предложете двуфакторно удостоверяване или вход през доставчик, който го поддържа.

Проверете всяка API заявка и страница, която връща потребителски данни. Всяка от тях трябва да отхвърля заявки от потребители, които не са влезли, на сървъра, а не само в кода на страницата. Изброете заявките, които сте проверили.

2. Оторизация: какво има право да прави?

Оторизацията е стъпката след вход: решаване какво този конкретен потребител може да вижда и променя. Тук приложенията, създадени с AI, най-често имат сериозни пропуски, защото приложението изглежда правилно – таблото на всеки потребител показва само неговите данни, – но сървърът ще предаде чужди данни, ако бъде попитан директно.

• Задължително: Всяко четене, актуализиране и изтриване проверява на сървъра, че записът принадлежи на текущия потребител (или на неговия екип).
• Задължително: Тествайте: създайте два профила, А и Б. Като А, отворете един от записите на А и запишете идентификатора в адреса или в мрежовата заявка. Влезте като Б и заявете същия идентификатор. Б трябва да получи грешка, а не данните на А.
• Задължително: Административните страници и административните API крайни точки проверяват ролята на потребителя на сървъра. Скриването на административния линк не е защита.
• Задължително: Потребителите не могат да променят собствената си роля, цена, баланс или полета за собственик, като редактират заявката. Тест: в мрежовия раздел вижте какво изпраща актуализацията на профила. Ако включва полета като role или isAdmin, помолете AI да ги игнорира от клиента.
• Препоръчително: Идентификаторите в адресите са трудни за отгатване (случайни идентификатори, а не 1, 2, 3). Това не замества проверките на правата, но ограничава щетите, когато такава липсва.

За всяка крайна точка, която чете или променя запис, проверете на сървъра дали влезлият потребител е собственик на записа или има право на достъп. Върнете 404, ако не е. След това покажете как бихте тествали това с два профила.

3. Достъп до ниво ред в базата данни

„Достъп до ниво ред“ означава, че всеки ред от таблица (една резервация, една фактура) се вижда само от потребителите, към които принадлежи. Има два често срещани начина да се наложи това:

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

• Задължително: Ако браузърът говори директно с базата данни (някои хоствани продукти за бази данни позволяват това), правилата за ниво ред са включени за всяка таблица. Без тях всеки с публичния ключ може да прочете цялата таблица.
• Задължително: Заявките филтрират по текущия потребител или екип, а не по идентификатор, изпратен от браузъра.
• Препоръчително: Общите данни (проектите на екип) имат ясно правило кой е в екипа, налагано на едно място.

4. Тайни ключове и API ключове

API ключът е парола за една услуга. Stripe, имейл и AI доставчиците използват такива. За основите вижте какво са променливите на средата и тайните.

• Задължително: Ключовете се съхраняват в променливите на средата или тайните на проекта, никога записани в кода.
• Задължително: Ключовете, с които може да се харчат пари или да се четат лични данни, се използват само на сървъра. Тест: отворете живия си сайт, вижте изходния код на страницата и JavaScript файловете в инструментите за разработчици и търсете началото на ключа си (например sk_). Той не трябва да се появява.
• Задължително: Ключовете никога не са били поставяни в чата, в публично хранилище или на екранна снимка. Ако е имало такова, сменете го при доставчика (създайте нов и изтрийте стария).
• Препоръчително: Използвайте ограничени или обхватни ключове там, където доставчикът ги предлага. Stripe, например, препоръчва ограничени ключове, които имат само правата, нужни на интеграцията ви.
• Препоръчително: Тестовите и живите ключове са разделени, а живото приложение използва живи ключове само когато сте готови.

Някои ключове са предназначени да са публични – publishable ключът на Stripe (pk_…) или ключ за карти, ограничен до вашия домейн. Правилото се отнася до ключовете, които дават власт, а не до всеки низ, който прилича на ключ.

5. Валидиране на входни данни

Всичко, което потребител изпраща – полета във формуляри, качвани файлове, параметри в адреси – може да бъде каквото и да е, а не само това, което позволява формулярът ви.

• Задължително: Валидирането се извършва на сървъра, не само в браузъра. Проверките в браузъра са за удобство; всеки може да ги заобиколи.
• Задължително: Заявките към базата данни използват параметри, а не текст, слепен от потребителски вход (това предотвратява SQL инжекции). Помолете AI да потвърди.
• Задължително: Текстът, който потребителите въвеждат, се показва като текст, а не се изпълнява като HTML. Тест: въведете <b>hello</b> като име. Трябва да видите самите тагове, а не получен удебелен текст.
• Препоръчително: Качените файлове проверяват типа и размера си, а качените файлове не се сервират от основния домейн на приложението като изпълними страници.
• Препоръчително: Грешките, показвани на потребителите, са прости („Нещо се обърка“); подробните грешки отиват само в сървърните дневници.
• Препоръчително: Уебхуковете от услуги като Stripe проверяват подписа на доставчика, преди да действат. Вижте какво е уебхук.

Добавете валидиране на сървъра към всеки формуляр и 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.
• Контролни точки ви позволяват да върнете промяна, която е развалила нещо.

Вижте Сигурност за приложенията, които създавате и Променливи на средата и тайни в документацията. Ако следващо добавяте потребителски профили, прочетете как да добавите вход в приложението си.

Въпроси