ડેવલપર્સ સ્પ્રીન્ટ ડેડલાઇન્સ અને ફીચર રિક્વેસ્ટના ભાર હેઠળ જીવે છે. પરફોર્મન્સ ટ્યુનિંગ અને UI પોલિશને શાબાશી મળે છે. સિક્યુરિટી સામાન્ય રીતે બેકલોગમાં હોય છે, જે પોતાની વારીની શાંતિથી રાહ જોતી હોય છે. તે રાહ જોવી એ એક ભૂલ છે. ઓટોમેટેડ બોટ્સ આસપાસના ઇન્ટરનેટને ૨૪ કલાક સ્કેન કરે છે, લીક થયેલી કીઝ, ઇન્જેક્શન પોઈન્ટ્સ અને નબળા ઓથેન્ટિકેશન માટે તપાસ કરે છે. ટેક ન્યૂઝમાં ડેટા બ્રીચ સામાન્ય બની ગયા છે, પરંતુ જે ટીમ જવાબદાર છે તેના માટે, સફાઈ કરવી ખૂબ જ મુશ્કેલ હોય છે. સારી વાત એ છે કે સુરક્ષિત કોડ લખવા માટે ક્રિપ્ટોગ્રાફીમાં PhD ની જરૂર નથી. તે તમારા રોજિંદા વર્કફ્લોમાં કેટલીક મજબૂત આદતો વણવાની જરૂર છે. અહીં પાંચ પદ્ધતિઓ છે જે ખરેખર તમારા વપરાશકર્તાઓ અને તમારી સિસ્ટમોનું રક્ષણ કરશે.

તમારી ઓથેન્ટિકેશન સુરક્ષિત કરો

ઘણી ટીમોએ કસ્ટમ લોગિન સિસ્ટમ બનાવવાની લાલચ અનુભવી છે. એક users ટેબલ, એક password કોલમ, એક JWT જનરેટર. જ્યાં સુધી તમને એ ખબર ન પડે ત્યાં સુધી તે સરળ લાગે છે કે હવે તમે સેશન મેનેજમેન્ટ, ટોકન રોટેશન, બ્રુટ-ફોર્સ પ્રોટેક્શન અને સુરક્ષિત પાસવર્ડ રિસેટ માટે પણ જવાબદાર છો. મોટાભાગની ટીમોએ આ શૂન્યથી બનાવવાનું બંધ કરવું જોઈએ. OAuth 2.0 અથવા OpenID Connect દ્વારા સ્થાપિત આઈડેન્ટિટી પ્રોવાઈડર્સને ઓથેન્ટિકેશન સોંપવાથી તમારા કોડબેઝમાંથી જોખમોની આખી શ્રેણી દૂર થઈ જાય છે. તમે એવા પ્રોટોકોલ્સ વાપરો છો જે હજારો એન્જિનિયરો દ્વારા પરીક્ષિત કરવામાં આવ્યા છે અને વ્યાપક સિક્યુરિટી કોમ્યુનિટી દ્વારા રિવ્યુ કરવામાં આવ્યા છે.

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

મલ્ટી-ફેક્ટર ઓથેન્ટિકેશન હવે વૈકલ્પિક નથી. પાસવર્ડ લીક થાય છે. ફિશિંગ કામ કરે છે. બીજું ફેક્ટર, પછી તે TOTP એપ હોય કે હાર્ડવેર કી, એકાઉન્ટ હેક થવાના દરમાં મોટો ઘટાડો કરે છે.

જ્યારે તમે સેશન ટોકન્સ અથવા JWTs ઇશ્યૂ કરો છો, ત્યારે તેમને HttpOnly અને Secure કૂકીઝમાં સ્ટોર કરો. HttpOnly ફ્લેગ JavaScript ને કૂકી વાંચતા અટકાવે છે, જે ઘણા cross-site scripting હુમલાઓને નિષ્ફળ બનાવે છે. Secure ફ્લેગ સુનિશ્ચિત કરે છે કે બ્રાઉઝર તેને ફક્ત HTTPS દ્વારા જ મોકલે. JWTs ને localStorage માં ન મૂકો. તે અનુકૂળ લાગે છે, પરંતુ તમારી સાઇટ પર કોઈપણ XSS નબળાઈ હુમલાખોરને તમારા વપરાશકર્તાઓના ટોકન્સનો તાત્કાલિક એક્સેસ આપી શકે છે.

