मॉड्यूल 14 · API टेस्टिंग

API ऑथराइज़ेशन टेस्टिंग

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

API authorization testing जाँचती है कि API हर authenticated caller को सिर्फ़ वही करने दे जिसकी access policy अनुमति देती है: सही functions, सही objects पर, सही fields के साथ। Authentication बताता है कि request किसने भेजी; authorization तय करता है कि वह caller यह कर सकता है या नहीं। Customer B ठीक से sign in है, इसलिए B के token के साथ GET /v1/orders/9021 authentication पास कर लेती है; लेकिन अगर order 9021 customer A का है, तो API को फिर भी इसे reject करना चाहिए।

Tester का मुख्य औज़ार test matrix है: एक तरफ़ users, ऊपर requests, और हर cell में policy के अनुसार expected जवाब।

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

Authorization defects data और actions उन लोगों के सामने खोल देते हैं जिनके पास पहले से valid account है। OWASP API Security Top 10 (2023) में Broken Object Level Authorization पहले स्थान (API1:2023) पर है: एक ownership check छूट जाए, तो कोई भी customer URL में एक number बदलकर दूसरे customers के पते पढ़ सकता है।

Normal use में ये defects कभी नहीं दिखते: app user को सिर्फ़ उसका अपना data दिखाता है और admin buttons छिपा देता है। इन्हें सिर्फ़ वही test पकड़ता है जो जानबूझकर गलत user बनकर API call करे।

Roles, ownership और access policy

Authorization decision तीन चीज़ों को साथ देखता है: caller कौन है, वह क्या करना चाहता है, और किस object को छूता है। ज़्यादातर products role-based access control (RBAC) को, जहाँ customer, support agent या admin जैसा role कुछ functions देता है, ownership rules के साथ जोड़ते हैं: customers सिर्फ़ अपने objects पर काम करते हैं। Multi-tenant products एक rule और जोड़ते हैं: users किसी दूसरी company का data कभी नहीं देखते।

लिखे हुए ये rules ही access policy हैं, यानी आपका test basis। OWASP Authorization Cheat Sheet default रूप से deny करने, least privilege देने और हर request पर permissions validate करने की सलाह देती है। Testing के लिए इसका मतलब:

  • Boundary API है, screen नहीं: "Refund" button छिपाने से कुछ सुरक्षित नहीं होता अगर POST /v1/orders/{id}/refund customer का token स्वीकार कर ले।
  • Role server के अपने records या verified token claim से आता है, client input से कभी नहीं, जैसे X-Role: admin header या body में "isAdmin": true।
  • OAuth पाठ के scopes तय करते हैं कि client application क्या कर सकता है: ज़रूरी scope के बिना token पर insufficient_scope के साथ 403 मिलता है। Scopes role और ownership checks के साथ जुड़ते हैं, उनकी जगह कभी नहीं लेते: orders.write वाला token भी किसी दूसरे customer का order नहीं बदल सकता।
  • जैसा API authentication पाठ में देखा, 401 का मतलब है valid credential नहीं, और 403 का मतलब है जाने-पहचाने caller को मना करना। RFC 9110 resource का होना छिपाने के लिए 404 की भी अनुमति देता है; कौन-सा लागू होगा, यह contract तय करता है।

आज़माएँ: JWT डिकोडर

तीन levels: function, object और property

Authorization तीन levels पर टूटता है, और OWASP API Security Top 10 में हर level का एक risk है। ऊँचे role के functions हासिल करना vertical privilege escalation है; उसी role में किसी दूसरे user के data तक पहुँचना horizontal।

  • Function level (API5:2023, Broken Function Level Authorization): क्या यह role यह operation call कर भी सकता है? Customer GET /v1/admin/users call करता है, या जिस path को वह सिर्फ़ पढ़ सकता है उस पर GET की जगह DELETE भेजता है।
  • Object level (API1:2023, BOLA, जिसे पुराने नाम IDOR यानी insecure direct object reference से भी जाना जाता है): क्या यह user इस object पर काम कर सकता है? Customer B, A के order की id भेजता है। IDs paths, query strings, bodies, headers और /orders/9021/invoice जैसे nested routes में छिपी होती हैं।
  • Property level (API3:2023, Broken Object Property Level Authorization): क्या यह user यह field देख या set कर सकता है? Response में ऐसे fields लौटते हैं जो caller को नहीं दिखने चाहिए, या API ऐसा field स्वीकार कर लेता है जिसे caller set नहीं कर सकता — इसे अक्सर mass assignment कहा जाता है।
