Security Checklist para sa mga AI-Built App: Ano ang Dapat Suriin Bago Ilunsad

Bago gamitin ng totoong tao ang app na ginawa mo gamit ang AI, suriin ang pitong bagay: sinusuri ng bawat pahina at API kung sino ang user at kung ano ang puwede niyang gawin; nasa server ang mga secret key, hindi sa browser o chat; sinusuri sa server ang lahat ng input; bawat user ay sariling records lang ang maaabot; rate-limited ang log-in at mga endpoint na magastos; updated ang mga dependency; at puwede mong maibalik ang data kapag may nangyaring mali. Ginagawang tiyak na test na puwede mong patakbuhin nang hindi nagbabasa ng code ng bawat isa sa mga ito ang checklist sa ibaba.

Magaling ang mga AI app builder sa paggawa ng gumaganang feature. Hindi sila awtomatikong maingat, dahil bihirang nasa prompt ang "maingat". Karamihan sa mga problemang nasa ibaba ay nagmumula sa mga bagay na walang nagtanong, kaya kadalasan ang ayos ay itanong ito.

Paano gamitin ang checklist na ito

Gawin ito nang sunud-sunod, at sa bawat item ay gawin ang dalawang bagay: tanungin ang AI para masigurong nahawakan ito, at subukan mo mismo. Kayang gumawa ng AI ng permission check; tanging test ang magsasabi kung gumagana ito. Minarkahan ang mga item:

• Must: Gawin ito bago gamitin ng iba ang app.
• Should: Gawin ito bago ka magkaroon ng totoong user o totoong data.
• Later: Sulit gawin habang lumalaki ang app.

Kung isang oras lang ang mayroon ka, gawin ang lahat ng Must.

1. Authentication: sino ito?

Ang authentication ay ang pagkumpirma kung sino ang isang tao, karaniwan sa pamamagitan ng log-in. Tingnan ang ano ang authentication para sa mga pangunahing kaalaman at paano magdagdag ng log-in sa app mo para sa mga opsyon.

• Must: Ang bawat pahinang nagpapakita ng pribadong data ay nangangailangan ng log-in. Test: mag-log out, pagkatapos ay i-paste ang URL ng pribadong pahina nang direkta sa browser.
• Must: Ang bawat API endpoint sa likod ng mga pahinang iyon ay nangangailangan din ng log-in, hindi lang ang pahina. Test: mag-log out, buksan ang network tab ng browser, at subukang ulitin ang request na ginawa ng app noong naka-log in ka.
• Must: Naka-hash ang mga password gamit ang mabagal na password-hashing algorithm, hindi kailanman plain text. Ayon sa gabay ng OWASP sa pag-iimbak ng password, Argon2id ang unang rekomendasyon, na may scrypt, bcrypt o PBKDF2 bilang alternatibo. Itanong: "Paano iniimbak ang mga password?"
• Should: Nag-e-expire ang password reset link at isang beses lang gumagana.
• Should: Nakamarka ang session cookie bilang Secure, HttpOnly at SameSite, at ang pag-log out ay nagtatapos ng session sa server.
• Later: Mag-alok ng two-factor authentication, o sign-in sa pamamagitan ng provider na mayroon nito.

Suriin ang bawat API route at pahinang nagbabalik ng data ng user. Dapat nitong tanggihan ang mga request mula sa user na hindi naka-log in, sa server, hindi lang sa code ng pahina. Ilista ang mga route na sinuri mo.

2. Authorization: ano ang puwede nilang gawin?

Ang authorization ay ang hakbang pagkatapos ng log-in: pagpapasya kung anong data ang puwedeng makita at baguhin ng partikular na user na ito. Dito kadalasang may malalaking butas ang mga AI-built app, dahil mukhang tama ang app: nakikita ng bawat user ang sariling data sa dashboard, pero ibibigay ng server ang data ng sinuman kung direktang hihingin.

• Must: Sinusuri ng bawat read, update at delete na ang record ay pag-aari ng kasalukuyang user (o ng kanyang team), sa server.
• Must: Subukan ito: gumawa ng dalawang account, A at B. Bilang A, buksan ang isa sa mga record ni A at itala ang ID sa URL o network request. Mag-log in bilang B at hilingin ang parehong ID. Dapat mag-error si B, hindi makuha ang data ni A.
• Must: Sinusuri ng mga admin page at admin API endpoint ang role ng user sa server. Hindi proteksyon ang pagtatago ng admin link.
• Must: Hindi nagagawang baguhin ng user ang sarili niyang role, presyo, balance o owner field sa pamamagitan ng pag-edit ng request. Test: sa network tab, tingnan kung ano ang ipinapadala ng profile update. Kung may kasamang field gaya ng role o isAdmin, hilingin sa AI na huwag itong tanggapin mula sa client.
• Should: Mahirap hulaan ang mga ID sa URL (random na ID sa halip na 1, 2, 3). Hindi ito kapalit ng permission check, pero nililimitahan nito ang pinsala kapag may nawawalang check.