OWASP Top 10 ને તમારા બેઝલાઇન તરીકે ગણો

OWASP Top 10 એ કોઈ સૈદ્ધાંતિક પરીક્ષાનો અભ્યાસક્રમ નથી. તે વેબ એપ્લિકેશન્સ ખરેખર કઈ રીતે બ્રીચ (breach) થાય છે તેના સૌથી સામાન્ય રસ્તાઓનું કેટલોગ છે. તેને અવગણવું એ તમારા રિફ્લેક્સ પર વિશ્વાસ રાખીને ટ્રાફિક સાઈન અવગણવા જેવું છે.

SQL injection હજુ પણ ડિક્યુમેન્ટેડ થયાના દાયકાઓ પછી પણ પ્રોડક્શન ડેટાબેઝમાં જોખમ ઊભું કરે છે. તેનો ઉકેલ સરળ છે, પરંતુ તે શિસ્તની માંગ કરે છે. ક્યારેય યુઝર ઇનપુટને ક્વેરી સ્ટ્રિંગમાં કોન્કેટેનેટ (concatenate) ન કરો. પેરામીટરાઇઝ્ડ ક્વેરીઝ અથવા Prisma જેવું ORM વાપરો જે તમારા માટે એસ્કેપિંગ હેન્ડલ કરે છે. ડેટાબેઝ ડ્રાઇવર કોડને ડેટાથી અલગ કરે છે, જેથી કોઈ દૂષિત ઇનપુટ તમારી ક્વેરી લોજિકને ફરીથી લખી શકતું નથી.

Cross-site scripting, અથવા XSS, અનફિલ્ટર્ડ યુઝર ઇનપુટ પર ખીલે છે. જો તમારી એપ્લિકેશન યુઝર દ્વારા સબમિટ કરવામાં આવેલી કોઈપણ વસ્તુ રૅન્ડર (render) કરે છે, તો તેને પહેલા સેનિટાઇઝ (sanitize) કરો. આધુનિક ફ્રેમવર્ક ઘણીવાર ડિફોલ્ટ રીતે આઉટપુટને એસ્કેપ કરે છે, પરંતુ કસ્ટમ કમ્પોનન્ટ્સ અને dangerouslySetInnerHTML-સ્ટાઇલ API એવા ગાર્ડરેલ્સને બાયપાસ કરી શકે છે. તમે શેના પર વિશ્વાસ કરો છો તે બાબતે સ્પષ્ટ રહો.

Cross-site request forgery બ્રાઉઝરને એવી ક્રિયા કરવા માટે છેતરે છે જે તેણે ન કરવી જોઈએ. તમારા ફોર્મ્સમાં એમ્બેડેડ એન્ટી-CSRF ટોકન્સ સાથે તેને મિટિગેટ કરો, અને તમારી કૂકીઝ પર SameSite એટ્રિબ્યુટ સેટ કરો. SameSite=Lax અથવા Strict બ્રાઉઝરને ક્રોસ-ઓરિજિન રિક્વેસ્ટ દરમિયાન કૂકીઝ રોકી રાખવા માટે કહે છે, જે મોટાભાગના CSRF ને રોકી દે છે.

Principle of Least Privilege નો અમલ કરો

દરેક યુઝરને એડમિન અધિકારોની જરૂર નથી. દરેક માઇક્રોસર્વિસને તમારા ડેટાબેઝના રૂટ એક્સેસની જરૂર નથી. Principle of least privilege નો અર્થ છે કે ચોક્કસ કાર્ય માટે જરૂરી એક્સેસ આપવો, અને તેનાથી વધુ કંઈ નહીં.

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

તમારા ક્લાઉડ એન્વાયરમેન્ટમાં પણ સમાન વિચારધારા લાગુ કરો. AWS IAM roles, Google Cloud service accounts, અને Azure managed identities ને વ્યક્તિગત ક્રિયાઓ સુધી મર્યાદિત રાખવા જોઈએ. જે CI/CD પાઇપલાઇન ફક્ત સ્ટેટિક એસેટ્સ ડિપ્લોય કરે છે તેને મોંઘા કમ્પ્યુટ ક્લસ્ટર્સ શરૂ કરવાની પરવાનગીની જરૂર નથી. આની સમીક્ષા કરો