मॉड्यूल 17 · सिक्योरिटी टेस्टिंग

एक्सेस कंट्रोल टेस्टिंग

Mutqan Soft QA टीम द्वारा · · 19 मिनट · मध्यम

Access control testing यह जाँचती है कि authentication और authorization के lesson में सीखा गया authorization decision हर request पर सच में लागू होता है: server ठीक वही allow करता है जो access policy allow करती है, हर role, action और record के लिए, और बाक़ी सब refuse करता है। यह स्वभाव से negative testing है: आप जान-बूझकर वह माँगते हैं जो current user को नहीं मिलना चाहिए। एक invoicing app में viewer account, developer tools से copy की गई accountant की "send invoice" request फिर से भेजता है और 403 की उम्मीद करता है, invoice जैसी थी वैसी ही रहे।

Access control तीन तरह से टूटता है: vertical, जब निचला role ऊँचे role का function कर लेता है; horizontal, जब कोई user उसी level पर दूसरे user का record पा लेता है, जिसे insecure direct object reference (IDOR) कहते हैं जब record ऐसे identifier से पहचाना जाता है जिसे caller बदल सकता है; और function-level, जब कोई function protected ही नहीं है। Roles × actions की matrix policy को इन तीनों के लिए test conditions में बदल देती है।

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

OWASP Top 10:2025 Broken Access Control को पहले स्थान (A01) पर रखता है; OWASP API Security Top 10 (2023) Broken Object Level Authorization (API1) से शुरू होता है और Broken Function Level Authorization (API5) भी सूचीबद्ध करता है। असली users अपने role के लिए बनी screens पर चलते हैं, इसलिए उन्हीं screens पर चलने वाली testing वे requests कभी नहीं भेजती जो ये defects उजागर करती हैं, और एक बदला हुआ identifier हर customer का data उजागर कर सकता है।

Tester के लिए ये tests सस्ते और क़ीमती हैं: दो test accounts और एक request tool, policy से तय expected results जिससे automation आसान है, और findings जिनकी severity अक्सर critical या major रखी जाती है क्योंकि वे किसी और का data या action उजागर करती हैं।

Vertical, horizontal और function-level failures

Authorization हर request पर एक सवाल का जवाब देता है: क्या यह identity इस resource पर यह action कर सकती है? Check दो levels पर होता है: function-level check पूछता है कि यह role यह function कर ही सकता है या नहीं (user invite करना, सभी invoices export करना); object-level check पूछता है कि यह user इसी record पर काम कर सकता है या नहीं (invoice 3107, 3108 नहीं)। दो failures का नाम उस दिशा से रखा जाता है जिसमें caller access पाता है, और तीसरे का उस check से जो गायब है।

  • Vertical privilege escalation: निचला role ऊँचे role का function इस्तेमाल करता है, जैसे viewer owner की POST /api/users request भेजता है। Check गायब है या client पर भरोसा करता है, जैसे cookie या request body में भेजा गया role। Expected: 403, और कुछ नहीं होता।
  • Horizontal privilege escalation: वही role, किसी और का record। Company A का accountant एक number बदलकर GET /api/invoices/3108 माँगता है, जो Company B का invoice है। OWASP इसे insecure direct object reference (IDOR) कहता है; API Security Top 10 इसी defect को Broken Object Level Authorization (BOLA) कहता है। Expected: 403, या 404 जब contract दूसरे customers के records छिपाता है।
  • Function-level access control गायब: ऐसा function जिसे सिर्फ़ obscurity बचा रही है। Link दिखाया नहीं जाता, endpoint documented नहीं है, पुराना /api/v1/export अब भी जवाब देता है, या check GET पर है पर उसी URL पर DELETE पर नहीं। Expected: policy के अनुसार 401 या 403; कोई भी success defect है। गायब function-level check ही अक्सर vertical escalation की वजह भी होता है; अलग नाम आपका ध्यान उन functions पर रखता है जिन्हें न कोई screen दिखाती है, न कोई list गिनाती है।
  • एक और बारीक level है: जो user record update कर सकता है वह ऐसा field बदल देता है जो उसका नहीं, जैसे profile update में "role": "owner", जिसे API Security Top 10 Broken Object Property Level Authorization (API3:2023) कहता है। इसे अपनी list में रखें; API security testing का lesson इसे गहराई से लेता है।

