सुरक्षित कोडिंग: सुरक्षित कोड लिखने के लिए डेवलपर गाइड

एक खतरनाक विचार हमारे उद्योग में घुस गया है: कि सुरक्षा किसी और की समस्या है। कि यह ऑपरेशन टीम, सुरक्षा इंजीनियरों, समर्पित पेनिट्रेशन टेस्टर्स का काम है जो तिमाही में एक बार आकर एप्लिकेशन को परखते हैं। यह विचार गलत है, और यह अधिकांश उल्लंघनों के लिए ज़िम्मेदार है जिनके बारे में आप किसी भी मंगलवार को पढ़ते हैं।

वास्तविकता यह है कि सुरक्षा एडिटर में तय होती है, सुरक्षा समीक्षा में नहीं। आपका हर निर्णय — आप SQL क्वेरी कैसे बनाते हैं, आप उपयोगकर्ता इनपुट कैसे संभालते हैं, आप सत्र टोकन कैसे संग्रहीत करते हैं — या तो एक दरवाज़ा खोलता है या उसे बंद करता है। हमलावर को एक खुले दरवाज़े की आवश्यकता है। आपको हर एक को बंद करना होगा।

यह लेख आवश्यक सुरक्षित कोडिंग प्रथाओं को कवर करता है जो हर डेवलपर को जाननी चाहिए। यह 2026 के लिए OWASP टॉप 10 पर आधारित है, जिसमें कुछ महत्वपूर्ण बदलाव हुए हैं, और उन कमजोरियों को कवर करता है जो दिन-प्रतिदिन वास्तविक कोडबेस में दिखाई देती हैं: इंजेक्शन, XSS, CSRF, प्रमाणीकरण विफलताएँ, डिपेंडेंसी जोखिम और सीक्रेट एक्सपोज़र।

2026 में OWASP टॉप 10: क्या बदला और क्यों

OWASP टॉप 10 हमारे उद्योग में सबसे महत्वपूर्ण वेब एप्लिकेशन सुरक्षा जोखिमों की सर्वसम्मति सूची के सबसे करीब है। 2026 संस्करण ने कई उल्लेखनीय परिवर्तन पेश किए जो दर्शाते हैं कि खतरे का परिदृश्य कैसे विकसित हुआ है। इन बदलावों को समझने से आपको अपने प्रयासों को उन जोखिमों पर केंद्रित करने में मदद मिलती है जो वास्तव में मायने रखते हैं।

2026 में सबसे बड़ा बदलाव AI-जनरेटेड कोड को एक अलग जोखिम श्रेणी के रूप में शामिल करना है। पहली बार, OWASP स्पष्ट रूप से मानता है कि बड़े भाषा मॉडल द्वारा उत्पादित कोड अद्वितीय सुरक्षा चुनौतियाँ पेश करता है। ये मॉडल सार्वजनिक कोड के विशाल संग्रह पर प्रशिक्षित होते हैं, जिसमें अच्छी तरह से बनाए गए लाइब्रेरी से लेकर Stack Overflow स्निपेट तक सब कुछ शामिल है। AI वही पैटर्न दोहराता है जो उसने देखे हैं, जिनमें कमजोर पैटर्न भी शामिल हैं।

एक और महत्वपूर्ण परिवर्तन इंजेक्शन श्रेणियों का समेकन है। पिछले संस्करण SQL इंजेक्शन, NoSQL इंजेक्शन, OS कमांड इंजेक्शन और LDAP इंजेक्शन को अलग-अलग प्रविष्टियों के रूप में मानते थे। 2026 संस्करण उन्हें एक ही श्रेणी 'इंजेक्शन' के अंतर्गत समूहित करता है, जो वास्तविकता को दर्शाता है कि अंतर्निहित पैटर्न — अविश्वसनीय डेटा को एक इंटरप्रेटर में संयोजित करना — लक्ष्य की परवाह किए बिना समान है।