Para sa bawat endpoint na nagbabasa o nagbabago ng record, suriin sa server kung ang naka-log in na user ang may-ari nito o pinapayagang i-access ito. Magbalik ng 404 kung hindi. Pagkatapos, ipakita sa akin kung paano ito susubukan gamit ang dalawang account.

3. Row-level access sa database

Ang "row-level access" ay nangangahulugang ang bawat row ng isang table (isang booking, isang invoice) ay nakikita lang ng mga user na pag-aari nito. May dalawang karaniwang paraan para ipatupad ito:

Puwedeng gawin nang maayos ang alinman. Ang mahalaga:

• Must: Kung direktang nakikipag-usap ang browser sa database (may ilang hosted database product na nagpapahintulot nito), naka-on ang row-level rule sa bawat table. Kung wala, sinumang may public key ay makakabasa ng buong table.
• Must: Ang mga query ay nagfi-filter sa kasalukuyang user o team, hindi sa ID na ipinapadala ng browser.
• Should: Ang shared na data (proyekto ng team) ay may malinaw na tuntunin kung sino ang kasama sa team, na ipinapatupad sa iisang lugar.

4. Mga secret at API key

Ang API key ay password para sa isang serbisyo. Gumagamit ng mga ito ang Stripe, email at AI provider. Para sa background, tingnan ang ano ang environment variables at secrets.

• Must: Nakaimbak ang mga key sa environment variable o secret ng project, hindi kailanman nakasulat sa code.
• Must: Ang mga key na puwedeng gumastos ng pera o magbasa ng pribadong data ay sa server lang ginagamit. Test: buksan ang live site, tingnan ang page source at ang JavaScript file sa devtools, at hanapin ang simula ng key mo (halimbawa sk_). Hindi dapat ito lumitaw.
• Must: Hindi kailanman na-paste ang mga key sa chat, public repository o screenshot. Kung nangyari, i-rotate ito sa provider (gumawa ng bago, at burahin ang luma).
• Should: Gumamit ng restricted o scoped na key kung inaalok ng provider. Halimbawa, inirerekomenda ng Stripe ang restricted key na may permission lang na kailangan ng integration mo.
• Should: Hiwalay ang test at live na key, at gamitin lang ng live na app ang live key kapag handa ka na.

May mga key na dinisenyong publiko, gaya ng publishable key ng Stripe (pk_…) o maps key na nakatali sa domain mo. Ang tuntunin ay tungkol sa mga key na may kapangyarihan, hindi sa bawat string na mukhang key.

5. Input validation

Ang anumang ipinapadala ng user (form field, file upload, URL parameter) ay puwedeng maging kahit ano, hindi lang ang pinapayagan ng form mo.

• Must: Nangyayari ang validation sa server, hindi lang sa browser. Para sa kaginhawaan lang ang mga check sa browser; kayang laktawan ng sinuman ang mga iyon.
• Must: Gumagamit ang mga database query ng parameter, hindi ng text na idinikit mula sa input ng user (pinipigilan nito ang SQL injection). Itanong sa AI para makumpirma.
• Must: Ang text na inilalagay ng user ay ipinapakita bilang text, hindi tinatakbo bilang HTML. Test: ilagay ang <b>hello</b> bilang pangalan mo. Dapat makita mo ang mga tag, hindi bold na text.
• Should: Sinusuri ng file upload ang uri at laki, at hindi inihahain ang mga naka-upload na file mula sa pangunahing domain ng app bilang tumatakbong pahina.
• Should: Simple ang mga error na ipinapakita sa user ("Something went wrong"); ang detalyadong error ay napupunta lang sa server logs.
• Should: Bago kumilos, sinusuri ng mga webhook mula sa mga serbisyo gaya ng Stripe ang signature ng provider. Tingnan ang ano ang webhook.

Magdagdag ng server-side validation sa bawat form at API endpoint: mga kinakailangang field, haba, format at pinapayagang value. Tanggihan ang iba pa na may malinaw na mensahe. Huwag ipakita sa user ang detalye ng internal error.

6. Rate limit at pang-aabuso

Naglilimita ang rate limit kung ilang request ang puwedeng gawin ng isang tao sa isang panahon. Kapag wala ito, puwedeng manghula ng password ang sinuman buong araw, bahain ang sign-up form mo, o paubusin ang bayarin mo sa bayad na API.