आज़माएँ: API रिक्वेस्ट बिल्डर

Access policy से roles × actions matrix तक

Test basis access policy है। कम ही teams इसे लिखकर रखती हैं, इसलिए इसे requirements, role descriptions, हर role के menus और API contract से जोड़ें, और product owner से confirm कराएँ: हर cell जो आप भर नहीं सकते, एक सवाल है। Rows roles हैं, साथ में Anonymous और horizontal case के लिए दूसरी team या company में उसी role का user। Columns product का हर action हैं, किसी एक role की screens से नहीं बल्कि हर source से: menus, API contract, exports, admin pages, और वे requests जो सबसे ऊँचे role का session भेजता है।

कुछ भी भेजने से पहले हर cell में expected result भरें: allowed cell के लिए success status और दिखने वाला असर, refused cell के लिए status और "no side effect"। हर cell एक test condition है: जिस refused cell का action ऊँचे role का है वह vertical test है; जो allowed cell किसी record का नाम लेता है उसे दूसरे user के record के साथ दोहराया जाता है, यह horizontal test है; और हर column को हर row में direct request से भी माँगा जाता है, यह function-level test है। OWASP Authorization Cheat Sheet teams से authorization logic के unit और integration tests लिखने को कहती है; matrix उन tests और आपके tests का साझा source है।

आज़माएँ: OpenAPI → टेस्ट केस

Worked example: तीन roles वाला invoicing app

https://invoices.test पर एक invoicing service, ऐसे test environment में जिसे test करने की आपके पास written permission है, कई companies को serve करती है। Policy: "User एक company का होता है और सिर्फ़ उसका data देखता है; दूसरी company के invoice की request 404 देती है। Viewers invoices पढ़ते हैं। Accountants invoices बनाते और भेजते भी हैं। Owners सभी invoices export और users invite भी करते हैं। Valid session के बिना API 401 देता है।" Test accounts: Company A में Maha (viewer), Yousef (accountant) और Rana (owner), जिसका invoice 3107 है, और Company B में Tariq (accountant)।

Rana के रूप में sign in करें, पाँच actions में से हर एक को एक बार करें और हर action जो भी requests भेजता है उन्हें Network panel से cURL के रूप में copy करें; जैसे invoice 3107 खोलने पर उसका PDF preview भी GET /api/invoices/3107/pdf से load होता है। फिर हर request को request tool में बारी-बारी Maha, Yousef और Tariq की session cookie के साथ और एक बार बिना cookie के replay करें, और कुछ न बदलें। अगर request में Rana के session से जुड़ा कोई token भी है, जैसे anti-CSRF token, तो उसे भी बदलें, वरना refusal authorization से नहीं बल्कि उस token check से आ सकता है। इस run में दो defects मिले।

Invoicing app का access matrix: caller और action के 24 cells में से सिर्फ़ 9 allowed हैं; viewer को accountant और owner के हर action पर 403 मिलता है, और Company B के accountant को Company A के invoice 3107 पर 404 मिलता है।
CallerA1 · invoice 3107 देखनाGET /api/invoices/3107A2 · invoice बनानाPOST /api/invoicesA3 · invoice 3107 भेजनाPOST /api/invoices/3107/sendA4 · सभी invoices exportGET /api/export/invoices.csvA5 · user invite करनाPOST /api/users
Anonymoussession नहीं401authentication401authentication401authentication401authentication401authentication
Maha · viewerCompany A200allowed403vertical403vertical403vertical403vertical
Yousef · accountantCompany A200allowed201allowed200allowed403vertical403vertical
Rana · ownerCompany A200allowed201allowed200allowed200allowed201allowed
Tariq · accountantCompany B, Company A के invoice पर404horizontal (IDOR)Company A का कोई record शामिल नहीं404horizontal (IDOR)403vertical403vertical
  • Policy के अनुसार allowed, expected success code के साथ
  • Vertical test: caller के role से ऊपर के function पर 403
  • Horizontal (IDOR) test: दूसरी company के invoice पर 404, जिसे contract छिपाता है
  • Authentication: valid session के बिना 401

