AI થી બનેલી એપ્સ માટે સિક્યુરિટી ચેકલિસ્ટ: લૉન્ચ પહેલાં શું તપાસવું

વાસ્તવિક લોકો એપ વાપરે તે પહેલાં, AI થી બનાવેલી એપ માટે સાત બાબતો તપાસો: દરેક પેજ અને API તપાસે છે કે યુઝર કોણ છે અને તે શું કરી શકે; સિક્રેટ કી સર્વર પર રહે છે, ક્યારેય બ્રાઉઝર કે ચેટમાં નહીં; બધા ઇનપુટ સર્વર પર વેલિડેટ થાય છે; દરેક યુઝર ફક્ત પોતાના રેકોર્ડ સુધી પહોંચી શકે છે; લૉગ-ઇન અને ખર્ચાળ endpoints પર રેટ લિમિટ છે; ડિપેન્ડન્સી અપ-ટુ-ડેટ છે; અને કંઈ ખોટું થાય તો તમે ડેટા પાછો મેળવી શકો છો. નીચેની ચેકલિસ્ટ આમાંની દરેક બાબતને એવી ચોક્કસ ચકાસણીઓમાં ફેરવે છે જે તમે કોડ વાંચ્યા વિના ચલાવી શકો.

AI એપ બિલ્ડર્સ સુવિધાઓ કામ કરાવવામાં સારા છે. તેઓ આપમેળે સાવધ નથી હોતા, કારણ કે "સાવધાની" ભાગ્યે જ પ્રોમ્પ્ટમાં હોય છે. નીચેની મોટાભાગની સમસ્યાઓ એવી બાબતોમાંથી આવે છે જે કોઈએ માંગી નથી, તેથી ઉકેલ સામાન્ય રીતે પૂછવાનો છે.

આ ચેકલિસ્ટ કેવી રીતે વાપરવી

ક્રમ પ્રમાણે કામ કરો, અને દરેક વસ્તુ માટે બે કામ કરો: ખાતરી કરવા માટે AI ને પૂછો કે તે સંભાળાયેલી છે, અને તમે જાતે ટેસ્ટ કરો. AI પરવાનગી તપાસ લખી શકે છે; માત્ર ટેસ્ટ જ કહે છે કે તે કામ કરે છે. આઇટમ્સ આ રીતે ચિહ્નિત છે:

• Must — બીજા કોઈ યુઝર પહેલાં આ કરો.
• Should — વાસ્તવિક યુઝર્સ કે વાસ્તવિક ડેટા પહેલાં આ કરો.
• Later — એપ વધે તેમ કરવા જેવું.

જો તમારી પાસે માત્ર એક કલાક હોય, તો દરેક Must કરો.

1. ઑથેન્ટિકેશન: આ કોણ છે?

ઑથેન્ટિકેશન એટલે કોઈ કોણ છે તે ખાતરી કરવી — સામાન્ય રીતે લૉગ-ઇન. મૂળભૂત બાબતો માટે ઑથેન્ટિકેશન શું છે અને વિકલ્પો માટે તમારી એપમાં લૉગ-ઇન કેવી રીતે ઉમેરવું જુઓ.

• Must: ખાનગી ડેટા બતાવતા દરેક પેજ માટે લૉગ-ઇન જરૂરી છે. ટેસ્ટ: લૉગ આઉટ કરો, પછી ખાનગી પેજનું URL સીધું બ્રાઉઝરમાં પેસ્ટ કરો.
• Must: તે પેજની પાછળના દરેક API endpoint માટે પણ લૉગ-ઇન જરૂરી છે — માત્ર પેજ માટે નહીં. ટેસ્ટ: લૉગ આઉટ કરો, બ્રાઉઝરનું network tab ખોલો, અને લૉગ ઇન હતા ત્યારે એપે કરેલી વિનંતી ફરી મોકલો.
• Must: પાસવર્ડ્સ ધીમા પાસવર્ડ-હેશિંગ અલ્ગોરિધમથી હેશ કરીને સંગ્રહિત છે, ક્યારેય સાદા ટેક્સ્ટમાં નહીં. OWASP ની પાસવર્ડ સંગ્રહ માર્ગદર્શિકા પ્રથમ Argon2id ની ભલામણ કરે છે, વિકલ્પ તરીકે scrypt, bcrypt અથવા PBKDF2. પૂછો: "પાસવર્ડ્સ કેવી રીતે સંગ્રહિત થાય છે?"
• Should: પાસવર્ડ રીસેટ લિંક્સની મુદત પૂરી થાય છે અને તે ફક્ત એક વાર કામ કરે છે.
• Should: સેશન કૂકીઝ Secure, HttpOnly અને SameSite ચિહ્નિત છે, અને લૉગ આઉટ કરવાથી સર્વર પર સેશન સમાપ્ત થાય છે.
• Later: ટુ-ફેક્ટર ઑથેન્ટિકેશન ઓફર કરો, અથવા તે ધરાવતા પ્રદાતા દ્વારા સાઇન-ઇન.

