OWASP टॉप 10

यह क्यों ज़रूरी है

Security defects functional tests में कम ही दिखते हैं, क्योंकि ईमानदार user के लिए application ठीक वैसा ही व्यवहार करता है जैसा specified है। वे तब दिखते हैं जब कोई ऐसा request भेजता है जो UI कभी नहीं भेजता: दूसरे user की id, admin path, logout के बाद का token, field के अंदर एक quote। Top 10 weakness की उन categories के नाम बताता है जिन्हें testing data व्यापक दिखाता है, और उन्हें इस हिसाब से तौलता है कि वे कितनी आसानी से exploit होती हैं और कितना नुक़सान करती हैं, इसलिए इसे cover करना आम और गंभीर, दोनों तरह की failures को cover करता है।

यह एक साझा भाषा भी है: developers, security specialists और auditors जानते हैं कि "A01 finding" का क्या मतलब है, इसलिए category का नाम लेने वाली report जल्दी समझी और prioritize की जाती है। और यह तय करता है कि QA टेस्टर क्या cover करता है, इससे पहले कि specialist penetration test उन्हीं categories में और गहराई तक जाए।

Top 10 क्या है, और क्या नहीं है

OWASP हर कुछ साल में नया edition निकालता है; 2025 ने 2021 की जगह ली। दस में से आठ categories applications टेस्ट करने वाली organisations के contributed testing data से आती हैं, और एक ऐसे score से रैंक होती हैं जो यह जोड़ता है कि हर weakness कितनी बार मिलती है (उसका incidence rate) और उसकी exploitability और impact कितना है; practitioners का एक community survey बाक़ी दो जोड़ता है, उन risks के लिए जिन्हें data कम दिखाता है (2025 का A09 पेज कहता है कि वह vote से आई, और A03 survey में सबसे ऊपर रैंक हुई concern थी)। 2025 में तीन बदलाव मायने रखते हैं: A10 Mishandling of Exceptional Conditions नई है; A03 2021 की Vulnerable and Outdated Components से बढ़कर पूरी build, distribution और update chain तक पहुँची; A09 का नाम बदला ताकि सिर्फ़ logging नहीं, alerting पर ज़ोर हो। हर category CWEs की एक सूची से mapped है: Common Weakness Enumeration (CWE) weakness के प्रकारों का MITRE का catalogue है (इसके उलट, एक CVE किसी एक product की एक vulnerability का नाम है), और कई scanners अपनी findings पर CWE ids लगाते हैं।

यह न तो standard है, न पूरी checklist। Application Security Verification Standard (ASVS) security को verifiable requirements में बदलता है, Web Security Testing Guide (WSTG) step-by-step test procedures देता है, और OWASP API Security Top 10 (2023) API-specific risks cover करता है। Top 10 से तय करें कहाँ पहले देखना है; ASVS और WSTG से तय करें कितनी गहराई तक।

• साल हमेशा लिखें: editions के बीच positions बदलती हैं, और A03 का मतलब 2021 में Injection था पर 2025 में Software Supply Chain Failures है।
• सिर्फ़ वही systems टेस्ट करें जो आपके हैं या जिनके लिए लिखित अनुमति है। इस lesson का हर check एक non-destructive observation है, exploit नहीं।

2025 की दस categories और टेस्टर का पहला check

हर category के लिए: वह क्या समेटती है, फिर टेस्टर का पहला check। इस module के बाद के lessons हर area में गहराई तक जाते हैं; यहाँ लक्ष्य है हर category को पहचानना और जानना कि कहाँ देखना है।