कोई request भेजने से पहले policy से लिखे गए expected results: viewers invoices पढ़ते हैं; accountants उन्हें बनाते और भेजते भी हैं; owners सभी invoices export और users invite भी करते हैं; दूसरी company का invoice 404 देता है।

  • Maha की POST /api/invoices/3107/send replay ने 200 दिया और customer को invoice मिल गया: vertical escalation; check सिर्फ़ menu में था। Severity: critical।
  • Tariq की GET /api/invoices/3107 ने सही 404 दिया, पर PDF preview की request GET /api/invoices/3107/pdf ने PDF दे दिया: उसी record तक दूसरे route से horizontal escalation। Severity: critical।
  • बाक़ी हर cell matrix से मेल खाया। हर fix की पुष्टि पूरा column फिर चलाकर करें, सिर्फ़ fail हुई cell से नहीं।
पाठ संस्करण
Expected result per cell, written from the policy before any request is sent

Caller                 A1 view 3107  A2 create  A3 send 3107  A4 export  A5 invite
Anonymous              401           401        401           401        401
Maha, viewer A         200           403        403           403        403
Yousef, accountant A   200           201        200           403        403
Rana, owner A          200           201        200           200        201
Tariq, accountant B    404           -          404           403        403

401 = authentication (no session)    403 = vertical: a function above the role
404 = horizontal: Company B's user on Company A's invoice (the contract hides it)

आज़माएँ: cURL पार्सर आज़माएँ: API ऑथेंटिकेशन टेस्टर आज़माएँ: API रिस्पॉन्स कम्पेरेटर

Unprotected functions और identifiers कहाँ छिपते हैं

Matrix उतनी ही पूरी है जितने उसके columns, और function-level defects उन columns में रहते हैं जिन्हें किसी ने लिखा ही नहीं। Sign-off से पहले देखें कि obvious list क्या छोड़ रही है।

  • उसी record तक दूसरे routes: PDF या print view, company filter वाला search endpoint, bulk export, sharing link।
  • उसी URL के दूसरे methods और versions: GET पर check पर PUT या DELETE पर नहीं, या अब भी deployed पुराना API version।
  • Client के अपने बारे में भेजे values: body, query string, cookie या hidden field में companyId, role या isOwner। Server को identity और company session से लेनी चाहिए; ये values बदलें और उम्मीद करें कि वे ignore या refuse हों।
  • Files और random identifiers: storage URL से बिना session check serve होता uploaded PDF, या मुश्किल से guess होने वाला UUID। दोनों record छिपाते हैं; कोई भी reader को authorize नहीं करता। दूसरे test account से असली identifier copy करें और refusal की उम्मीद करें।

आज़माएँ: REST API टेस्टर

आम गलतियाँ

  • हर role को सिर्फ़ उसकी अपनी screens से test करना और वे requests कभी न भेजना जो screens offer नहीं करतीं।
  • ज़्यादातर tests owner या admin account से चलाना, जो हर check pass करता है और इसलिए कोई check test नहीं करता।
  • Record का main route test करना और उसके PDF, export, search और sharing routes छोड़ देना।
  • कोई भी refusal मान लेना: login page पर redirect जिसकी body में अब भी data है, या 403 जिसके बाद action फिर भी हो गया। Body पढ़ें और बाद में data जाँचें।
  • छिपे links, random file names या UUIDs को access control समझना।
  • Production या ऐसा system test करना जिसकी written permission नहीं, या bug reports में live cookies और tokens mask किए बिना paste करना।

QA का नज़रिया