યુઝર ડેટા પરત કરતા દરેક API રૂટ અને પેજ તપાસો. દરેકે લૉગ ઇન ન હોય તેવા યુઝર્સની વિનંતીઓ નકારવી જોઈએ, સર્વર પર, માત્ર પેજના કોડમાં નહીં. તપાસેલા રૂટ્સની યાદી આપો.

2. ઓથોરાઇઝેશન: તેમને શું કરવાની મંજૂરી છે?

ઓથોરાઇઝેશન લૉગ-ઇન પછીનું પગલું છે: આ ચોક્કસ યુઝર શું જોઈ અને બદલી શકે તે નક્કી કરવું. AI થી બનેલી એપ્સમાં સૌથી વધુ ગંભીર છિદ્રો અહીં હોય છે, કારણ કે એપ સાચી દેખાય છે — દરેક યુઝરના ડેશબોર્ડમાં માત્ર તેનો પોતાનો ડેટા દેખાય છે — જ્યારે સર્વર સીધી વિનંતી પર કોઈનો પણ ડેટા ખુશીથી આપી દે છે.

• Must: દરેક વાંચન, અપડેટ અને ડિલીટ સર્વર પર તપાસે છે કે રેકોર્ડ વર્તમાન યુઝર (અથવા તેની ટીમ)નો છે.
• Must: તેની ચકાસણી કરો: બે એકાઉન્ટ્સ બનાવો, A અને B. A તરીકે, A નો એક રેકોર્ડ ખોલો અને URL અથવા network વિનંતીમાં ID નોંધો. B તરીકે લૉગ ઇન કરો અને તે જ ID માંગો. B ને ભૂલ મળવી જોઈએ, A નો ડેટા નહીં.
• Must: એડમિન પેજ અને એડમિન API endpoints સર્વર પર યુઝરની ભૂમિકા તપાસે છે. એડમિન લિંક છુપાવવી એ સુરક્ષા નથી.
• Must: વિનંતી સંપાદિત કરીને યુઝર્સ પોતાની ભૂમિકા, ભાવ, બેલેન્સ અથવા માલિક ફીલ્ડ્સ બદલી શકતા નથી. ટેસ્ટ: network tab માં જુઓ કે પ્રોફાઇલ અપડેટ શું મોકલે છે. જો તેમાં role અથવા isAdmin જેવા ફીલ્ડ્સ હોય, તો AI ને ક્લાયન્ટ તરફથી તેમને અવગણવા કહો.
• Should: URL માં IDs અનુમાન કરવા મુશ્કેલ છે (1, 2, 3 ને બદલે રેન્ડમ IDs). આ પરવાનગી તપાસનો વિકલ્પ નથી, પરંતુ એક ખૂટે ત્યારે નુકસાન મર્યાદિત કરે છે.

દરેક endpoint માટે જે રેકોર્ડ વાંચે કે બદલે, સર્વર પર તપાસો કે લૉગ-ઇન યુઝર તેનો માલિક છે કે ઍક્સેસ કરવાની મંજૂરી છે. ન હોય તો 404 પરત કરો. પછી બતાવો કે તમે બે એકાઉન્ટ્સ સાથે આ કેવી રીતે ટેસ્ટ કરશો.

3. ડેટાબેઝમાં રો-લેવલ ઍક્સેસ

"રો-લેવલ ઍક્સેસ" એટલે કોષ્ટકની દરેક રો (એક બુકિંગ, એક ઇન્વૉઇસ) ફક્ત તેની સાથે સંબંધિત યુઝર્સને જ દેખાય. તેને લાગુ કરવાની બે સામાન્ય રીતો છે:

બંને સારી રીતે થઈ શકે. જે મહત્વનું છે:

