संवेदनशील डेटा एक्सपोज़र

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

Product के लिए leak अक्सर पूरा breach ही होता है: session tokens से भरा access log, या हर customer का phone number किसी भी signed-in user को लौटाने वाला list endpoint, किसी exploit chain के बिना ही काफ़ी है। Personal data का क़ानूनी वज़न भी है। सऊदी अरब का Personal Data Protection Law (PDPL) test environments और log files में process होते personal data पर उतना ही लागू होता है जितना production में, और माँग करता है कि collect किया गया data purpose की न्यूनतम ज़रूरत तक सीमित रहे; जो field कोई इस्तेमाल नहीं करता, वह feature नहीं, liability है।

Tester के लिए ये सबसे आसानी से मिलने वाले security defects में से हैं: कोई attack tools नहीं, सिर्फ़ वह पढ़ना जो application पहले से भेजती और store करती है, और जो functional tester हर दिन देखता है। Tester खुद भी exposure का source हो सकता है, screenshots, bug reports और production से copy किए test data के ज़रिए, इसलिए यह lesson exposure को बिना पैदा किए ढूँढने के बारे में है।

क्या sensitive गिना जाता है, और encoding सुरक्षा क्यों नहीं है

शुरुआत data का नाम लेकर करें। लगभग हर product में चार classes मायने रखती हैं, हर एक का अपना rule है कि वह कहाँ दिख सकती है, और वे आपस में overlap करती हैं: password-reset link एक secret है, और जिस e-mail address पर वह भेजा गया वह personal data है।

Class चाहे जो हो, encoding सुरक्षा नहीं है। Base64, percent-encoding, hex और JWT का payload, जिसके पास string है वह सब उलटकर पढ़ सकता है, जैसा Base64 Decoder और JWT Decoder एक सेकंड में दिखा देते हैं। Data को सिर्फ़ ऐसी key से encryption बचाता है जो पढ़ने वाले के पास न हो, या passwords के लिए one-way hash; अगला lesson, cryptography basics, यह फ़र्क़ समझाता है। Masking display का rule है, सुरक्षा नहीं: **** 4242 तभी safe है जब server पूरा number कभी भेजे ही नहीं।

• Credentials और secrets: passwords, session identifiers, access और refresh tokens, reset और verification codes, API keys, private keys। Rule: enter या issue होने के बाद दोबारा कभी display नहीं, कभी log नहीं; URL में भी नहीं, सिवाय random, single-use और short-lived token के, जैसे e-mail से भेजे reset link का token।
• Personal data: जो भी किसी व्यक्ति की पहचान कराए या उसका वर्णन करे — phone या e-mail के साथ नाम, national ID या iqama number, जन्मतिथि, पता, location, photos। PDPL एक सख़्त class, sensitive data, define करता है, जिसमें health data, genetic और biometric data, और ethnic origin या धार्मिक आस्था बताने वाला data शामिल है। Rule: सिर्फ़ उस व्यक्ति या authorised role को, और सिर्फ़ वे fields जो screen को चाहिए।
• Payment data: card number, expiry date, card verification code, IBAN। Rule: number हर जगह masked, verification code कभी store या return नहीं।
• Internal details: stack traces, SQL text, file paths, internal hostnames और IP addresses, software versions, debug flags। Rule: user को generic message, details reference id के साथ server log में।

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

Data कहाँ leak होता है: URLs, responses, error messages और logs

URLs share करने के लिए बने हैं, और ठीक इसी वजह से RFC 9110 उनमें sensitive information रखने से बचने की सलाह देता है। GET request की query string browser history और bookmarks में, web server, load balancer और CDN के access logs में, analytics, support screenshots और page पर मौजूद हर third-party script तक, जो पूरा address पढ़ सकती है, और Referer header के ज़रिए दूसरी sites तक copy होती है, अगर page की Referrer-Policy पूरा URL भेजने देती है। इसलिए links, filters और e-mail के buttons में ?sessionId=, ?email= और ?nationalId= HTTPS पर भी leaks हैं, क्योंकि HTTPS connection बचाता है, copies नहीं। Personal data और secrets की जगह request body या header है; आम तौर पर स्वीकार्य अपवाद एक random, single-use और short-lived token है, जैसे reset या confirmation link का token, जो ऐसे page पर खुले जो Referrer-Policy: no-referrer भेजता है।

