API सिक्योरिटी टेस्टिंग

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

Data API के पास होता है; user interface उसे सिर्फ़ दिखाता है। छिपे हुए buttons और client-side validation उस caller से कुछ नहीं बचाते जो API से सीधे बात करता है, और ज़्यादातर callers यही करते हैं: mobile apps, partner integrations और दूसरी services। एक missing ownership check हर customer के records हर दूसरे customer के सामने खोल देती है; बिना limit वाला एक OTP endpoint किसी script को तब तक codes आज़माने देता है जब तक कोई चल न जाए। ऐसे defects data breaches और fraud बन जाते हैं, cosmetic bugs नहीं।

Tester के लिए अच्छी ख़बर यह है कि इनमें से ज़्यादातर checks वही हैं जो आप पहले से करते हैं, बस थोड़े अलग रूप में: token बदलें, id बदलें, raw response पढ़ें, request दोहराएँ, दो responses की तुलना करें। इनके लिए न scanner चाहिए न exploit skills, और जो functional tester हर नए endpoint पर इन्हें चलाता है वह इनमें से कई defects penetration test से बहुत पहले पकड़ लेता है।

OWASP API Security Top 10 (2023) एक checklist के रूप में

OWASP APIs के लिए अलग Top 10 इसलिए प्रकाशित करता है क्योंकि API के risks web pages के risks से अलग हैं: हमला करने के लिए कोई browser नहीं है, लेकिन हर request में ids हैं, sessions की जगह tokens हैं और छिपाने के लिए कोई screen नहीं। 2023 edition ने 2019 edition की जगह ली और list को फिर से व्यवस्थित किया; 2019 के दो नाम अब भी कई teams इस्तेमाल करती हैं, "Excessive Data Exposure" (अब API3 का हिस्सा) और "Lack of Resources & Rate Limiting" (अब API4), इसलिए यह lesson दोनों नाम देता है।

हर entry को एक सवाल की तरह पढ़ें जो आप हर endpoint के बारे में पूछते हैं, साथ में एक safe check जो आप test environment में अपने test accounts से चला सकते हैं:

• API1:2023 Broken Object Level Authorization (BOLA): API client से आई id पर बिना यह जाँचे भरोसा करती है कि caller को उस object तक पहुँच का हक़ है या नहीं। Check: वही request दूसरे user के token से।
• API2:2023 Broken Authentication: tokens और logins कमज़ोर या असीमित हैं: expiry या logout के बाद भी tokens स्वीकार होते हैं, password या OTP की unlimited attempts, URLs में credentials। Check: missing, expired, revoked और tampered tokens; allowed attempts गिनें।
• API3:2023 Broken Object Property Level Authorization: response में ऐसी properties हैं जो caller को नहीं दिखनी चाहिए (excessive data exposure) या request ऐसी properties set कर सकती है जो उसे नहीं करनी चाहिए (mass assignment)। Check: raw JSON को contract से मिलाएँ; एक extra field भेजें।
• API4:2023 Unrestricted Resource Consumption: request rate, page size, upload size या SMS जैसी पैसे ख़र्च करने वाली operations पर कोई limit नहीं। Check: तेज़ी से दोहराएँ, pageSize=50000 माँगें, maximum से एक byte बड़ा upload करें।
• API5:2023 Broken Function Level Authorization: एक role दूसरे role का function call कर सकता है। Check: admin endpoint पर customer token, जैसा API authorization testing के lesson में।
• API6:2023 Unrestricted Access to Sensitive Business Flows: ऐसा flow जो automate होने पर business को नुक़सान पहुँचाता है (सारा stock ख़रीद लेना, हर slot book कर लेना, mass sign-ups) बिना किसी limit, step-up check (CAPTCHA या one-time code जैसा एक अतिरिक्त verification) या review के। Check: एक account से flow को script करें और देखें कि कुछ उसे धीमा करता है या नहीं।
• API7:2023 Server Side Request Forgery (SSRF): server client का दिया हुआ URL, जैसे webhook या image import, बिना allow-list के fetch करता है। Check: अपने control वाला capture URL दें (ऐसा URL जो उस तक आई हर request record करता है, जैसे Webhook Tester का URL) और देखें कि server क्या fetch करता है; private addresses को probe करने के बजाय developer से पूछें कि वे कैसे refuse होते हैं।
• API8:2023 Security Misconfiguration: stack trace वाले verbose errors, TLS के बिना HTTP, किसी भी origin को allow करने वाला CORS, ग़ैर-ज़रूरी methods, default settings। Check: एक malformed request और response headers।
• API9:2023 Improper Inventory Management: पुराने versions और debug endpoints अब भी जवाब देते हैं; OpenAPI document और deployed API अलग हैं। Check: /v2 ship होने के बाद /v1 call करें; जो जवाब देता है पर documented नहीं है उसकी list बनाएँ।
• API10:2023 Unsafe Consumption of APIs: partner API के data पर बिना validation, size limits या redirect checks के भरोसा किया जाता है। Check: partner को mock करें और bad data लौटाएँ।