क्रिप्टोग्राफ़िक विफलताओं को सूची में ऊपर स्थान दिया गया है, जो AI-संचालित क्रिप्टैनालिसिस की बढ़ती व्यापकता और क्वांटम-आसन्न माइग्रेशन योजना की निरंतर आपदा से प्रेरित है। यदि आप आधुनिक प्रमाणित एन्क्रिप्शन का उपयोग नहीं कर रहे हैं और आपने दीर्घकालिक डेटा के लिए पोस्ट-क्वांटम माइग्रेशन के बारे में सोचना भी शुरू नहीं किया है, तो आप भविष्य का कर्ज जमा कर रहे हैं।

2026 की सूची सुरक्षा गलत कॉन्फ़िगरेशन और सॉफ़्टवेयर अखंडता विफलताओं को 'कॉन्फ़िगरेशन और समझौता' नामक एक व्यापक श्रेणी में भी विलीन करती है, यह मानते हुए कि कई अखंडता विफलताएँ मौलिक रूप से कॉन्फ़िगरेशन निर्णय हैं।

सुरक्षा कोई उत्पाद या सुविधा नहीं है। यह इंजीनियरिंग संस्कृति का एक गुण है। यदि आपकी टीम डिज़ाइन चरण के दौरान सुरक्षा की परवाह नहीं करती, तो अंत में कोई भी स्कैनिंग इसे ठीक नहीं करेगी।

इंजेक्शन हमले: वही पुरानी कहानी, फिर भी सबसे बड़ी समस्या

इंजेक्शन हमले एक कारण से OWASP सूची में शीर्ष पर बने हुए हैं: वे निष्पादित करने में सरल, प्रभाव में विनाशकारी और प्रोडक्शन कोड में आश्चर्यजनक रूप से सामान्य हैं। मूल समस्या यह है कि एक प्रोग्राम उपयोगकर्ता-नियंत्रित इनपुट वाली स्ट्रिंग को संयोजित करके एक कमांड या क्वेरी बनाता है। हमलावर इच्छित संदर्भ से बाहर निकलने और अपने स्वयं के निर्देश इंजेक्ट करने के लिए उस इनपुट को तैयार करता है।

SQL इंजेक्शन क्लासिक उदाहरण है, और यह अभी भी काम करता है। जिन डेवलपर्स ने दस साल पहले विश्वविद्यालय में SQL इंजेक्शन के बारे में सीखा था, वे अभी भी समय सीमा के दबाव में कमजोर कोड लिखते हैं। समाधान सर्वविदित है: पैरामीटराइज़्ड क्वेरी, प्रिपेयर्ड स्टेटमेंट, या एक ORM जो एस्केपिंग को सही ढंग से संभालता है।

// Vulnerable: string concatenation with user input
const query = `SELECT * FROM users WHERE email = '${req.query.email}'`;
db.execute(query);

// Fixed: parameterized query
const query = 'SELECT * FROM users WHERE email = ?';
db.execute(query, [req.query.email]);

कमजोर पैटर्न किसी भी अनुभवी डेवलपर को स्पष्ट रूप से गलत दिखना चाहिए, फिर भी यह हर हफ्ते कोड समीक्षाओं में दिखाई देता है। कारण हमेशा एक जैसे होते हैं: समय का दबाव, एक क्वेरी जो पैरामीटराइज़ेशन के लिए बहुत सरल लग रही थी, या एक ORM जो विशिष्ट डेटाबेस ड्राइवर के लिए उपलब्ध नहीं था। इनमें से कोई भी कारण किसी घटना के पोस्ट-मॉर्टम में जीवित नहीं रहता।

यही सिद्धांत NoSQL डेटाबेस पर भी लागू होता है। MongoDB, उदाहरण के लिए, इंजेक्शन के लिए कमजोर है जब उपयोगकर्ता इनपुट सीधे क्वेरी ऑब्जेक्ट में पास किया जाता है। एक हमलावर पासवर्ड मान के रूप में { "$ne": "" } पास करके प्रमाणीकरण को पूरी तरह से बायपास कर सकता है यदि क्वेरी कच्चे इनपुट से बनाई गई है।

