केवल HTTPS इस्तेमाल करने से API GDPR के अनुरूप नहीं हो जाती। लागू होने का दायरा, प्रसंस्करण का उद्देश्य और कानूनी आधार तय करें तथा डेटा व पहुँच को आवश्यकता तक सीमित रखें।
क्षेत्रीय दायरा और कानूनी आधार
अनुच्छेद 3 में अन्य स्थितियों के साथ संघ में किसी प्रतिष्ठान की गतिविधियों के संदर्भ में प्रसंस्करण और निर्धारित शर्तों पर संघ में मौजूद लोगों को वस्तुएँ या सेवाएँ देना अथवा उनके व्यवहार की निगरानी शामिल है। केवल नागरिकता या यूरोपीय निवास से पूरा दायरा स्पष्ट नहीं होता। सहमति अनुच्छेद 6 का एक आधार है, अकेला नहीं; विशेष श्रेणी के डेटा पर अनुच्छेद 9 की अतिरिक्त शर्तें हैं।
जाँच योग्य नियंत्रण और जिम्मेदारी
कॉलर की पहचान सत्यापित होने से हर रिकॉर्ड पढ़ने की अनुमति नहीं मिलती। हर ऑब्जेक्ट और कार्रवाई के अधिकार जाँचें, लौटाए गए फ़ील्ड घटाएँ और परिवहन सुरक्षित रखें। लॉग में रहस्य या अनावश्यक व्यक्तिगत डेटा न लिखें। नियंत्रक, प्रोसेसर, संग्रह अवधि, अधिकार और अंतरराष्ट्रीय हस्तांतरण स्पष्ट करें। संभावित उच्च जोखिम वाले प्रसंस्करण में अनुच्छेद 35 के अनुसार प्रभाव आकलन आवश्यक है।
ताज़ा स्थिति: वार्ता का अधिकार और लागू कानून अलग हैं
21 अक्टूबर 2026 को यूरोपीय संघ की परिषद ने डेटा संरक्षण नियमों सहित Digital Omnibus पर अपनी वार्ता स्थिति घोषित की। वार्ता का अधिकार अंतिम विधायी स्वीकृति नहीं है। केवल इस घोषणा से मौजूदा दायित्व प्रस्तावित संशोधनों में नहीं बदल जाते।
घटना की तैयारी
- प्रसंस्करण दस्तावेज़ और नियंत्रण के प्रमाण अद्यतन रखें।
- नियंत्रक उल्लंघन की जानकारी मिलने पर अनुचित देरी के बिना और संभव हो तो 72 घंटे में प्राधिकरण को सूचित करता है, जब तक अधिकारों व स्वतंत्रताओं को जोखिम होने की संभावना कम न हो (अनुच्छेद 33)।
- प्रोसेसर नियंत्रक को अनुचित देरी के बिना सूचित करता है; लॉग सुरक्षित रखें और संग्रह अवधि सीमित करें।
स्रोत और दायरा
- EUR-Lex · GDPR / RGPD · 2016/679 · Art. 3, 5, 6, 9, 25, 28, 32, 33, 35, 44–49
- CNIL · API · 2023
- OWASP · API1:2023 · Broken Object Level Authorization
- Council of the EU · Digital Omnibus · 21 October 2026
- CNIL · Art. 33
संपादकीय जाँच: 31 अक्टूबर 2026।
फ़ील्ड के हिसाब से डेटा एक्सपोज़र को लिमिट करें।
एक डेटा प्रोटेक्शन पॉलिसी को यह पहचानने की ज़रूरत है कि कौन से फ़ील्ड सिस्टम से बाहर जा सकते हैं। GraphQL में, एक ऑपरेशन कई तरह के फ़ील्ड को मिला सकता है; हर रिज़ॉल्वर को मकसद और परमिशन लागू करनी चाहिए।
- उन सेंसिटिव फ़ील्ड और रोल की इन्वेंटरी बनाएं जिनकी उन्हें ज़रूरत है।
- बिना इजाज़त वाले अकाउंट के साथ लिस्ट और नेस्टेड ऑब्जेक्ट को टेस्ट करें।
- लॉग में रखे गए आर्गुमेंट और रिज़ल्ट कम करें।
प्राथमिक स्रोत: OWASP — GraphQL Cheat Sheet. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
ZIP और TAR: निर्देशिका और संसाधन सीमा में निकालें
निकाली फ़ाइलों को प्रकाशित करने से पहले पथ, लिंक और वास्तविक विस्तार जाँचें।
- न्यूनतम अनुमति वाली नई गैर-सार्वजनिक निर्देशिका में निकालें। पूर्ण पथ, ऊपर जाने वाले पथ, अनावश्यक लिंक और विशेष फ़ाइलें अस्वीकार करें। वास्तविक समाधान किए लक्ष्य और नाम टकराव को लक्ष्य सिस्टम, अक्षर केस सहित, जाँचें। टेक्स्ट उपसर्ग अकेले सीमा साबित नहीं करता।
- लिखे बाइट, प्रविष्टि संख्या, गहराई, समय और प्रक्रिया संसाधन पर प्रति फ़ाइल और कुल सीमा रखें। केवल संपीड़ित या घोषित आकार न मानें। अनावश्यक नेस्टेड अभिलेख अस्वीकार करें; जरूरी हों तो सभी स्तर कुल बजट साझा करें। लाइब्रेरी और फ़िल्टर अद्यतन रखें।
- ../, पूर्ण पथ, लिंक, दोहराव और बजट अधिकता जाँचें। रुकावट में बैच प्रकाशित न हो और पुरानी फ़ाइल न बदले। प्रकार और सामग्री जाँचकर प्रकाशित करें; अलग निर्देशिका साफ करते समय लक्ष्य सत्यापित करें।
दोहराने योग्य स्वीकृति मामला
काल्पनिक उदाहरण: डेटा किसी ग्राहक या देखे गए परिणाम का नहीं है।
मामले के इनपुट देखें
{
"compressed_mb": 2,
"expanded_mb": 600,
"aggregate_budget_mb": 100,
"first_files_valid": true,
"expected": "stop_on_actual_overrun_and_do_not_promote"
}अपेक्षित निर्णय
काल्पनिक उदाहरण: 2 MB संपीड़ित डेटा 600 MB बनता है और बजट 100 MB है। वास्तव में लिखे बाइट अधिक होते ही रोकें; पहली फ़ाइलें सही दिखें तब भी बैच प्रकाशित न करें।
Python — tarfile extraction filters and further verification
क्या छोटा अभिलेख या फ़िल्टर सुरक्षा देता है?
नहीं। बहुत विस्तार हो सकता है। संसाधन सीमाएँ, पथ नियम और निकाली फ़ाइलों का सत्यापन जोड़ें।
प्राथमिक स्रोत: Python — tarfile extraction filters and further verification. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