Refinement के दौरान ही access policy माँगें, जैसे ही किसी feature में एक से ज़्यादा role या एक से ज़्यादा owner हो: कौन-से roles हैं, हर तरह के record का owner कौन है, हर role क्या कर सकता है, और refusal कौन-सा status देता है, दूसरी company के record के लिए भी। Matrix को test basis के रूप में लिखें, product owner से हर cell confirm कराएँ, और हर role के लिए test accounts माँगें, साथ में दूसरी team या company में उसी role का एक और user।

हर run को matrix के रूप में record करें, हर cell के expected और actual result के साथ; bug report में cell, दोनों identities, masked credentials, request, response और side effect लिखें। क्योंकि expected results policy से तय हैं, matrix को API tests में बदलें जो हर release पर चलें। Exploitation security specialists पर छोड़ें, और scope तय करने वाली written permission के बिना test environment के बाहर कुछ भी test न करें।

अभ्यास

Course platform की access matrix बनाएँ

आपका काम

एक course platform में तीन roles हैं। Learners सिर्फ़ अपने submissions और certificates देखते हैं। Instructors अपने पढ़ाए courses की learner list देखते हैं, उनके submissions देखते और grade करते हैं, और उनके certificates देखते हैं। Admins सब कुछ करते हैं और सिर्फ़ वही payments refund करते हैं। API valid session के बिना 401, role जिस function का इस्तेमाल नहीं कर सकता उस पर 403, और दूसरे learner या दूसरे course के record पर 404 देता है। Test environment को test करने की आपके पास written permission है।

Material में दिए पाँच actions के सामने callers की matrix बनाएँ, हर cell का status predict करें, और हर refused cell को authentication, vertical या horizontal के रूप में label करें। फिर hidden functions वाले section से तीन tests जोड़ें।

सामग्री
Setup: submission 4410 = learner Lina, course QA-101 (instructor Hani)
       certificate 7702 = learner Omar, course DB-201 (instructor Dana)
       Lina and Omar are learners; Hani and Dana are instructors; Sami is an admin

#  Action                     Request
A1 view submission 4410       GET  /api/submissions/4410
A2 grade submission 4410      POST /api/submissions/4410/grade
A3 download certificate 7702  GET  /api/certificates/7702
A4 list learners of QA-101    GET  /api/courses/QA-101/learners
A5 refund a payment           POST /api/payments/88/refund
चरण
  1. Callers लिखें: Anonymous, हर role, और horizontal case के लिए उसी role का दूसरा user।
  2. हर source से actions लिखें, वे भी जो learner कभी नहीं देखता।
  3. System देखने से पहले हर cell policy से भरें।
  4. हर refused cell को label करें: authentication (401), vertical (403) या horizontal (404)।
  5. दूसरे routes, methods और client-supplied values के tests जोड़ें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Anonymous: हर column में 401 (authentication)। Sami, admin: हर column में allowed, reads पर 200 और grade व refund पर contract के अनुसार 200 या 201।

Lina, learner और 4410 की owner: A1 200; A2 403 (vertical: learners कभी grade नहीं करते); A3 404 (horizontal: Omar का certificate); A4 403 और A5 403 (vertical)।

Omar, learner: A1 404 (horizontal, classic IDOR cell); A2 403 (vertical); A3 200; A4 403 और A5 403 (vertical)।

Hani, QA-101 का instructor: A1 200; A2 allowed (contract के अनुसार 200 या 201), फिर confirm करें कि grade store हुआ; A3 404 (horizontal: Dana के course का certificate); A4 200; A5 403 (vertical: refund सिर्फ़ admin का)।

Dana, DB-201 की instructor: A1 और A2 404 (horizontal: दूसरे course का submission, grade अपरिवर्तित); A3 200; A4 404 (horizontal: दूसरे instructor का course); A5 403 (vertical)।

Hidden-function tests, जैसे: Lina, Omar का certificate file के रूप में GET /api/certificates/7702/pdf से माँगती है, expected 404 और कोई file नहीं; Lina DELETE /api/submissions/4410 भेजती है, expected contract के अनुसार 403 या 405 और कोई बदलाव नहीं; Dana body में "courseId": "DB-201" के साथ 4410 grade करती है, expected 404 और grade अपरिवर्तित।

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