OS कमांड इंजेक्शन एक और प्रकार है जो मरने से इनकार करता है। exec, spawn या child_process को उपयोगकर्ता-नियंत्रित इनपुट के साथ कॉल करना विनाशकारी है। यदि आपको कोई बाहरी कमांड चलाने की आवश्यकता है, तो अनुमत मानों की सख्त अनुमति सूची के विरुद्ध इनपुट को मान्य करें। उपयोगकर्ता इनपुट से कमांड स्ट्रिंग कभी न बनाएँ।

क्रॉस-साइट स्क्रिप्टिंग और SPA चुनौती

क्रॉस-साइट स्क्रिप्टिंग (XSS) एक इंजेक्शन हमला है जहाँ लक्ष्य डेटाबेस के बजाय ब्राउज़र का DOM है। एक हमलावर एक वेब पेज में दुर्भावनापूर्ण JavaScript इंजेक्ट करता है, और वह स्क्रिप्ट पीड़ित के सत्र के संदर्भ में निष्पादित होती है, जिससे उसे कुकीज़, localStorage, सत्र डेटा तक पहुँच मिलती है।

React, Vue और Svelte के साथ बनाए गए सिंगल-पेज एप्लिकेशन के उदय ने XSS परिदृश्य को काफी बदल दिया है। आधुनिक फ्रेमवर्क टेम्पलेट एक्सप्रेशन में मानों को स्वचालित रूप से एस्केप करते हैं, जो सबसे सामान्य XSS वेक्टर को समाप्त करता है — लेकिन डेवलपर अभी भी इन सुरक्षाओं को बायपास कर सकते हैं। सबसे आम बायपास React में dangerouslySetInnerHTML, Vue में v-html, या Svelte में @html है।

// Vulnerable: rendering unsanitized HTML from user input
function Comment({ body }) {
  return <div dangerouslySetInnerHTML={{ __html: body }} />;
}

// Fixed: sanitize before rendering
import DOMPurify from 'dompurify';

function Comment({ body }) {
  const clean = DOMPurify.sanitize(body);
  return <div dangerouslySetInnerHTML={{ __html: clean }} />;
}

सर्वर-साइड रेंडरिंग XSS सुरक्षा में एक और आयाम जोड़ता है। यदि आपका एप्लिकेशन सर्वर पर उपयोगकर्ता-निर्मित सामग्री रेंडर करता है और क्लाइंट को HTML भेजता है, तो उस सामग्री को सर्वर साइड पर एस्केप किया जाना चाहिए। कई टेम्पलेट इंजन डिफ़ॉल्ट रूप से एस्केप्ड आउटपुट देते हैं, लेकिन डेवलपर अनएस्केप्ड आउटपुट में ऑप्ट इन कर सकते हैं। अपने टेम्पलेट्स में अनएस्केप्ड आउटपुट की हर घटना की समीक्षा करें।

तीसरा XSS वेक्टर जिसे डेवलपर अक्सर अनदेखा करते हैं, वह है डेटा विशेषताओं और URL के माध्यम से अप्रत्यक्ष इंजेक्शन। यदि आप उपयोगकर्ता इनपुट का उपयोग करके DOM एलिमेंट पर डेटा विशेषता सेट करते हैं, तो आप कमजोर हो सकते हैं यदि इनपुट में ऐसे वर्ण हैं जो विशेषता संदर्भ को तोड़ते हैं। इसी तरह, यदि आप उपयोगकर्ता इनपुट से URL बनाते हैं, तो एक हमलावर javascript: URL का उपयोग कर सकता है।

क्रॉस-साइट रिक्वेस्ट फोर्जरी और प्रमाणीकरण सख्तीकरण

क्रॉस-साइट रिक्वेस्ट फोर्जरी (CSRF) एक वेब एप्लिकेशन के प्रमाणित उपयोगकर्ता के ब्राउज़र में विश्वास का शोषण करता है। एक हमलावर आपके एप्लिकेशन के लिए एक अनुरोध तैयार करता है और एक प्रमाणित उपयोगकर्ता को इसे निष्पादित करने के लिए प्रेरित करता है — एक दुर्भावनापूर्ण पेज पर जाकर, एक लिंक पर क्लिक करके, या एक इमेज लोड करके। यदि आपका एप्लिकेशन प्रमाणीकरण के लिए केवल सत्र कुकीज़ पर निर्भर करता है, तो CSRF हमले संभव हैं।