Responses तब leak करते हैं जब server view की जगह पूरा object लौटा देता है। Profile screen एक नाम दिखाती है, लेकिन /api/users/42 में passwordHash, otpSecret, nationalId और isAdmin हैं; list endpoint हर customer का phone किसी भी signed-in user को देता है; JavaScript bundle में API key चली जाती है; personal data वाला response बिना Cache-Control: no-store के browser cache में रह सकता है, जैसा HTTP caching का lesson समझाता है। Check हमेशा raw body का होता है, screen का नहीं।

Error messages internals leak करते हैं। Stack trace वाला 500 page, SQL text वाला database error, file path, framework version या test में on छोड़ा गया debug page attacker को ठीक-ठीक बताता है कि क्या आज़माए, और एक address पर "user not found" और दूसरे पर "wrong password" कहने वाला login confirm कर देता है कि कौन-से accounts मौजूद हैं। User को reference id के साथ generic message दिखना चाहिए; detail की जगह server log है।

Logs चुपचाप leak करते हैं। पूरे request bodies log करने वाली application उसे भेजा गया हर password और card number log करती है; access logs पहले paragraph का हर URL रखते हैं; error trackers, analytics और crash reporters copies पाने वाले third parties हैं; और chat और tickets में paste किए log snippets और आगे जाते हैं। OWASP Logging Cheat Sheet ऐसे data की list देता है जिसे logs से बाहर रखना है, जिनमें passwords, session identifiers, access tokens, encryption keys, payment card data और health data व government identifiers जैसा sensitive personal data शामिल हैं।

आज़माएँ: URL पार्सर

Data minimisation: हर field के पीछे का सवाल

Data minimisation का मतलब है सिर्फ़ वही data collect, process, show और रखना जो बताए गए purpose को चाहिए। PDPL इसकी माँग करता है, GDPR इसे एक principle का नाम देता है, और exposure के ख़िलाफ़ यह सबसे मज़बूत बचाव है, क्योंकि जो data system के पास है ही नहीं वह leak नहीं हो सकता। Tester के लिए यह हर field का एक सवाल बन जाता है, जो चार जगहों पर पूछा जाता है।

• Collection: क्या form ऐसा data माँगता है जो feature को नहीं चाहिए, जैसे newsletter के लिए जन्मतिथि? हर extra field एक test condition और product owner के लिए सवाल है।
• Return: क्या response का हर field इस role की किसी screen पर दिखता है? Raw JSON की UI से तुलना करें, list, search, export और "me" endpoints समेत, जो आम तौर पर सबसे चौड़े होते हैं।
• Logging: application कौन-से fields अपने logs में लिखती है, और कौन-से masked हैं? Developer से पूछें, फिर अपनी test values से verify करें।
• Retention: user के account delete करने के बाद क्या data अब भी search, exports और logs के backups में दिखता है? क्या test environment में production data की copy है ही? PDPL के तहत वह copy process होता personal data है; synthetic data default है, जैसा database testing guide समझाता है।

Worked example: एक order-tracking API

एक delivery app के test plan में उसके नए order tracking का exposure check है, जिसका scope security lead ने लिखित में confirm किया: test environment, tester के अपने test customer और test courier accounts, सिर्फ़ harmless inputs। Customers को tracking link SMS से मिलता है, और tracking page और mobile app दोनों GET /api/orders/{id} call करते हैं।

Link है https://track.shop.example/t?order=1042&phone=0551234567: GET URL में एक phone number, जो SMS provider के logs, browser history और tracking page में embedded map provider की script तक copy होता है, जो पूरा address पढ़ सकती है। नीचे का response, raw JSON की तरह पढ़ने पर, पूरा card number और verification code, customer का national ID, courier के घर का पता, एक internal note और एक database host ले जाता है, जिनमें से कुछ भी tracking screen नहीं दिखाती, और उसमें Cache-Control header नहीं है। /api/orders/abc एक 500 देता है जिसके body में file path और SQL text है। आख़िर में एक developer, जिससे पूछा गया कि API क्या log करती है, application log की एक line paste करता है जिसमें पूरा POST /login body है, password समेत।

Tester हर value masked करके severity के क्रम में report करता है: पहले response में card data, क्योंकि payment authorise होने के बाद verification code रखा ही नहीं जाना चाहिए, और log में password, जिसे logs तक पहुँच रखने वाला हर कोई पढ़ सकता है; फिर URL में phone number, national ID, courier का पता और internal note, error body में SQL text और file path, और गायब Cache-Control: no-store। Severity security team के साथ तय होती है, और fix हर उस जगह confirm होता है जहाँ data दिखा था, सिर्फ़ tracking screen पर नहीं।