• A01:2025 Broken Access Control: अपनी permissions से बाहर काम करना, जैसे id बदलकर दूसरे user का record पढ़ना। Check: ग़लत user और ग़लत role के valid token से request दोहराएँ; 403 या 404 की अपेक्षा रखें।
• A02:2025 Security Misconfiguration: default accounts, ज़रूरत से ज़्यादा features, verbose errors, missing security headers, ढीली permissions। Check: response headers पढ़ें, एक error page trigger करें, test environment पर documented default credentials आज़माएँ।
• A03:2025 Software Supply Chain Failures: vulnerable, unmaintained, untracked या compromised components, build tools और update channels। Check: versions के साथ dependency inventory माँगें और पूछें कि हर release से पहले advisories देखी जाती हैं या नहीं।
• A04:2025 Cryptographic Failures: बिना encryption भेजा या रखा गया sensitive data, कमज़ोर algorithms, hard-coded keys। Check: हर endpoint पर TLS की पुष्टि करें; clear text में stored या logged passwords, card numbers या tokens खोजें।
• A05:2025 Injection: untrusted input बिना escaping किसी interpreter (SQL, OS command, template, HTML) तक पहुँचना; cross-site scripting (XSS), जहाँ input किसी दूसरे user के browser में script बनकर चल जाता है, यहीं आती है। Check: हर field में एक quote, angle bracket या semicolon; errors, बदले results या rendered markup पर नज़र रखें।
• A06:2025 Insecure Design: business logic सही code के साथ भी दुरुपयोग की इजाज़त देता है, जैसे coupon दो बार लगना। Check: बेईमान user की तरह flow पर चलें और बिना किसी technical trick के rule तोड़ने की कोशिश करें।
• A07:2025 Authentication Failures: कमज़ोर passwords स्वीकार, lockout या throttling नहीं, user enumeration, logout के बाद भी चलती sessions। Check: ग़लत-password attempts, मौजूद और अनजान accounts के लिए अलग messages, logout के बाद पुराना token।
• A08:2025 Software or Data Integrity Failures: बिना verification भरोसा किया गया code या data: untrusted CDN से scripts, unsigned updates, असुरक्षित CI/CD pipeline। Check: पूछें कि build artefacts और updates कैसे verify होते हैं, और client जो data वापस भेजता है, जैसे cookie में एक serialised object, वह बिना integrity check स्वीकार होता है या नहीं।
• A09:2025 Security Logging and Alerting Failures: logins, failed logins और high-value transactions log नहीं होते, logs monitor नहीं होते, alerts नहीं उठते। Check: अपने tests के बाद पूछें कि आपके forbidden requests logs में दिखे या नहीं और किसी को alert मिला या नहीं।
• A10:2025 Mishandling of Exceptional Conditions: errors वहाँ handle नहीं होते जहाँ होते हैं, failing open (जब check ख़ुद error दे तब action की इजाज़त दे देना), दिखते हुए stack traces, failure के बाद inconsistent state। Check: missing parameter, बहुत बड़ी value या ग़लत type भेजें; साफ़ error और बंद दरवाज़े की अपेक्षा रखें।

आज़माएँ: सिक्योरिटी हेडर एनालाइज़र आज़माएँ: API ऑथेंटिकेशन टेस्टर आज़माएँ: कुकी एनालाइज़र

Worked example: एक endpoint, दस categories

एक customer portal logged-in customer को अपना invoice PDF में download करने देता है। इस request को list से गुज़ारने में कुछ ही मिनट लगते हैं और test conditions का एक छोटा, prioritized set मिलता है।

• A01: customer A के invoice 8812 के लिए customer B के token से request दोहराएँ। Expected: 403 या 404, PDF कभी नहीं। यह भी पूछें कि stored PDF का कोई predictable direct URL तो नहीं जो इस check को skip कर दे। पहली priority: invoices में personal और financial data होता है।
• A07 और A04: बिना token के request को 401 मिलना चाहिए; logout और expiry के बाद token काम करना बंद करे; response TLS पर जाए और किसी shared cache में cacheable न हो (Cache-Control: no-store या private)।
• A02 और A10: /api/invoices/abc/pdf और /api/invoices/99999999/pdf request करें। Expected: सही status वाला छोटा error, कोई stack trace नहीं, headers में framework version नहीं।
• A05 और A09: id numeric है, इसलिए quote वाली id भी भेजें, 8812'; response में database error exploitation के बिना भी finding है। Run के बाद developer से कहें कि आपके forbidden requests log में खोजें।
• A03, A06 और A08 team के लिए सवाल हैं: कौन-सी PDF library और version invoice बनाती है (A03), क्या unpaid order का invoice बन सकता है (A06), और PDF server के अपने records से बनता है या client के भेजे values, जैसे amount, से बिना verification (A08)।

GET /api/invoices/8812/pdf HTTP/1.1
Host: portal.example.com
Authorization: Bearer <access token of customer A>
Accept: application/pdf

आज़माएँ: API रिक्वेस्ट बिल्डर आज़माएँ: JWT क्लेम एनालाइज़र आज़माएँ: स्पेशल कैरेक्टर डेटासेट जनरेटर

अक्सर पूछे जाने वाले सवाल

संदर्भ

• OWASP Top 10:2025OWASP Foundation · 2025वेब एप्लिकेशन की दस सबसे गंभीर सुरक्षा जोखिम, हर एक की जाँच और रोकथाम के साथ।
• OWASP Web Security Testing Guide (WSTG)OWASP Foundationवेब एप्लिकेशन और API की सुरक्षा कमज़ोरियों को परखने की संदर्भ कार्यप्रणाली, एक-एक टेस्ट के रूप में।
• OWASP Application Security Verification Standard (ASVS)OWASP Foundationवेब एप्लिकेशन के लिए सत्यापन-योग्य सुरक्षा आवश्यकताओं की चेकलिस्ट, तीन एश्योरेंस स्तरों में।
• OWASP API Security Top 10 (2023)OWASP Foundation · 2023API की दस सबसे आम कमज़ोरियाँ: ऑब्जेक्ट-लेवल ऑथराइज़ेशन का टूटना, ऑथेंटिकेशन का टूटना, अनियंत्रित रिसोर्स खपत और अन्य।