मानक बचाव एक CSRF टोकन है: हर फॉर्म में एम्बेडेड एक अद्वितीय, अनुमान लगाने योग्य मान और सर्वर पर मान्य। जब कोई उपयोगकर्ता फॉर्म सबमिट करता है, तो सर्वर जाँचता है कि CSRF टोकन सत्र में संग्रहीत टोकन से मेल खाता है। एक हमलावर का जाली अनुरोध इस टोकन को शामिल नहीं कर सकता क्योंकि Same-Origin Policy हमलावर के पेज को आपके सर्वर के प्रतिक्रिया पढ़ने से रोकती है।

// Vulnerable: no CSRF protection
app.post('/api/transfer', (req, res) => {
  const { toAccount, amount } = req.body;
  transferFunds(req.session.userId, toAccount, amount);
  res.json({ ok: true });
});

// Fixed: validate CSRF token
app.post('/api/transfer', (req, res) => {
  const token = req.headers['x-csrf-token'];
  if (!validateCsrfToken(req.session, token)) {
    return res.status(403).json({ error: 'Invalid CSRF token' });
  }
  const { toAccount, amount } = req.body;
  transferFunds(req.session.userId, toAccount, amount);
  res.json({ ok: true });
});

आधुनिक फ्रेमवर्क में CSRF सुरक्षा आउट ऑफ़ द बॉक्स शामिल है। Express.js मिडलवेयर, Django का बिल्ट-इन CSRF मिडलवेयर, और Rails का प्रमाणीकरण टोकन तंत्र सभी एक ही पैटर्न लागू करते हैं। डेवलपर जो गलती करते हैं वह उन API एंडपॉइंट के लिए CSRF सुरक्षा को अक्षम करना है जो HTML फॉर्म की सेवा नहीं करते, यह भूल जाते हैं कि उन एंडपॉइंट को अभी भी क्रॉस-ओरिजिन अनुरोधों द्वारा लक्षित किया जा सकता है।

प्रमाणीकरण सख्तीकरण CSRF से आगे जाता है। हर सत्र की एक समाप्ति होनी चाहिए। हर पासवर्ड रीसेट टोकन एकल-उपयोग और समय-सीमित होना चाहिए। हर लॉगिन एंडपॉइंट को ब्रूट फोर्स हमलों को रोकने के लिए रेट लिमिटिंग लागू करनी चाहिए। मल्टी-फ़ैक्टर प्रमाणीकरण सभी उपयोगकर्ताओं के लिए उपलब्ध और प्रोत्साहित होना चाहिए, और प्रशासनिक खातों के लिए आवश्यक होना चाहिए।

रेट लिमिटिंग सबसे लागत-प्रभावी सुरक्षा उपायों में से एक है जिसे आप लागू कर सकते हैं। इसमें न्यूनतम कोड की आवश्यकता होती है, कोई चल रहा रखरखाव बोझ नहीं है, और हमलों की एक पूरी श्रेणी को रोकता है। एप्लिकेशन स्तर (प्रति उपयोगकर्ता), नेटवर्क स्तर (प्रति IP), और एंडपॉइंट स्तर (प्रति संवेदनशील ऑपरेशन) पर रेट लिमिटिंग लागू करें। लॉगिन एंडपॉइंट के लिए एक उचित प्रारंभिक बिंदु प्रति मिनट पाँच प्रयास प्रति उपयोगकर्ता है।

डिपेंडेंसी प्रबंधन और सीक्रेट हैंडलिंग

आधुनिक एप्लिकेशन ओपन-सोर्स डिपेंडेंसी की नींव पर बनाए गए हैं। एक सामान्य Node.js प्रोजेक्ट में हजारों ट्रांज़िटिव डिपेंडेंसी होती हैं। हर एक एक संभावित हमला वेक्टर है। 2024 की event-stream घटना, जहाँ एक दुर्भावनापूर्ण अभिनेता ने मेंटेनर एक्सेस प्राप्त किया और एक लोकप्रिय npm पैकेज में क्रिप्टोकरेंसी-चुराने वाला कोड इंजेक्ट किया, कोई अपवाद नहीं है।