• Must: જો બ્રાઉઝર સીધું ડેટાબેઝ સાથે વાત કરે (કેટલાક હોસ્ટેડ ડેટાબેઝ ઉત્પાદનો આની મંજૂરી આપે છે), તો દરેક કોષ્ટક માટે row-level નિયમો ચાલુ છે. તેમના વિના, જાહેર કી ધરાવતો કોઈપણ આખું કોષ્ટક વાંચી શકે.
• Must: ક્વેરીઝ વર્તમાન યુઝર અથવા ટીમ દ્વારા ફિલ્ટર થાય છે, બ્રાઉઝર મોકલે તે ID દ્વારા નહીં.
• Should: સહિયારો ડેટા (ટીમના પ્રોજેક્ટ્સ) માટે ટીમમાં કોણ છે તેનો સ્પષ્ટ નિયમ છે, એક જ જગ્યાએ લાગુ.

4. સિક્રેટ્સ અને API કી

API કી એ સેવાનો પાસવર્ડ છે. Stripe, ઇમેઇલ અને AI પ્રદાતાઓ બધા તેનો ઉપયોગ કરે છે. પૃષ્ઠભૂમિ માટે એન્વાયર્નમેન્ટ વેરિએબલ્સ અને સિક્રેટ્સ શું છે જુઓ.

• Must: કી પ્રોજેક્ટના એન્વાયર્નમેન્ટ વેરિએબલ્સ અથવા સિક્રેટ્સમાં સંગ્રહિત છે, ક્યારેય કોડમાં લખેલી નહીં.
• Must: પૈસા ખર્ચી શકે અથવા ખાનગી ડેટા વાંચી શકે તેવી કી ફક્ત સર્વર પર વપરાય છે. ટેસ્ટ: તમારી લાઇવ સાઇટ ખોલો, devtools માં પેજ સોર્સ અને JavaScript ફાઇલો જુઓ, અને તમારી કીની શરૂઆત (દા.ત. sk_) શોધો. તે દેખાવી ન જોઈએ.
• Must: કી ક્યારેય ચેટ, જાહેર રિપોઝિટરી કે સ્ક્રીનશોટમાં પેસ્ટ થઈ ન હોય. જો થઈ હોય, તો પ્રદાતા પાસે તેને રોટેટ કરો (નવી બનાવો, જૂની ડિલીટ કરો).
• Should: પ્રદાતા ઓફર કરે ત્યાં મર્યાદિત અથવા scoped કી વાપરો. દાખલા તરીકે, Stripe તમારા ઇન્ટિગ્રેશનને જરૂરી પરવાનગીઓ ધરાવતી restricted કીની ભલામણ કરે છે.
• Should: ટેસ્ટ અને લાઇવ કી અલગ છે, અને લાઇવ એપ ફક્ત તમે તૈયાર હો ત્યારે જ લાઇવ કી વાપરે છે.

કેટલીક કી જાહેર રહેવા માટે બનાવાયેલ છે — Stripe ની publishable કી (pk_…) અથવા તમારા ડોમેન પર મર્યાદિત નકશા કી. નિયમ એ કી વિશે છે જે શક્તિ આપે છે, દરેક સ્ટ્રિંગ જે કી જેવી દેખાય તે વિશે નહીં.

5. ઇનપુટ વેલિડેશન

યુઝર જે કંઈ મોકલે — ફોર્મ ફીલ્ડ્સ, ફાઇલ અપલોડ, URL પેરામીટર્સ — તે કંઈ પણ હોઈ શકે, માત્ર તમારા ફોર્મ જે મંજૂર કરે તે નહીં.

• Must: વેલિડેશન સર્વર પર થાય છે, માત્ર બ્રાઉઝરમાં નહીં. બ્રાઉઝર તપાસ સગવડ માટે છે; કોઈ પણ તેને છોડી શકે.
• Must: ડેટાબેઝ ક્વેરીઝ parameters વાપરે છે, યુઝર ઇનપુટમાંથી ભેગા કરેલ ટેક્સ્ટ નહીં (આ SQL injection અટકાવે છે). AI ને પુષ્ટિ કરવા કહો.
• Must: યુઝર્સ જે ટેક્સ્ટ દાખલ કરે તે ટેક્સ્ટ તરીકે દેખાય છે, HTML તરીકે ચાલતો નથી. ટેસ્ટ: તમારા નામ તરીકે <b>hello</b> દાખલ કરો. તમને ટૅગ્સ દેખાવા જોઈએ, બોલ્ડ ટેક્સ્ટ નહીં.
• Should: ફાઇલ અપલોડ પ્રકાર અને કદ તપાસે છે, અને અપલોડ કરેલી ફાઇલો તમારા એપના મુખ્ય ડોમેન પરથી ચાલતા પેજ તરીકે પીરસાતી નથી.
• Should: યુઝર્સને બતાવાતી ભૂલો સાદી છે ("કંઈક ખોટું થયું"); વિગતવાર ભૂલો ફક્ત સર્વર લોગમાં જાય છે.
• Should: Stripe જેવી સેવાઓના webhooks કંઈ કરતાં પહેલાં પ્રદાતાની સહી ચકાસે છે. webhook શું છે જુઓ.

