டெவலப்பர்கள் ஸ்பிரிண்ட் காலக்கெடு மற்றும் புதிய அம்சங்களுக்கான (feature requests) கோரிக்கைகளின் அழுத்தத்தில் வாழ்கிறார்கள். செயல்திறன் மேம்பாடு (Performance tuning) மற்றும் UI மெருகேற்றுதல் ஆகியவை அங்கீகாரம் பெறுகின்றன. பாதுகாப்பு என்பது வழக்கமாக பேக்லாக்கில் (backlog) தங்கி, தனது முறைக்காக அமைதியாகக் காத்திருக்கிறது. அந்தத் தாமதம் ஒரு தவறு. தானியங்கி பாட்கள் (Automated bots) இணையத்தை நாழிக்கணக்கில் ஸ்கேன் செய்து, கசிந்திருக்கும் கீய்கள் (leaked keys), இன்ஜெக்ஷன் புள்ளிகள் (injection points) மற்றும் பலவீனமான அங்கீகார முறைகளைத் தேடுகின்றன. தரவு மீறல்கள் (Data breaches) தொழில்நுட்பச் செய்திகளில் ஒரு சாதாரண விஷயமாகிவிட்டன, ஆனால் அதற்குப் பொறுப்பான குழுவிற்கு, அதைச் சரிசெய்வது மிகவும் கடினமானது. நல்ல செய்தி என்னவென்றால், பாதுகாப்பான குறியீட்டை (secure code) எழுத கிரிப்டோகிராஃபியில் (cryptography) PhD தேவையில்லை. உங்கள் அன்றாடப் பணிப்பாய்வில் (workflow) சில வலுவான பழக்கங்களை இணைத்தால் போதுமானது. உங்கள் பயனர்களையும் உங்கள் அமைப்புகளையும் உண்மையாகப் பாதுகாக்கும் ஐந்து நடைமுறைகள் இதோ.
உங்கள் அங்கீகாரத்தைப் பாதுகாக்கவும்
பல குழுக்கள் ஒரு தனிப்பயனாக்கப்பட்ட (custom) லாகின் அமைப்பை உருவாக்கத் தூண்டப்படுகிறார்கள். ஒரு users table, ஒரு password column, ஒரு JWT generator. இது எளிமையானது என்று தோன்றலாம், ஆனால் இப்போது நீங்கள் session management, token rotation, brute-force protection மற்றும் பாதுகாப்பான password resets ஆகியவற்றிற்குப் பொறுப்பேற்க வேண்டியிருக்கும் என்பதை உணரும்போது நிலைமை மாறும். பெரும்பாலான குழுக்கள் இதைத் தொடக்கத்திலிருந்து (from scratch) உருவாக்குவதை நிறுத்த வேண்டும். OAuth 2.0 அல்லது OpenID Connect மூலம் அங்கீகாரத்தை (authentication) ஏற்கனவே நிலைநாட்டப்பட்ட அடையாள வழங்குநர்களிடம் (identity providers) ஒப்படைப்பது, உங்கள் codebase-லிருந்து முழுமையான இடர்களை (risks) நீக்குகிறது. ஆயிரக்கணக்கான பொறியாளர்களால் சோதிக்கப்பட்டு, பரந்த பாதுகாப்பு சமூகத்தால் மதிப்பாய்வு செய்யப்பட்ட நெறிமுறைகளை (protocols) நீங்கள் பெறுகிறீர்கள்.
அப்படியிருந்தாலும், நீங்கள் கடவுச்சொற்களை (passwords) நீங்களே கையாள வேண்டியிருந்தால், அவற்றை மிகுந்த கவனத்துடன் கையாளவும். ஒவ்வொன்றையும் bcrypt அல்லது Argon2 பயன்படுத்தி ஹேஷ் (hash) செய்யவும். இந்த அல்காரிதம்கள் (algorithms) வேண்டுமென்றே மெதுவாக வடிவமைக்கப்பட்டுள்ளன. அந்த மெதுவான வேகம், உங்கள் தரவுத்தளத்தைத் திருடிவிட்டு, ஆஃப்லைனில் கடவுச்சொற்களை உடைக்க முயற்சிக்கும் தாக்குபவர்களைத் தடுக்கும். கடவுச்சொல்லை ஒருபோதும் plain text-ல் வைக்காதீர்கள். லாக்ஸிலோ (logs), கிராஷ் அறிக்கைகளிலோ (crash reports) அல்லது வேறு எதிலுமோ கூட வேண்டாம்.
மல்டி-ஃபேக்டர் அங்கீகாரம் (Multi-factor authentication) இனி விருப்பத்தேர்வு அல்ல. கடவுச்சொற்கள் கசியலாம். ஃபிஷிங் (Phishing) வேலை செய்யலாம். ஒரு TOTP ஆப் அல்லது ஒரு ஹார்டுவேர் கீ (hardware key) எதுவாக இருந்தாலும், இரண்டாவது காரணி கணக்குத் திருட்டு விகிதத்தை (account takeover rates) வியத்தகு முறையில் குறைக்கிறது.
நீங்கள் session tokens அல்லது JWT-களை வழங்கும்போது, அவற்றை HttpOnly மற்றும் Secure cookies-க்குள் சேமிக்கவும். HttpOnly flag, ஜாவாஸ்கிரிப்ட் (JavaScript) குக்கீயைப் படிப்பதைத் தடுக்கிறது, இது பல cross-site scripting தாக்குதல்களைச் செயலிழக்கச் செய்கிறது. Secure flag, பிரவுசர் அதை HTTPS வழியாக மட்டுமே அனுப்புவதை உறுதி செய்கிறது. JWT-களை localStorage-ல் போடாதீர்கள். இது வசதியாகத் தோன்றலாம், ஆனால் உங்கள் தளத்தில் உள்ள எந்தவொரு XSS பாதிப்பும் (vulnerability) ஒரு தாக்குபவருக்கு உங்கள் பயனர்களின் டோக்கன்களை உடனடியாக அணுக வழிவகை செய்யும்.
OWASP Top 10-ஐ உங்கள் அடிப்படைத் தரமாகக் கருதுங்கள்
OWASP Top 10 என்பது ஒரு தத்துவார்த்தத் தேர்வுத் திட்டம் (theoretical exam syllabus) அல்ல. இது இணையச் செயலிகள் (web applications) உண்மையில் எவ்வாறு மீறப்படுகின்றன என்பதற்கான ஒரு பட்டியல். உங்கள் வேகத்தின் மீது உங்களுக்கு நம்பிக்கை இருப்பதால் போக்குவரத்துச் சிக்னல்களைப் புறக்கணிப்பது போன்றது இது.
SQL injection முதன்முதலில் ஆவணப்படுத்தப்பட்ட பல தசாப்தங்களுக்குப் பிறகும் இன்றும் தயாரிப்புத் தரவுத்தளங்களைத் (production databases) துரத்துகிறது. இதற்கான தீர்வு எளிதானது, ஆனால் அதற்கு ஒழுக்கம் தேவை. பயனர் உள்ளீட்டை (user input) ஒருபோதும் query string-உடன் இணைக்காதீர்கள் (concatenate). parameterized queries அல்லது உங்களுக்காக escaping-ஐக் கையாளும் Prisma போன்ற ஒரு ORM-ஐப் பயன்படுத்தவும். தரவுத்தள டிரைவர் (database driver) குறியீட்டையும் தரவையும் தனித்தனியாகப் பிரிக்கிறது, எனவே ஒரு தீய உள்ளீடு (malicious input) உங்கள் query லாஜிக்கை மாற்ற முடியாது.
Cross-site scripting அல்லது XSS, வடிகட்டப்படாத பயனர் உள்ளீடுகளின் மூலம் பெருகுகிறது. உங்கள் செயலி பயனர் சமர்ப்பிக்கும் எதையும் திரையில் காட்டினால் (renders), முதலில் அதைச் சுத்திகரிக்கவும் (sanitize). நவீன கட்டமைப்புகள் (modern frameworks) பெரும்பாலும் இயல்பாகவே வெளியீட்டைத் தடுத்துவிடும் (escape), ஆனால் தனிப்பயன் கூறுகள் (custom components) மற்றும் dangerouslySetInnerHTML போன்ற API-கள் அந்தப் பாதுகாப்புகளைத் தவிர்க்கக்கூடும். எதை நீங்கள் நம்புகிறீர்கள் என்பதில் தெளிவாக இருங்கள்.
Cross-site request forgery ஒரு பிரவுசரைச் செய்யக்கூடாத ஒரு செயலைச் செய்யத் தூண்டுகிறது. உங்கள் படிவங்களில் (forms) இணைக்கப்பட்ட anti-CSRF டோக்கன்கள் மூலம் இதைக் குறைக்கவும், மேலும் உங்கள் குக்கீகளில் SameSite attribute-ஐ அமைக்கவும். SameSite=Lax அல்லது Strict என்பது cross-origin கோரிக்கைகளின் போது குக்கீகளைத் தடுத்து வைக்குமாறு பிரவுசருக்குக் கூறுகிறது, இது பெரும்பாலான CSRF தாக்குதல்களைத் தடுத்து நிறுத்தும்.
குறைந்தபட்ச அதிகாரக் கொள்கையைப் பயன்படுத்துங்கள்
ஒவ்வொரு பயனருக்கும் அட்மின் உரிமைகள் (admin rights) தேவையில்லை. ஒவ்வொரு மைக்ரோ சர்வீஸுக்கும் (microservice) உங்கள் தரவுத்தளத்திற்கு ரூட் அணுகல் (root access) தேவையில்லை. குறைந்தபட்ச அதிகாரக் கொள்கை (principle of least privilege) என்பது ஒரு குறிப்பிட்ட பணிக்குத் தேவையான அணுகலை மட்டும் வழங்குவதாகும், அதற்கு மேல் எதுவும் இல்லை.
உங்கள் பயன்பாட்டுத் தரவுத்தளப் பயனருடன் (application database user) தொடங்குங்கள். உங்கள் பேக்எண்ட் (backend) வரிசைகளை (rows) படிக்கவும் எழுதவும் மட்டுமே தேவைப்பட்டால், அட்டவணைகளை நீக்க (drop tables), ஸ்கீமாக்களை மாற்ற (alter schemas) அல்லது புதிய தரவுத்தளங்களை உருவாக்க அனுமதிப்பதைக் குறைக்கவும். ஒரு தாக்குபவர் உங்கள் செயலியைப் பாதிக்கும்போது, அந்த வரையறுக்கப்பட்ட அனுமதிகள் ஒரு சுவராகச் செயல்படும். அவர்கள் தரவைத் திருடலாம், ஆனால் ஒரே கட்டளையில் உங்கள் உள்கட்டமைப்பை (infrastructure) அழிக்க முடியாது.
இதே சிந்தனையை உங்கள் கிளவுட் சூழலுக்கும் (cloud environment) பயன்படுத்துங்கள். AWS IAM roles, Google Cloud service accounts மற்றும் Azure managed identities ஆகியவை தனிப்பட்ட செயல்களுக்கு மட்டுமே வரையறுக்கப்பட வேண்டும். ஸ்டேடிக் சொத்துக்களை (static assets) மட்டும் வரிசைப்படுத்தும் (deploy) ஒரு CI/CD pipeline-க்கு, விலையுயர்ந்த கம்ப்யூட் கிளஸ்டர்களை (compute clusters) உருவாக்க அனுமதி தேவையில்லை. இவற்றை மறுஆய்வு செய்யுங்கள்