• अखंडता सत्यापन के साथ पैकेज मैनेजर का उपयोग करें। npm shrinkwrap और yarn.lock सुनिश्चित करते हैं कि हर इंस्टॉल एक ही डिपेंडेंसी ट्री का उपयोग करता है। अपनी डिपेंडेंसी को पिन करें, रेंज ऑपरेटर का उपयोग न करें।
• अपने CI पाइपलाइन के भाग के रूप में डिपेंडेंसी भेद्यता स्कैनिंग चलाएँ। npm audit, Snyk, Dependabot और Trivy जैसे उपकरण स्वचालित रूप से आपके डिपेंडेंसी ग्राफ में ज्ञात कमजोरियों का पता लगाते हैं।
• अप्रयुक्त डिपेंडेंसी हटाएँ। हर पैकेज जिसका आप सक्रिय रूप से उपयोग नहीं कर रहे हैं, बिना लाभ के एक दायित्व है। अपने package.json में मृत वजन की पहचान करने के लिए depcheck जैसे उपकरणों का उपयोग करें।
• प्रत्येक डिपेंडेंसी द्वारा अनुरोधित अनुमतियों का ऑडिट करें। एक पैकेज जो पर्यावरण चर पढ़ता है, फ़ाइल सिस्टम तक पहुँचता है, और नेटवर्क अनुरोध करता है, एक जोखिम है। हर अनुमति को उचित ठहराएँ।
• समीक्षा प्रक्रिया के साथ स्वचालित डिपेंडेंसी अपडेट सेट करें। Dependabot या Renovate नए संस्करण उपलब्ध होने पर पुल रिक्वेस्ट खोलेंगे। चेंजलॉग की समीक्षा करें, ब्रेकिंग चेंज की जाँच करें, और तुरंत मर्ज करें — विशेष रूप से सुरक्षा पैच के लिए।

सीक्रेट प्रबंधन इस समीकरण का दूसरा भाग है। स्रोत कोड में हार्डकोडेड API कुंजियाँ, डेटाबेस पासवर्ड और एन्क्रिप्शन सीक्रेट पेनिट्रेशन टेस्ट में सबसे आम निष्कर्षों में से एक हैं। वे पूरी तरह से रोके जाने योग्य भी हैं।

// Vulnerable: hardcoded secrets in source code
const DB_PASSWORD = 'sup3r-s3cr3t-passw0rd!';
const API_KEY = 'sk-live-abc123def456';

// Fixed: use environment variables with validation
function getEnv(name: string): string {
  const value = process.env[name];
  if (!value) {
    throw new Error(`Missing required environment variable: ${name}`);
  }
  return value;
}

const dbPassword = getEnv('DB_PASSWORD');
const apiKey = getEnv('API_KEY');

// Also: use .env files locally, never commit them
// Add .env to .gitignore from day one

यदि आपने कभी किसी git रिपॉज़िटरी में कोई सीक्रेट कमिट किया है, तो वह समझौता हो चुका है। नवीनतम कमिट से सीक्रेट हटाना पर्याप्त नहीं है — यह अभी भी git इतिहास में है। रिपॉज़िटरी तक पहुँच रखने वाला कोई भी व्यक्ति इसे पा सकता है। एकमात्र सुरक्षित कार्रवाई तुरंत सीक्रेट को रोटेट करना है।

प्रोडक्शन में एक समर्पित सीक्रेट मैनेजर का उपयोग करें। HashiCorp Vault, AWS Secrets Manager, Azure Key Vault या Google Secret Manager सुरक्षित भंडारण, एक्सेस ऑडिटिंग, स्वचालित रोटेशन और बारीक एक्सेस नियंत्रण प्रदान करते हैं। पर्यावरण चर स्थानीय विकास के लिए स्वीकार्य हैं, लेकिन प्रोडक्शन सीक्रेट को एप्लिकेशन स्टार्टअप पर एक सीक्रेट स्टोर से लाया जाना चाहिए।