GET /api/orders/1042 HTTP/1.1
Host: api.test.shop.example
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiI3NzMxIn0.x

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 1042,
  "status": "out_for_delivery",
  "customer": { "name": "Test Customer", "phone": "0551234567",
                "nationalId": "1098765432" },
  "payment": { "card": "4242424242424242", "expiry": "12/27", "cvv": "123" },
  "courier": { "name": "Test Courier", "phone": "0509876543",
               "homeAddress": "Al Olaya, Riyadh" },
  "internal": { "note": "complained twice", "dbHost": "10.0.3.12" }
}

GET /api/orders/abc HTTP/1.1
Host: api.test.shop.example

HTTP/1.1 500 Internal Server Error
Content-Type: application/json

{ "error": "invalid input syntax for type integer: \"abc\"",
  "query": "SELECT * FROM orders WHERE id = 'abc'",
  "at": "/srv/app/src/orders/service.ts:88" }

आज़माएँ: JSON ट्री व्यूअर

Exposure को safely कैसे test करें

Exposure testing पढ़ना है, attack करना नहीं: आप देखते हैं कि application आपके अपने test accounts के लिए क्या भेजती और store करती है, ऐसे system में जो आपका है या जिसे test करने की लिखित permission आपके पास है। असली customer data कभी test data नहीं होता; ग़लती से मिल जाए तो रुकें, copy न करें और अपने lead को बताएँ। Evidence values masked करके रखें, जैसे 05512*****।

• Inventory: requirements और data model से feature के sensitive fields लिखें, और हर एक के लिए कौन देख सकता है और वह कहाँ दिख सकता है: screen, API, log, export, e-mail, SMS।
• URLs: Network panel को ? से filter करके हर flow चलें, हर e-mail और SMS link खोलें और संदिग्ध URLs parse करें। Expected: किसी query string में personal data, passwords, session identifiers या keys नहीं, और e-mail link में सिर्फ़ single-use, short-lived token।
• Responses: हर उस endpoint के लिए जिसे कोई screen call करती है, raw body पढ़ें और हर वह field mark करें जो screen नहीं दिखाती; यही list, search, export और "me" endpoints, HTML source और JavaScript bundles के लिए दोहराएँ।
• Errors: हर input type के लिए एक malformed value, एक missing required field और एक unsupported method भेजें, और 4xx व 5xx bodies पढ़ें; login, registration और reset को मौजूद और अनजान accounts के लिए एक जैसा जवाब देना चाहिए।
• Logs और third parties: developer के साथ test environment के application और access logs में अपनी test values regular expression से खोजें, और लिखें कि कौन-से error trackers और analytics requests पाते हैं।
• Client side: personal data वाले responses पर Cache-Control: no-store, Referrer-Policy header, local और session storage की सामग्री, और browser console क्या print करता है।

आज़माएँ: Regex टेस्टर आज़माएँ: AI API रिस्पॉन्स रिस्क एनालाइज़र

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

संदर्भ

• OWASP Top 10:2025OWASP Foundation · 2025वेब एप्लिकेशन की दस सबसे गंभीर सुरक्षा जोखिम, हर एक की जाँच और रोकथाम के साथ।
• OWASP API Security Top 10 (2023)OWASP Foundation · 2023API की दस सबसे आम कमज़ोरियाँ: ऑब्जेक्ट-लेवल ऑथराइज़ेशन का टूटना, ऑथेंटिकेशन का टूटना, अनियंत्रित रिसोर्स खपत और अन्य।
• OWASP Cheat Sheet Series: LoggingOWASP Foundationक्या लॉग करें और क्या कभी न करें (पासवर्ड, टोकन, निजी डेटा), और लॉग को छेड़छाड़-प्रकट कैसे रखें।
• Personal Data Protection Law (English translation)सऊदी डेटा एवं AI प्राधिकरण (SDAIA) · 2023व्यक्तिगत डेटा पर सऊदी कानून — टेस्ट वातावरण में असली ग्राहक रिकॉर्ड की प्रतियों के बजाय सिंथेटिक डेटा क्यों इस्तेमाल करना चाहिए।