દરેક ફોર્મ અને API endpoint પર સર્વર-બાજુ વેલિડેશન ઉમેરો: જરૂરી ફીલ્ડ્સ, લંબાઈ, ફોર્મેટ અને મંજૂર મૂલ્યો. બાકીનું સ્પષ્ટ સંદેશ સાથે નકારો. યુઝર્સને આંતરિક ભૂલની વિગતો ન બતાવો.

6. રેટ લિમિટ્સ અને દુરુપયોગ

રેટ લિમિટ એક સમયગાળામાં કોઈ કેટલી વિનંતીઓ કરી શકે તેની મર્યાદા છે. તેના વિના, કોઈ આખો દિવસ પાસવર્ડ અનુમાન કરી શકે, તમારું સાઇનઅપ ફોર્મ ભરી શકે, અથવા ચૂકવેલ API પર તમારું બિલ વધારી શકે.

• Must: લૉગ-ઇન, સાઇનઅપ અને પાસવર્ડ રીસેટ IP સરનામા અને એકાઉન્ટ દીઠ રેટ-લિમિટેડ છે.
• Must: પ્રતિ કૉલ તમને પૈસા ખર્ચાવતી દરેક વસ્તુ — AI મોડેલ વિનંતીઓ, SMS, ઇમેઇલ — માં પ્રતિ-યુઝર મર્યાદા છે અને લૉગ-ઇન જરૂરી છે.
• Should: જાહેર ફોર્મ્સ (સંપર્ક, વેઇટલિસ્ટ) પાસે સ્પામ સુરક્ષા છે: રેટ લિમિટ, છુપાયેલ honeypot ફીલ્ડ, અથવા CAPTCHA.
• Should: તમારા ચૂકવેલ પ્રદાતાઓ પર ખર્ચ મર્યાદા અથવા ચેતવણીઓ સેટ કરો, જેથી ભૂલ કે હુમલાખોર અમર્યાદિત બિલ ન બનાવી શકે.

7. ડિપેન્ડન્સી

એપ્સ ઓપન-સોર્સ પેકેજોથી બને છે, અને પેકેજોમાં ક્યારેક જાણીતી નબળાઈઓ હોય છે.

• Should: AI ને જાણીતી નબળાઈઓ તપાસવા કહો (JavaScript પ્રોજેક્ટ્સ માટે npm audit અથવા તમારા પેકેજ મેનેજર માટે સમકક્ષ) અને અસરગ્રસ્ત વસ્તુઓ અપડેટ કરો.
• Should: એપ હવે વાપરતી ન હોય તેવા પેકેજો દૂર કરો.
• Should: ખૂબ ઓછા યુઝર્સવાળા પેકેજો અથવા લોકપ્રિય પેકેજોના ટાઇપો જેવા નામો સામે સાવધ રહો.
• Later: દર મહિને અથવા બે મહિને ફરી તપાસો, અથવા તમારો કોડ GitHub પર હોય તો સ્વચાલિત ચેતવણીઓ ચાલુ કરો.

8. બેકઅપ અને પુનઃપ્રાપ્તિ

સિક્યુરિટીમાં ભૂલોમાંથી પાછા આવવાની ક્ષમતા પણ સામેલ છે — તમારી, AI ની, કે હુમલાખોરની.

• Must: જાણો કે તમારો ડેટા ક્યાં રહે છે અને તેનો બેકઅપ છે કે નહીં. ધારી ન લો; તમારા હોસ્ટના દસ્તાવેજીકરણમાં તપાસો.
• Should: મહત્વના ડેટાની તમારી પોતાની સમયાંતરે નિકાસ રાખો (દા.ત. CSV નિકાસ સુવિધા અથવા ડેટાબેઝ ડમ્પ), અલગ જગ્યાએ સંગ્રહિત.
• Should: તમારો કોડ વર્ઝન કંટ્રોલમાં રાખો, જેથી કોઈ પણ વર્ઝન પુનઃસ્થાપિત થઈ શકે.
• Should: વિનાશક ક્રિયાઓ (એકાઉન્ટ ડિલીટ, પ્રોજેક્ટ ડિલીટ) પુષ્ટિ માંગે, અને થોડા સમય માટે પાછી લઈ શકાય તેવી "soft delete" વિચારો.
• Later: એક વાર ખરેખર રિસ્ટોર ટેસ્ટ કરો. જે બેકઅપ ક્યારેય રિસ્ટોર કર્યો નથી તે આશા છે, યોજના નહીં.