टूलिंग: SAST, DAST और सुरक्षा हेडर

सुरक्षित कोडिंग केवल इस बारे में नहीं है कि आप क्या लिखते हैं — यह इस बारे में भी है कि आप क्या जाँचते हैं और कैसे डिप्लॉय करते हैं। सबसे अनुशासित विकास टीमें स्थैतिक विश्लेषण, गतिशील विश्लेषण और इंफ़्रास्ट्रक्चर सख्तीकरण को जोड़ती हैं।

स्टैटिक एप्लिकेशन सिक्योरिटी टेस्टिंग (SAST) उपकरण बिना निष्पादित किए स्रोत कोड का विश्लेषण करते हैं। वे उन पैटर्न की तलाश करते हैं जो कमजोरियों का संकेत देते हैं: SQL इंजेक्शन, XSS, असुरक्षित डिसीरियलाइज़ेशन, हार्डकोडेड सीक्रेट और अधिक। SAST उपकरण विकास वर्कफ़्लो में एकीकृत होते हैं और कोड लिखे जाने के समय फ़ीडबैक प्रदान करते हैं।

डायनेमिक एप्लिकेशन सिक्योरिटी टेस्टिंग (DAST) उपकरण तैयार अनुरोध भेजकर और प्रतिक्रियाओं का अवलोकन करके चल रहे एप्लिकेशन का विश्लेषण करते हैं। वे उन कमजोरियों का पता लगाते हैं जो SAST उपकरण नहीं पा सकते, जैसे CSRF, प्रमाणीकरण बायपास और कॉन्फ़िगरेशन समस्याएँ। DAST सबसे प्रभावी होता है जब CI/CD पाइपलाइन में एकीकृत किया जाता है।

तीसरी परत सुरक्षा हेडर के माध्यम से इंफ़्रास्ट्रक्चर सख्तीकरण है। HTTP प्रतिक्रिया हेडर ब्राउज़र को बताते हैं कि आपके एप्लिकेशन को रेंडर करते समय कैसे व्यवहार करना है। उन्हें सही ढंग से सेट करना बिना किसी रनटाइम लागत के क्लाइंट-साइड हमलों की एक पूरी श्रेणी को रोकता है।

• Content-Security-Policy: ब्राउज़र को संसाधन लोड करने के स्रोतों को प्रतिबंधित करता है। भले ही हमलावर स्क्रिप्ट टैग इंजेक्ट करने में सफल हो, XSS को रोकता है।
• Strict-Transport-Security: ब्राउज़र को आपके डोमेन के सभी कनेक्शनों के लिए HTTPS का उपयोग करने के लिए मजबूर करता है। SSL स्ट्रिपिंग हमलों को रोकता है।
• X-Frame-Options: आपके एप्लिकेशन को अन्य डोमेन पर iframes में एम्बेड होने से रोकता है। क्लिकजैकिंग हमलों को कम करता है।
• X-Content-Type-Options: ब्राउज़र को प्रतिक्रिया प्रकार का MIME-स्निफ़िंग करने से रोकता है। गलत लेबल वाली सामग्री प्रकारों के माध्यम से स्क्रिप्ट इंजेक्शन के जोखिम को कम करता है।
• Set-Cookie Secure, HttpOnly और SameSite फ़्लैग के साथ: सुनिश्चित करता है कि कुकीज़ केवल HTTPS पर भेजी जाएँ, JavaScript के लिए दुर्गम हों, और क्रॉस-ओरिजिन न भेजी जाएँ। SameSite=Lax या Strict सबसे प्रभावी CSRF बचाव है।

सुरक्षा हेडर कॉन्फ़िगर करने में आसान और तुरंत प्रभावी हैं। securityheaders.com जैसे उपकरण का उपयोग करके अपने एप्लिकेशन को स्कैन करें और गायब हेडर की पहचान करें। अधिकांश एप्लिकेशन फ्रेमवर्क मिडलवेयर के माध्यम से इन हेडर को सेट करने का समर्थन करते हैं।