• Must: Limitado sa rate ang log-in, sign-up at password reset kada IP address at kada account.
• Must: Ang anumang nagkakagastos sa bawat tawag, gaya ng AI model request, SMS at email, ay may limit kada user at nangangailangan ng log-in.
• Should: Ang mga public form (contact, waitlist) ay may proteksyon laban sa spam: rate limit, nakatagong honeypot field, o CAPTCHA.
• Should: Magtakda ng spending cap o alert sa mga bayad na provider, para hindi makalikha ng walang limitong bill ang bug o ang umaatake.

7. Mga dependency

Ginagawa ang mga app mula sa open-source na package, at minsan may kilalang kahinaan ang mga package.

• Should: Tanungin ang AI na tingnan ang mga kilalang kahinaan (para sa JavaScript project, npm audit o katumbas sa package manager mo) at i-update ang mga apektado.
• Should: Alisin ang mga package na hindi na ginagamit ng app.
• Should: Mag-ingat sa mga package na kakaunti ang gumagamit o may pangalang mukhang typo ng sikat na package.
• Later: Suriin ulit kada isa o dalawang buwan, o i-on ang automated alert kung nasa GitHub ang code mo.

8. Backup at pagbawi

Kasama sa seguridad ang kakayahang makabawi sa mga pagkakamali, sa iyo man, sa AI, o sa umaatake.

• Must: Alamin kung saan nakatira ang data mo at kung may backup ito. Huwag ipagpalagay; tingnan sa dokumentasyon ng host mo.
• Should: Panatilihin ang sarili mong pana-panahong export ng mahahalagang data (halimbawa, feature na CSV export o database dump), na nakaimbak sa ibang lugar.
• Should: Panatilihin ang code mo sa version control, para maibalik ang anumang bersyon.
• Should: Ang mga mapanirang aksyon (burahin ang account, burahin ang project) ay humihingi ng kumpirmasyon, at isaalang-alang ang "soft delete" na puwedeng bawiin sa loob ng ilang panahon.
• Later: Subukan talaga ang pagbalik ng data kahit minsan. Ang backup na hindi pa nasusubukang ibalik ay pag-asa, hindi plano.

9. Bago ilunsad

• Must: Gumagamit ang live site ng HTTPS sa lahat ng bahagi.
• Must: Tanggalin ang sample data, test account at debug page mula sa development.
• Should: Nakasaad sa privacy policy kung anong data ang kinokolekta mo at bakit. Kadalasang kinakailangan ito sa maraming lugar kapag nangongolekta ng personal na data. Huwag mag-claim ng certification (SOC 2, HIPAA) na wala ka.
• Should: May paraan para makontak tungkol sa mga isyu sa seguridad, at alam mo kung paano mabilis mag-rotate ng bawat key.

Para sa mas malawak na pre-launch na pagsusuri na lampas sa seguridad, tingnan ang paano dalhin ang AI prototype sa production.

Kailan kumuha ng propesyonal na review

Hinuhuli ng checklist ang mga karaniwang pagkakamali; hindi nito pinapalitan ang eksperto. Isaalang-alang ang pagbabayad para sa review kung direkta kang nagpoproseso ng card number sa halip na sa hosted checkout, nag-iimbak ka ng health, pinansyal o datos ng bata, nagbebenta ka sa mga kumpanyang humihingi ng security questionnaire, o malulubhang maaapektuhan ka ng leak. Nakakatulong nang malaki sa review na ma-export ang code mo.

Seguridad kapag nagtatayo sa Mythex

Wala sa Mythex ang security-scan panel, kaya ang checklist sa itaas ang prosesong susundin. May ilang bagay na nakakatulong:

• Project secrets. Itabi ang mga key sa project settings → Secrets, o sa pamamagitan ng secrets card na ipinapakita ng agent sa chat, para hindi mapunta sa code o mensahe mo. Pagkatapos baguhin ang secret ng live app, mag-publish ulit.
• Plan at Ask mode. Hilingin sa agent na suriin ang mga permission nang hindi nag-e-edit: "Sa Ask mode, ilista ang bawat API route at kung anong permission check ang ginagawa nito."
• /test ay pinapa-click-through ng agent ang preview mo bilang user, kapaki-pakinabang para sa dalawang-account na test sa seksyon 2.
• Checkpoint ay nagpapahintulot na i-rollback ang pagbabagong nagpasira ng isang bagay.

Tingnan ang Security para sa mga app na ginawa mo at Environment variables at secrets sa docs. Kung susunod mong idadagdag ang user account, basahin ang paano magdagdag ng log-in sa app mo.

Mga tanong