# Function level: customer A's token on an admin function
GET /v1/admin/users
Authorization: Bearer <token of customer A>
-> expected 403

# Object level: customer B's token on customer A's order
GET /v1/orders/9021
Authorization: Bearer <token of customer B>
-> expected 404 (the contract hides other customers' orders)

# Property level: a customer sends a field only admins may set
PATCH /v1/users/me
Authorization: Bearer <token of customer A>
Content-Type: application/json

{"displayName": "Sara A.", "role": "admin"}
-> expected 400, or the role field ignored; A stays a customer

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

Test matrix बनाएँ: users × requests

Matrix policy को ऐसे test cases में बदल देता है जिन्हें आप गिन सकते हैं। कुछ भी भेजने से पहले इसे बनाएँ:

  • Rows: एक anonymous caller, हर role, और एक ही role के दो users (A और B), क्योंकि horizontal tests के लिए ऐसे objects चाहिए जो आपके नहीं हैं; multi-tenant products में दूसरे tenant का एक user भी।
  • Columns: OpenAPI document का हर endpoint और method, admin, search और export endpoints समेत, और वे पुराने versions भी जो अब भी deployed हैं।
  • Cells: policy से expected result, ऐसे test objects पर जिनका owner पता है, execution से पहले लिखा हुआ। ज़्यादातर cells refusals होते हैं, और defects वहीं छिपते हैं।
  • Execution: सिर्फ़ token बदलें, फिर status, body (किसी दूसरे user का data नहीं, कोई forbidden field नहीं) और state जाँचें: ऐसा 403 जिसके बावजूद change save हो गया, defect है।
  • Lists: B के लिए GET /v1/orders में A के orders नहीं होने चाहिए, ?customerId= जोड़ने पर भी नहीं।

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

Worked example: एक orders API

एक shop का orders API: customers सिर्फ़ अपने orders पढ़ और बदल सकते हैं; support agents कोई भी order पढ़ सकते हैं और refund जारी कर सकते हैं, पर कुछ बदल नहीं सकते; admins सब कुछ कर सकते हैं और सिर्फ़ वही users manage करते हैं। दूसरे customer का order 404 लौटाता है। Order 9021 customer A का है। Matrix के 20 cells में से सिर्फ़ 8 request की अनुमति देते हैं।

Orders API का access matrix: actor और request के 20 cells में से सिर्फ़ 8 allowed हैं; customer A के order 9021 की हर request पर customer B को 404 मिलता है, और users की list सिर्फ़ admin देख सकता है।
ActorR1 · order पढ़नाGET /v1/orders/9021R2 · पता बदलनाPATCH /v1/orders/9021R3 · order का refundPOST /v1/orders/9021/refundR4 · सभी users की listGET /v1/admin/users
Anonymoustoken नहीं401authentication401authentication401authentication401authentication
Customer Aorder 9021 का owner200allowed200allowed403function level403function level
Customer Bदूसरा customer404object level404object level404object level403function level
Support agent200allowed403function level201allowed403function level
Admin200allowed200allowed201allowed200allowed
  • Policy के अनुसार allowed, expected success code के साथ
  • Authorization से refused: role जिस function का इस्तेमाल नहीं कर सकता उस पर 403, दूसरे customer के order पर 404
  • Object-level (BOLA) cells: वही role, किसी और का order
  • Authentication से refused: valid credential नहीं, 401

Execution से पहले policy से लिखे गए expected results। Customers सिर्फ़ अपने orders पढ़ और बदल सकते हैं; support agents कोई भी order पढ़ सकते हैं और refund जारी कर सकते हैं, पर कुछ बदल नहीं सकते; admins सब कुछ कर सकते हैं और सिर्फ़ वही users manage करते हैं।

Test environment में इसे चलाने पर, एक बार में एक actor के token से, तीन defects मिले:

  • Customer B, R1: 404 की जगह A के पते के साथ 200। Object level, critical: कोई भी customer कोई भी order पढ़ सकता है।
  • Customer A, R3: 201, यानी A के अपने order का refund। Function level, critical: object का owner होना उस पर हर function की अनुमति नहीं देता, और यहाँ shop का पैसा बाहर जाता है।
  • Support agent, R2: उम्मीद के मुताबिक 403, लेकिन नए GET में नया पता दिखा। Function level, major: status ने refusal बताया, लेकिन change save हो गया। इसे सिर्फ़ state check ने पकड़ा।
पाठ संस्करण
Orders API, test environment. Order 9021 belongs to customer A.

R1  GET    /v1/orders/9021          read the order
R2  PATCH  /v1/orders/9021          change the delivery address
R3  POST   /v1/orders/9021/refund   refund the order
R4  GET    /v1/admin/users          list all user accounts

Actor                  R1    R2    R3    R4
anonymous (no token)   401   401   401   401
customer A (owner)     200   200   403   403
customer B             404   404   404   403
support agent          200   403   201   403
admin                  200   200   201   200

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

आम गलतियाँ

  • हर role के लिए एक ही account से टेस्ट करना, जिससे object-level tests असंभव हो जाते हैं।
  • यह मान लेना कि button छिपा है तो उसके पीछे का endpoint गलत role को reject करता है।
  • सिर्फ़ status code जाँचना, जिससे data बदल देने वाला refusal या दूसरे users के records वाली list भी pass हो जाती है।
  • IDs सिर्फ़ URL path में बदलना, query parameters, bodies, nested routes या list और export endpoints में नहीं।
  • Object-level tests इसलिए छोड़ देना कि ids random UUIDs हैं।
  • Production data, असली customer accounts या बिना लिखित अनुमति वाले किसी system पर टेस्ट करना।

QA का नज़रिया

Refinement के दौरान ही access policy माँगें, role × operation table के रूप में, endpoints बनने से पहले। Matrix के रूप में लिखी policy "क्या support agent payment details देख सकता है?" जैसे gaps तभी दिखा देती है जब उनका जवाब देना सस्ता है; फ़ैसला product owner करता है, और आप जवाबों को test cases में बदलते हैं।

तय करें कि हर environment में QA के पास कौन-से test accounts हैं: हर role के कम से कम दो, और ज़रूरत हो तो दो tenants। Actor, उसका role, object का owner, request, expected और actual status और state check लिखें, tokens mask करके। Personal या financial data खोलने वाला BOLA या function-level defect security defect है, और उसकी severity आम तौर पर critical होती है। Matrix को pipeline में data-driven API tests के रूप में automate करें, और सिर्फ़ वही systems टेस्ट करें जो आपके हैं या जिन्हें टेस्ट करने की लिखित अनुमति आपके पास है।

अभ्यास

Clinic API का authorization test log review करें

आपका काम

एक clinic API की policy: patients सिर्फ़ अपने appointments पढ़ और cancel कर सकते हैं और सिर्फ़ reason बदल सकते हैं; doctors अपने assigned appointments पढ़ते हैं और clinical notes जोड़ते हैं; receptionists सभी appointments पढ़ते और reschedule करते हैं, लेकिन clinical notes कभी नहीं देखते; staff accounts सिर्फ़ admins बनाते हैं। जो appointment caller नहीं देख सकता, उस पर 404 मिलता है।

Accounts: patients P1 और P2, doctor D1, receptionist RC1। Appointment 5531, P1 का है और D1 को assigned है। Test environment का यह log review करें।

सामग्री
Clinic API, test environment. Appointment 5531: patient P1, doctor D1.

#  Actor  Request                                Status  Observed
1  P1     GET /v1/appointments/5531              200     P1's appointment
2  P2     GET /v1/appointments/5531              200     P1's appointment
3  P2     POST /v1/appointments/5531/cancel      404     appointment unchanged
4  RC1    GET /v1/appointments/5531              200     body has "clinicalNotes"
5  P1     POST /v1/appointments/5531/notes       403     no note added
6  D1     POST /v1/staff {"role": "doctor"}      201     staff account created
7  P1     PATCH /v1/appointments/5531            200     doctor changed to D7
          {"reason": "follow-up", "doctorId": "D7"}
चरण
  1. Observed result पढ़ने से पहले policy से हर row का expected result लिखें।
  2. हर row को correct या defect mark करें, और हर defect का level बताएँ: function, object या property।
  3. Defects को severity के क्रम में रखें और सबसे गंभीर defect का bug title लिखें।
  4. Actor और request के ऐसे दो combinations बताएँ जो log में नहीं हैं।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Expected: 1 → 200; 2 → 404; 3 → 404, unchanged; 4 → 200, clinicalNotes के बिना; 5 → 403, 404 नहीं, क्योंकि P1 appointment देख सकता है; 6 → 403, कोई account नहीं; 7 → जैसा contract तय करे: या तो 400 और कुछ नहीं बदलता, या 200 जिसमें सिर्फ़ reason बदलता है और doctorId ignore होता है; दोनों हालात में doctor D1 ही रहता है। Rows 1, 3 और 5 सही हैं।

Critical: row 2, object level (BOLA, API1:2023), एक patient दूसरे patient का appointment पढ़ता है; row 6, function level (API5:2023), doctor staff accounts बनाता है।

Major: row 7, property level (mass assignment, API3:2023), patient doctor बदल देता है; row 4, property level (excessive data exposure, API3:2023), receptionist clinical notes देखता है, या critical जहाँ ये notes सबसे संवेदनशील data हैं।

Row 2 का bug title: "GET /v1/appointments/{id} 404 की जगह 200 के साथ दूसरे patient का appointment लौटाता है (P2, P1 का 5531 पढ़ता है)"।

Cover नहीं, उदाहरण के लिए: anonymous call (401); P2 के रूप में GET /v1/appointments, जिसमें 5531 नहीं होना चाहिए।

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

Refuse की गई request को 403 लौटाना चाहिए या 404?

दोनों सही हो सकते हैं। RFC 9110, 403 को ऐसी request के लिए परिभाषित करता है जिसे server समझ गया पर पूरा करने से मना करता है, और 404 की अनुमति देता है जब server यह ज़ाहिर नहीं करना चाहता कि resource मौजूद है। कई APIs दूसरे users के objects के लिए 404 लौटाते हैं ताकि ids टटोली न जा सकें। ज़रूरी यह है कि contract एक जवाब तय करे और API उस पर टिका रहे: मौजूद ids पर 403 और न मौजूद ids पर 404 देना attacker को बता देता है कि कौन-सी ids मौजूद हैं।

हमारी ids random UUIDs हैं। क्या फिर भी object-level tests चाहिए?

हाँ। Unpredictable ids का अंदाज़ा लगाना मुश्किल होता है, लेकिन ids shared links, logs, screenshots और दूसरे API responses से leak होती हैं। OWASP unpredictable ids की सलाह authorization check के साथ देता है, उसकी जगह नहीं: client से आई हर id पर server को जाँचना होगा कि caller उस object तक पहुँच सकता है।

Matrix बहुत तेज़ी से बड़ा होता है। क्या हर cell टेस्ट करना ज़रूरी है?

Risk के हिसाब से priority तय करें: पहले हर write operation, हर admin function, personal या financial data लौटाने वाला हर endpoint, और list, search और export endpoints। फिर matrix को data-driven tests के रूप में automate करें, हर actor और request के लिए data की एक row, ताकि नया endpoint या role सिर्फ़ rows जोड़े और पूरा matrix हर build पर चले।

Authorization testing security testing है या functional testing?

दोनों। Access policy एक functional requirement है, इसलिए उसकी जाँच रोज़ की API testing का हिस्सा है। Specialist penetration testers इससे आगे जाते हैं, लेकिन यह पता लगाने वाले पहले लोग वे नहीं होने चाहिए कि customer B, customer A का order पढ़ सकता है।

संदर्भ

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

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

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

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

API टेस्टिंग

REST API टेस्टर

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

API टेस्टिंग

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

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

API टेस्टिंग

OpenAPI → टेस्ट केस

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

ऑटोमेशन

JWT डिकोडर

JWT का हेडर और पेलोड डिकोड करें, क्लेम जाँचें और एक्सपायरी देखें — पूरी तरह आपके ब्राउज़र में।

सुरक्षा

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

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

API टेस्टिंग

और गहराई से

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

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