डेवलपमेंट समय पर SAST, डिप्लॉयमेंट समय पर DAST और इंफ़्रास्ट्रक्चर परत पर सुरक्षा हेडर का संयोजन ओवरलैपिंग कवरेज बनाता है। यदि एक परत किसी कमजोरी को चूक जाती है, तो दूसरी परत इसे पकड़ सकती है। यह सॉफ़्टवेयर डेवलपमेंट जीवनचक्र पर लागू डिफेंस इन डेप्थ है।

सुरक्षा संस्कृति का निर्माण

कोई भी उपकरण, चेकलिस्ट या फ्रेमवर्क उस विकास टीम की जगह नहीं ले सकता जो वास्तव में सुरक्षा को एक डिज़ाइन बाधा के रूप में आंतरिक करती है। एक टीम जो सुरक्षित कोड लिखती है और एक टीम जो नहीं लिखती, उनके बीच का अंतर उनके स्थैतिक विश्लेषण उपकरण की गुणवत्ता नहीं है — यह उनकी दैनिक वर्कफ़्लो में एम्बेडेड आदतों और मान्यताओं का सेट है।

सबसे महत्वपूर्ण आदत कार्यान्वयन से पहले खतरे का मॉडलिंग है। एक नई सुविधा के लिए कोड की एक भी पंक्ति लिखने से पहले, पूछें: हमलावर क्या करने की कोशिश कर रहा है? यह सुविधा किस सबसे मूल्यवान डेटा को छूती है? यदि हमलावर इनपुट को नियंत्रित करता है तो क्या होता है? इन सवालों का जल्दी उत्तर देने से डिज़ाइन-स्तर की कमजोरियाँ सामने आती हैं जिन्हें कोई कोड समीक्षा नहीं पकड़ेगी।

दूसरी आदत सुरक्षा को प्रथम श्रेणी की चिंता के रूप में सहकर्मी समीक्षा है। कोड समीक्षाएँ जो केवल शैली, शुद्धता और प्रदर्शन पर ध्यान केंद्रित करती हैं, सुरक्षा मुद्दों को याद करती हैं। अपने पुल रिक्वेस्ट टेम्पलेट में एक सुरक्षा चेकलिस्ट आइटम जोड़ें: SQL इंजेक्शन? XSS? CSRF? डिफ़ में सीक्रेट? प्राधिकरण जाँच? रेट लिमिटिंग?

तीसरी आदत घटनाओं से सीखना है। जब कोई सुरक्षा कमजोरी पाई जाती है — चाहे आपके कोडबेस में या किसी और के — इसे एक शिक्षण अवसर के रूप में मानें। एक पोस्ट-मॉर्टम आयोजित करें जो प्रणालीगत कारणों पर केंद्रित हो: कमजोरी क्यों पेश की गई? समीक्षा में इसे क्यों नहीं पकड़ा गया? कौन सा प्रक्रिया परिवर्तन भविष्य में इस श्रेणी की कमजोरी को रोकेगा?

सुरक्षित कोडिंग एक ऐसा कौशल नहीं है जिसे आप एक बार सीखकर समाप्त कर देते हैं। खतरे का परिदृश्य विकसित होता है। उपकरण विकसित होते हैं। आपकी अपनी समझ विकसित होती है। हर डेवलपर को हर तिमाही नए हमले वैक्टर, नई बचाव तकनीक और नए उपकरणों के बारे में सीखने में समय निवेश करना चाहिए। OWASP चीट शीट श्रृंखला पढ़ें। अपने स्वयं के एप्लिकेशन के खिलाफ पेनिट्रेशन टेस्ट चलाएँ।

क्योंकि अंततः यही बात है। सुरक्षा एक अटूट प्रणाली बनाने के बारे में नहीं है। यह एक ऐसी प्रणाली बनाने के बारे में है जो विकल्पों की तुलना में तोड़ने लायक नहीं है। हर कमजोरी जो आप बंद करते हैं, हर सीक्रेट जो आप हार्डकोडिंग बंद करते हैं, हर रेट लिमिट जो आप लागू करते हैं, किसी और को अधिक आकर्षक लक्ष्य बनाता है। कम लटके फल न बनें।