9. લૉન્ચ પહેલાં

• Must: લાઇવ સાઇટ દરેક જગ્યાએ HTTPS વાપરે છે.
• Must: ડેવલપમેન્ટમાંથી સેમ્પલ ડેટા, ટેસ્ટ એકાઉન્ટ્સ અને ડિબગ પેજ દૂર કરેલા છે.
• Should: ગોપનીયતા નીતિ કહે છે કે તમે કયો ડેટા અને શા માટે એકઠો કરો છો — વ્યક્તિગત ડેટા એકઠો કરો તો ઘણી જગ્યાએ જરૂરી. જે પ્રમાણપત્રો (SOC 2, HIPAA) તમારી પાસે નથી તેનો દાવો ન કરો.
• Should: સિક્યુરિટી સમસ્યાઓ વિશે તમારો સંપર્ક થઈ શકે તેવો રસ્તો છે, અને દરેક કી ઝડપથી રોટેટ કરતાં તમે જાણો છો.

સિક્યુરિટી ઉપરાંત વ્યાપક લૉન્ચ-પૂર્વ તપાસ માટે, AI પ્રોટોટાઇપને પ્રોડક્શનમાં કેવી રીતે લઈ જવો જુઓ.

ક્યારે વ્યાવસાયિક સમીક્ષા લેવી

ચેકલિસ્ટ સામાન્ય ભૂલો પકડે છે; તે નિષ્ણાતની જગ્યા લેતી નથી. જો તમે હોસ્ટેડ ચેકઆઉટ દ્વારા નહીં પણ જાતે કાર્ડ નંબર પ્રોસેસ કરો, આરોગ્ય, નાણાકીય અથવા બાળકોનો ડેટા સંગ્રહ કરો, સિક્યુરિટી પ્રશ્નાવલી માંગતી કંપનીઓને વેચો, અથવા લીકથી ગંભીર નુકસાન થાય, તો સમીક્ષા માટે ચૂકવણી કરવાનું વિચારો. તમારો કોડ નિકાસ કરી શકાય તેવો હોય તો તે સમીક્ષા ઘણી સરળ બને છે.

Mythex પર બનાવતી વખતે સિક્યુરિટી

Mythex માં સિક્યુરિટી-સ્કેન પેનલ નથી, તેથી ઉપરની ચેકલિસ્ટ અનુસરવાની પ્રક્રિયા છે. કેટલીક મદદરૂપ બાબતો:

• પ્રોજેક્ટ સિક્રેટ્સ. કી પ્રોજેક્ટ સેટિંગ્સ → Secrets હેઠળ સંગ્રહિત કરો, અથવા એજન્ટ ચેટમાં બતાવે તે secrets કાર્ડ દ્વારા, જેથી તે તમારા કોડ અને સંદેશાઓની બહાર રહે. લાઇવ એપ માટે સિક્રેટ બદલ્યા પછી ફરી પબ્લિશ કરો.
• Plan અને Ask મોડ્સ. એજન્ટને સંપાદન વિના પરવાનગીઓ સમીક્ષા કરવા કહો: "Ask mode માં, દરેક API route અને તે કઈ પરવાનગી તપાસ કરે છે તેની યાદી બનાવો."
• /test એજન્ટને તમારા preview માં યુઝર તરીકે ક્લિક કરાવે છે — વિભાગ 2 માં બે-એકાઉન્ટ ટેસ્ટ માટે ઉપયોગી.
• Checkpoints તમને કંઈક તોડનાર ફેરફાર પાછો લેવા દે છે.

દસ્તાવેજોમાં તમે બનાવેલી એપ્સ માટે સિક્યુરિટી અને એન્વાયર્નમેન્ટ વેરિએબલ્સ અને સિક્રેટ્સ જુઓ. જો તમે આગળ યુઝર એકાઉન્ટ્સ ઉમેરી રહ્યા હો, તો તમારી એપમાં લૉગ-ઇન કેવી રીતે ઉમેરવું વાંચો.

પ્રશ્નો