आज़माएँ: OpenAPI → टेस्ट केस आज़माएँ: Webhook टेस्टर आज़माएँ: API हेडर वैलिडेटर

BOLA और broken authentication: पहले token बदलें, फिर id

BOLA सबसे बड़ा risk इसलिए है क्योंकि APIs में ids हर जगह हैं और caller उस object का owner है या नहीं, यह check हर id के लिए लिखनी पड़ती है। API authorization testing के lesson में users × requests matrix बनी थी; security pass उसे उन ids तक बढ़ाता है जो matrix से अक्सर छूट जाती हैं: ?accountId= जैसी query strings, request bodies, headers, /parcels/7731/label.pdf जैसे nested routes, batch और export endpoints, और file downloads, जो अक्सर अलग code path से serve होते हैं जहाँ कोई check ही नहीं होती। हमेशा एक ही role के दो accounts इस्तेमाल करें, और defect साबित करने वाले पहले record पर रुक जाएँ: आपका काम यह दिखाना है कि check missing है, दूसरों का data इकट्ठा करना नहीं।

API में broken authentication ज़्यादातर tokens और login के आसपास के endpoints की बात है। हर protected endpoint पर request चार तरह से भेजें और हर बार 401 की उम्मीद करें, API authentication के lesson की तरह WWW-Authenticate header के साथ, और body में कोई data या internal detail नहीं: बिना token, expired token, logout कर चुके session का token, और ऐसा token जिसके signature का एक character बदला गया हो। फिर उन endpoints को देखें जो credentials जारी करते हैं:

• Password, OTP और password-reset verification: गिनें कि 429 या lockout से पहले API कितनी ग़लत attempts स्वीकार करती है। छह अंकों के OTP की दस लाख संभावित values होती हैं; बिना limit के guessing सिर्फ़ समय की बात है।
• JWTs: "alg": "none" वाला header स्वीकार नहीं होना चाहिए, और किसी दूसरे audience के लिए जारी हुआ token, या ऐसे issuer का token जिस पर API भरोसा नहीं करती, refuse होना चाहिए; RFC 8725 (JWT Best Current Practices) ये checks बताता है। JWT Header Analyzer और JWT Claims Analyzer दिखाते हैं कि token क्या claim करता है, इससे पहले कि आप टेस्ट करें कि API उसके साथ क्या करती है।
• Error bodies: "wrong password" और "no such account" एक जैसे पढ़ने चाहिए, वरना login endpoint बता देता है कि कौन-से accounts मौजूद हैं।
• Credentials और tokens की जगह URLs, logs या error messages में कभी नहीं है; query string में गया token हर proxy के log में पहुँच जाता है।

# One protected request, four ways.
# Expected: 401 each time, with WWW-Authenticate and no data in the body
GET /v1/users/me HTTP/1.1
Host: api.example.test
# 1. no Authorization header
# 2. Authorization: Bearer <expired token>
# 3. Authorization: Bearer <token of a session that has logged out>
# 4. Authorization: Bearer <valid token with one signature character changed>

# OTP verification: send code 000001, then 000002, 000003 ...
# Expected: 429 or a lockout after a small number of attempts
POST /v1/auth/otp/verify HTTP/1.1
Host: api.example.test
Content-Type: application/json

{"phone": "+9665XXXXXXXX", "code": "000001"}

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

Excessive data exposure और missing rate limits

Excessive data exposure तब होता है जब API पूरा object लौटा देती है और client पर भरोसा करती है कि वह उसका सिर्फ़ एक हिस्सा दिखाएगा। Profile screen नाम और avatar दिखाती है; raw response में e-mail address, phone number, national id, internal notes या password hash भी होता है। 2023 edition इस risk को mass assignment के साथ API3 में मिला देता है, क्योंकि दोनों एक ही missing सवाल हैं: क्या यह caller यह property देख, या set कर सकता है? Read side को हर raw response की contract से तुलना करके टेस्ट करें, जैसा API schema validation के lesson में, और हर field के लिए पूछें कि क्या इस role को इसकी ज़रूरत है। Write side को टेस्ट करने के लिए एक otherwise valid PATCH या POST में ऐसी property जोड़ें जिस पर caller का control नहीं होना चाहिए, "role": "admin", "balance": 9999 या "verified": true, फिर object को दोबारा पढ़ें: सही नतीजे हैं 400, या field का चुपचाप ignore होना और बदला न होना।

Rate limits उन resources की रक्षा करती हैं जिन्हें हर request खर्च करती है: CPU, memory, bandwidth, database connections और पैसा, जब कोई endpoint SMS भेजता है या paid service call करता है। इनके बिना एक client सबके लिए service ख़त्म कर सकता है या ऊपर बताए guessing attacks चला सकता है। RFC 6585 इसके लिए 429 Too Many Requests परिभाषित करता है और कहता है कि response में Retry-After header हो सकता है। एक safe test के तीन हिस्से हैं, और एक जगह:

• Rate: वही request तेज़ी से भेजें, team से तय संख्या में, और दर्ज करें कि पहला 429 किस request number पर आया, उसके साथ कौन-से headers आए, और limit per user है, per API key है या per IP address, क्योंकि सिर्फ़ IP वाली limit client के address बदलते ही फिर से शुरू हो जाती है।
• Size: ?pageSize=50000 माँगें, documented maximum से एक byte बड़ी body भेजें या upload करें, और JSON body को किसी भी client से ज़्यादा गहरा nest करें। 400 या 413 और capped page की उम्मीद करें, 50000 rows वाला response कभी नहीं।
• Cost: जो endpoints SMS या e-mail भेजते हैं या partner call करते हैं, उन पर पक्का करें कि per-user daily limit मौजूद है और उसे server लागू करता है, app नहीं।
• जगह: सिर्फ़ ऐसा test environment जिस पर load डालने की आपको अनुमति है, team से तय संख्याओं के साथ, क्योंकि test खुद एक load है; production पर कभी नहीं और किसी और के system पर कभी नहीं।

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

Worked example: एक telecom self-service API पर security pass

Test environment में एक telecom self-service API, अपनी-अपनी test lines वाले दो customer accounts A और B, एक OpenAPI document और team की written permission। Plan में पाँच endpoints और ऊपर के चार risks हैं; expected results पहली request से पहले contract से लिखे गए। आठ checks में से छह ने defects पकड़े:

• C1, BOLA: GET /v1/accounts/A/invoices पर B के token ने 404 की जगह A के invoices के साथ 200 लौटाया। Critical: कोई भी customer किसी भी customer के invoices पढ़ सकता है।
• C3, broken authentication: logout कर चुके session का token अब भी स्वीकार हुआ; logout ने उसे सिर्फ़ device से हटाया था। Major।
• C4, broken authentication: लगातार 50 ग़लत OTP codes, सब 400, न 429 न lockout। Critical: login code guess किया जा सकता है।
• C5, excessive data exposure: GET /v1/users/me ने nationalId और passwordHash लौटाए, जिनमें से कोई contract में नहीं है। Critical: identity data और password hash किसी भी client तक पहुँचते हैं।
• C6, mass assignment: "planTier": "premium" के साथ PATCH /v1/users/me ने 200 लौटाया, और नए GET में plan upgraded दिखा। Major, financial impact के साथ।
• C7, resource consumption: A की test line के usage records पर ?pageSize=50000 ने सारे 12000 records एक ही page में, नौ seconds में लौटाए; contract की limit (100) लागू नहीं थी। Major।

Telecom self-service API, test environment. Customers A and B, each with a test line.

#   Risk  Request (actor)                               Expected     Observed
C1  API1  B: GET /v1/accounts/A/invoices                404          200, A's invoices
C2  API2  no token: GET /v1/users/me                    401          401
C3  API2  A after logout: GET /v1/users/me              401          200
C4  API2  POST /v1/auth/otp/verify, 50 wrong codes      429 early    50 x 400, no lockout
C5  API3  A: GET /v1/users/me, fields vs contract       contract     2 extra fields
C6  API3  A: PATCH /v1/users/me {"planTier":"premium"}  400/ignored  200, plan upgraded
C7  API4  A: GET /v1/accounts/A/usage?pageSize=50000    100 rows     12000 rows, 9 s
C8  API4  A: GET /v1/accounts/A/invoices, 60 in 10 s    429 after 30 429 from request 31

आज़माएँ: REST API टेस्टर आज़माएँ: API रिस्पॉन्स कम्पेरेटर

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

संदर्भ

• OWASP API Security Top 10 (2023)OWASP Foundation · 2023API की दस सबसे आम कमज़ोरियाँ: ऑब्जेक्ट-लेवल ऑथराइज़ेशन का टूटना, ऑथेंटिकेशन का टूटना, अनियंत्रित रिसोर्स खपत और अन्य।
• OWASP Cheat Sheet Series: REST SecurityOWASP FoundationREST API के सुरक्षा नियम: HTTPS, हर रिक्वेस्ट पर ऑथेंटिकेशन, इनपुट वैलिडेशन, सुरक्षित एरर रिस्पॉन्स, रेट लिमिटिंग।
• RFC 6585: Additional HTTP Status CodesIETF · 2012428, 429 Too Many Requests, 431 और 511 को परिभाषित करता है, रेट लिमिटिंग के लिए Retry-After हेडर सहित।
• RFC 8725: JSON Web Token Best Current PracticesIETF · 2020JWT इम्प्लीमेंटेशन के सुरक्षा नियम: alg=none अस्वीकार करें, एल्गोरिद्म पिन करें, iss/aud जाँचें, छोटी अवधि रखें।