क्या IDOR और horizontal privilege escalation एक ही चीज़ हैं?

IDOR horizontal escalation का typical रूप है: record ऐसे identifier से पहचाना जाता है जिसे caller बदल सकता है, और server ownership check नहीं करता। Horizontal escalation search filters, exports और sharing links से भी होता है जो बिना कोई identifier edit किए दूसरे users के records लौटा देते हैं। API Security Top 10 इन सबको Broken Object Level Authorization (BOLA) के तहत रखता है।

मुझे कितने test accounts चाहिए?

हर role का कम से कम एक, और horizontal row के लिए दूसरी team या company में उसी role का एक और user, सब test environment में और कभी असली users के accounts नहीं। Multi-tenant products के लिए, जहाँ एक system कई companies को serve करता है, दो companies चाहिए जिनके अपने records हों, ताकि हर object-bound action के लिए किसी और का record मौजूद हो।

क्या random UUIDs से IDOR tests बेकार हो जाते हैं?

नहीं। UUID guess करना मुश्किल है, पर identifiers exports, emails, logs और दूसरे users के pages से leak होते हैं, और server को request refuse करनी ही चाहिए, चाहे कोई भी भेजे। दूसरे test account से असली identifier copy करें और वही refusal expect करें जो sequential id को मिलती।

संदर्भ

  • OWASP Web Security Testing Guide (WSTG)OWASP Foundationवेब एप्लिकेशन और API की सुरक्षा कमज़ोरियों को परखने की संदर्भ कार्यप्रणाली, एक-एक टेस्ट के रूप में।
  • OWASP Top 10:2025OWASP Foundation · 2025वेब एप्लिकेशन की दस सबसे गंभीर सुरक्षा जोखिम, हर एक की जाँच और रोकथाम के साथ।
  • OWASP Cheat Sheet Series: AuthorizationOWASP Foundationसही access control: least privilege, deny by default, हर request पर permission जाँच, attribute- या relationship-आधारित मॉडल को प्राथमिकता, और authorization logic का टेस्ट।
  • OWASP API Security Top 10 (2023)OWASP Foundation · 2023API की दस सबसे आम कमज़ोरियाँ: ऑब्जेक्ट-लेवल ऑथराइज़ेशन का टूटना, ऑथेंटिकेशन का टूटना, अनियंत्रित रिसोर्स खपत और अन्य।
टूल्स

Mutqan tools से अभ्यास करें

API रिक्वेस्ट बिल्डर

HTTP रिक्वेस्ट (method, URL, हेडर, auth, बॉडी) बनाएँ और भेजें, फिर रिस्पॉन्स जाँचें — आपके ब्राउज़र में हल्का-फुल्का Postman।

API टेस्टिंग

API ऑथेंटिकेशन टेस्टर

किसी endpoint पर Bearer, Basic, API-key और कस्टम-हेडर प्रमाणीकरण टेस्ट करें और अधिकृत बनाम अनधिकृत रिस्पॉन्स की तुलना करें।

API टेस्टिंग

REST API टेस्टर

method, हेडर और JSON बॉडी पर पूरे नियंत्रण के साथ REST endpoint टेस्ट करें, फिर स्टेटस, हेडर और JSON path पर assertion लगाएँ।

API टेस्टिंग

API रिस्पॉन्स कम्पेरेटर

दो API रिस्पॉन्स (जैसे staging बनाम production) की तुलना करें और हर संरचनात्मक तथा वैल्यू का अंतर देखें।

API टेस्टिंग

OpenAPI → टेस्ट केस

OpenAPI / Swagger स्पेसिफ़िकेशन से संरचित टेस्ट-केस मैट्रिक्स (positive, negative, auth, boundary) बनाएँ।

ऑटोमेशन

cURL पार्सर

cURL कमांड को मेथड, URL, हेडर और बॉडी में पार्स करें, फिर उसे fetch, axios, Python या संरचित रिक्वेस्ट में बदलें।

वेब

और गहराई से

इस topic में आपकी प्रगति

QA रोडमैप का हिस्सा