संवेदनशील मान की जगह लेने वाला टोकन और पहुँच की अनुमति देने वाला टोकन अलग काम करते हैं। उपयोग का दायरा और सर्वर पर अधिकारों की जाँच आवश्यक रहती है।
मान बदलने पर सभी जोखिम नहीं मिटते
टोकनाइज़ेशन संवेदनशील मान को दूसरे मान से बदलता है। प्रणाली प्रतिवर्ती या अपरिवर्तनीय हो सकती है और मैपिंग वॉल्ट का उपयोग कर भी सकती है या नहीं भी। टोकन से रिकॉर्ड जोड़ना या अनुमत कार्य करना संभव रह सकता है; इसलिए उसकी चोरी अनिवार्य रूप से हानिरहित नहीं है। छद्मनामकरण गुमनामी नहीं है: GDPR की शर्तें लागू होने पर डेटा व्यक्तिगत बना रहता है।
चैनल और हर कार्रवाई की सुरक्षा अलग जाँचें
TLS अपने समाप्ति बिंदुओं के बीच संचार सुरक्षित करता है; यह खराब प्राधिकरण या घुसपैठ किए गए सर्वर को ठीक नहीं करता। हस्ताक्षरित JWT अनिवार्य रूप से एन्क्रिप्टेड नहीं होता और उसका पेलोड पढ़ा जा सकता है। प्रोटोकॉल के अनुसार हस्ताक्षर, जारीकर्ता, लक्षित प्राप्तकर्ता और वैधता जाँचें, फिर ऑब्जेक्ट अधिकार देखें। OAuth के लिए RFC 9700 लें और संरचना के अनुसार अवधि, निरस्तीकरण व दोबारा उपयोग से सुरक्षा तय करें।
तीन तंत्र और सुरक्षा की सीमाएँ
| तंत्र | उद्देश्य | जाँचने की सीमा |
|---|---|---|
| डेटा टोकनाइज़ेशन | संवेदनशील मान बदलना। | मैपिंग, दोबारा पहचान और टोकन के संभव उपयोग। |
| एन्क्रिप्शन | कुंजियों से गोपनीयता सुरक्षित करना। | कुंजी प्रबंधन और डिक्रिप्शन के बाद खुलासा। |
| एक्सेस टोकन | सेवा के सामने अनुमति प्रस्तुत करना। | चुराया गया bearer token दोबारा इस्तेमाल हो सकता है; सर्वर पर अधिकार जाँचें। |
स्रोत और दायरा
- PCI SSC · Tokenization Product Security Guidelines · 2015 · pp. 6–8
- IETF · RFC 7519 · JSON Web Token · 2015
- IETF · RFC 9700 · OAuth 2.0 Security BCP · 2025
- EUR-Lex · GDPR / RGPD · Art. 4(5), recital 26
संपादकीय जाँच: 31 अक्टूबर 2026।
प्रोटेक्टेड डेटा को ऑथराइज़्ड एक्शन के साथ कन्फ्यूज़ न करें।
एन्क्रिप्शन और टोकनाइज़ेशन कुछ डेटा एक्सपोज़र को कम करते हैं लेकिन यह तय नहीं करते कि API कॉल किसी ऑब्जेक्ट को पढ़ सकता है या कोई ऑपरेशन ट्रिगर कर सकता है। OWASP ऑब्जेक्ट-लेवल और फ़ंक्शन-लेवल ऑथराइज़ेशन को बड़े API रिस्क में लिस्ट करता है।
- हर रिक्वेस्ट किए गए ऑब्जेक्ट और एक्शन पर परमिशन चेक करें, यहां तक कि ऑथेंटिकेटेड गेटवे के पीछे भी।
- डेमो डेटा के साथ क्रॉस-अकाउंट और क्रॉस-रोल रिक्वेस्ट को टेस्ट करें।
- सीक्रेट या सेंसिटिव वैल्यू को प्लेन टेक्स्ट में लॉग किए बिना इन्वेस्टिगेशन के लिए तैयार रिकॉर्ड रखें।
प्राथमिक स्रोत: OWASP API Security Top 10 — 2023. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
पासकी: डोमेन और RP ID बदलने की तैयारी
खाते, वेब ओरिजिन और RP ID को अलग रखें ताकि क्रेडेंशियल चुपचाप फिर न बाँधे जाएँ।
- पुराने तथा नए ओरिजिन, RP ID और जुड़े खाते लिखें। वही खाता नाम किसी पासकी को दूसरे RP ID के लिए वैध नहीं बनाता। WebAuthn के अनुमत संयोजन और बदलाव के दौरान उपलब्ध प्रवेश मार्ग जाँचें।
- अधिकृत परीक्षण वातावरण में उपयुक्त लाइब्रेरी से चैलेंज, ओरिजिन, RP ID और खाते का जुड़ाव जाँचें। अप्रत्याशित ओरिजिन और दोहराया चैलेंज आजमाएँ। RP ID बदले तो प्रमाणित नया पंजीकरण तैयार करें; डेटाबेस की पंक्ति कॉपी करना कुंजी का स्थानांतरण नहीं है।
- केवल पुराना क्रेडेंशियल रखने वाला उपयोगकर्ता, बहाली और खुले सत्र जाँचें। जाँची वापसी के साथ मार्ग खोलने और हटाने का क्रम तय करें। नए डोमेन पर पंजीकरण सफल होना सभी पुराने सत्रों का निरस्तीकरण साबित नहीं करता।
दोहराने योग्य स्वीकृति मामला
काल्पनिक उदाहरण: डेटा किसी ग्राहक या देखे गए परिणाम का नहीं है।
मामले के इनपुट देखें
{
"old_origin": "https://login.old.example",
"old_rp_id": "old.example",
"new_origin": "https://login.new.example",
"new_rp_id": "new.example",
"same_service_account": true,
"expected": "authenticated_new_registration"
}अपेक्षित निर्णय
काल्पनिक उदाहरण: खाता वही है, लेकिन old.example से अलग RP ID वाला new.example होता है। पुराने क्रेडेंशियल को चुपचाप नहीं बाँध सकते; नया पंजीकरण नियोजित प्रमाणित मार्ग से होना चाहिए।
क्या डेटाबेस संपादन पासकी का RP ID बदल सकता है?
नहीं। RP ID क्रेडेंशियल के सत्यापित दायरे का हिस्सा है। नए दायरे में वैध पंजीकरण और प्रमाणित खाता मिलान तैयार करें।
प्राथमिक स्रोत: W3C — Web Authentication Level 2. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
TLS नवीनीकरण: वास्तव में दिया प्रमाणपत्र जाँचें
बदलाव पूरा कहने से पहले नवीनीकरण को TLS अंत बिंदुओं और क्लाइंट तक जाँचें।
- नाम, CDN, लोड बैलेंसर, प्रॉक्सी और प्रमाणपत्र देने वाले आंतरिक कनेक्शन लिखें। दिया प्रमाणपत्र, चेन, समाप्ति और जिम्मेदार व्यक्ति दर्ज करें। जारी होना सभी नोड पर स्थापना साबित नहीं करता। निजी कुंजी सुरक्षित रखें और सूची में न डालें।
- उपलब्ध हो तो प्रदाता परीक्षण वातावरण में स्वचालन जाँचें। सत्यापन चुनौती, SAN नाम, सुरक्षित संग्रह और घटक पुनः लोड देखें। कुंजी नीति के अनुसार उपयोगी प्रमाणपत्र हो तो हर स्टार्ट पर जारी करने से बचें।
- समर्थित क्लाइंट और जरूरी मार्गों पर नाम, तारीख और विश्वास चेन जाँचें। TLS सत्यापन चालू रखें। केवल शेड्यूलर नहीं, दिए प्रमाणपत्र की समाप्ति देखें। वापसी में मान्य प्रमाणपत्र और सुरक्षित कुंजी जरूरी है; अन्यथा बिंदु सुधारें या अलग करें।
दोहराने योग्य स्वीकृति मामला
काल्पनिक उदाहरण: डेटा किसी ग्राहक या देखे गए परिणाम का नहीं है।
मामले के इनपुट देखें
{
"issuance_succeeded": true,
"proxy_count": 2,
"proxies_serving_expected_certificate": 1,
"other_proxy_certificate_expired": true,
"tls_verification_enabled": true,
"expected": "change_incomplete_fix_and_verify_client_paths"
}अपेक्षित निर्णय
काल्पनिक उदाहरण: नवीनीकरण सफल है पर दो प्रॉक्सी में एक समाप्त प्रमाणपत्र देता है। बदलाव अधूरा है; प्रॉक्सी सुधारें और TLS सत्यापन बंद किए बिना क्लाइंट मार्ग जाँचें।
प्राथमिक स्रोत: Let’s Encrypt — Integration Guide. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
संदर्भ: डेटा, उपयोग और सीमाएँ
दस्तावेज़ जाँच की तारीख .
इस संस्करण में विस्तृत संदर्भ टिप्पणियाँ अंग्रेज़ी में उपलब्ध हैं।
| स्रोत और उद्देश्य | सत्यापित डेटा या मानक | उपयोग कैसे करें | ध्यान में रखने योग्य सीमा |
|---|---|---|---|
| MITRE · Common Weakness Enumeration Name classes of software and hardware weakness. |
A CWE describes a weakness that can contribute to vulnerabilities. It does not represent a particular incident. | Connect the weakness to the observed mechanism: input, processing and missing control. Use it to fix the cause and plan regression tests. | A keyword in a report alone does not establish the correct CWE classification. |
| OASIS · TAXII 2.1 Exchange threat intelligence through an application protocol. |
TAXII 2.1 is an OASIS Standard dated 10 June 2021. It includes service discovery and access to collections. | Test authentication, collection permissions, pagination and recovery after interruption. Record which objects were actually received and processed. | TAXII transports data; it replaces neither the content model nor assessment of reliability. |
CISA KEV सूची देखें
इस संस्करण में विस्तृत संदर्भ टिप्पणियाँ अंग्रेज़ी में उपलब्ध हैं।
One identifier can span several technical layers
An entry may concern a library, server or component embedded in an appliance. Search the exact name, known dependencies and the distributed product’s advisory. Catalogue aliases are not a complete list of affected versions.
- Connect the CVE, component supplier and final-product supplier.
- Check version, configuration and execution path in the authorised environment.
- Do not infer remediation from an empty search result.
CISA KEV · 2026.11.06 · Documentary review : 2026-11-07
मीडिया: सैनिटाइज़ेशन और प्रमाण
इस संस्करण में विस्तृत संदर्भ टिप्पणियाँ अंग्रेज़ी में उपलब्ध हैं।
Encryption and erasure require different evidence
Encryption protects access while keys and implementation retain their properties. Cryptographic erase requires suitable encrypted scope and sanitization of relevant keys; it does not follow from API-token removal.
- Map data-encryption, wrapping and derivation keys and external copies.
- Check whether target sensitive data previously existed in plaintext.
- Record technical outcome, limits and validation without retaining secrets in the evidence.
Read the methods, evidence points and annotated situations →
NIST · SP 800-88 Rev. 2 · Guidelines for Media Sanitization · Final · 2025-09-26 · consulted 2026-10-23