TanodTools
HI

security.txt जेनरेटर और चेकर

RFC 9116 के अनुसार सही security.txt बनाएं ताकि शोधकर्ता जान सकें कि आपसे कैसे संपर्क करना है, या मौजूदा फ़ाइल पेस्ट करके देखें कि उसमें क्या गड़बड़ है। यूरोपीय संघ के साइबर रेज़िलिएंस एक्ट (CRA) की तैयारी का हिस्सा।

पूरी तरह आपके ब्राउज़र में चलता है

security.txt बनाएं

ज़रूरी
ईमेल पता, देश कोड के साथ फ़ोन नंबर, या https:// पेज। शोधकर्ता सबसे पहले पहली लाइन आज़माते हैं।
वैकल्पिक
आपकी भेद्यता प्रकटीकरण नीति। इसे यहाँ बनाएं।
आपकी पब्लिक की का https:// लिंक, कोई dns: रिकॉर्ड या openpgp4fpr: फ़िंगरप्रिंट।
कॉमा से अलग किए हुए भाषा कोड।
वह पता जहाँ से यह फ़ाइल परोसी जाएगी। सलाह दी जाती है, ख़ासकर साइन की हुई फ़ाइलों के लिए।
एक पेज जिस पर समस्याएँ बताने वाले शोधकर्ताओं का आभार माना जाता है।
आपकी सुरक्षा से जुड़ी नौकरियों का पेज।

    कहाँ रखें

    फ़ाइल को security.txt नाम से सेव करें और उसे https://your-domain/.well-known/security.txt पर HTTPS से सादे टेक्स्ट (text/plain; charset=utf-8) के रूप में परोसें। जिस भी डोमेन को कवर करना हो, वहाँ यही करें। साइन करने के लिए gpg --clearsign security.txt चलाएं और नतीजा प्रकाशित करें।

    security.txt जाँचें

    कोई डोमेन या पूरा पता। इससे जाँच होती है कि Canonical मेल खाता है या नहीं। कुछ भी लाया नहीं जाता।

      यह टेक्स्ट को सिर्फ़ RFC 9116 के हिसाब से जाँचता है। यह आपकी वेबसाइट से फ़ाइल नहीं लाता (आप जो लिखते हैं वह इस पेज से बाहर नहीं जाता, इसलिए फ़ाइल पेस्ट करें), OpenPGP सिग्नेचर को वेरिफ़ाई नहीं करता, और किसी पते के चालू होने की जाँच भी नहीं करता। यह एक टेम्पलेट है, कानूनी सलाह नहीं।

      security.txt कैसे बनाएं और जाँचें

      1. कम से कम एक Contact (ईमेल पता, फ़ोन नंबर या https:// पेज) लिखें और Expires तारीख़ देख लें। Policy और Preferred-Languages जैसे जो वैकल्पिक फ़ील्ड चाहें, भरें।
      2. फ़ाइल कॉपी करें या डाउनलोड करें, और उसे अपने डोमेन पर HTTPS से, सादे टेक्स्ट के रूप में /.well-known/security.txt पर प्रकाशित करें।
      3. मौजूदा फ़ाइल जाँचने के लिए उसका टेक्स्ट चेकर में पेस्ट करें। पहले त्रुटियाँ ठीक करें, फिर चेतावनियाँ देखें। Canonical फ़ील्ड जाँचने के लिए वह पता भी डालें जहाँ से आप फ़ाइल परोसते हैं।
      4. Expires की तारीख़ बीतने से पहले नवीनीकरण का रिमाइंडर अपने कैलेंडर में लगा लें।

      security.txt किसलिए है

      जब कोई शोधकर्ता, ग्राहक या CERT आपके सॉफ़्टवेयर में कोई कमज़ोरी पाता है, तो पहली दिक़्क़त यह होती है कि बताएं किसे। security.txt एक छोटी टेक्स्ट फ़ाइल है जो तय पते /.well-known/security.txt पर रखी जाती है और इसका जवाब देती है: एक संपर्क, एक समाप्ति तारीख़ और, चाहें तो, आपकी प्रकटीकरण नीति और पब्लिक की का लिंक। फ़ॉर्मैट RFC 9116 में तय है, और कई स्कैनर, bug bounty प्लेटफ़ॉर्म और राष्ट्रीय CERT कुछ और देखने से पहले यही फ़ाइल खोजते हैं।

      यूरोपीय संघ के किसी सॉफ़्टवेयर विक्रेता के लिए यह साइबर रेज़िलिएंस एक्ट (CRA) के तहत उसकी ज़िम्मेदारियों में भी मदद करती है: Annex I में बाहरी लोगों के लिए भेद्यताओं की रिपोर्ट करने का प्रकाशित तरीक़ा और उन्हें सँभालने की प्रक्रिया अपेक्षित है। विनियमन इस फ़ॉर्मैट का नाम नहीं लेता, पर संपर्क प्रकाशित करने का आम तरीक़ा यही है। बाक़ी सेटअप, 24 घंटे की घड़ी समेत, छोटे विक्रेताओं के लिए रिपोर्टिंग गाइड में है।

      फ़ील्ड

      Contact और Expires ज़रूरी हैं। Contact कई बार आ सकता है और उसे URI होना चाहिए: mailto:, tel: या https:। Expires एक ही बार आता है, 2027-12-31T23:59:59Z जैसी तारीख़ और समय के रूप में, और RFC 9116 के अनुसार वह एक साल से कम आगे का होना चाहिए। Encryption, Acknowledgments, Policy, Hiring और Canonical वैकल्पिक लिंक हैं, और हर वेब पता https वाला होना चाहिए। Preferred-Languages एक ही बार आता है और उसमें भाषा कोड की सूची होती है। जो फ़ील्ड RFC में परिभाषित नहीं हैं, उन्हें पाठक अनदेखा कर देते हैं, इसलिए चेकर उन्हें चेतावनी के रूप में दिखाता है: आमतौर पर वे टाइपो होते हैं।

      सुझाव

      • ऐसा मेलबॉक्स रखें जिसे कई लोग पढ़ें, किसी एक व्यक्ति का पता नहीं, और उसे खुद लिखकर आज़माएं।
      • एक भेद्यता प्रकटीकरण नीति लिखें और उसे Policy फ़ील्ड से जोड़ें।
      • रिपोर्ट आने से पहले अपनी समय-सीमाएँ जान लें: CRA 24-घंटे इंसिडेंट क्लॉक आपके जानने के समय को तारीख़ वाली समय-सीमाओं में बदल देती है।

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

      क्या साइबर रेज़िलिएंस एक्ट (CRA) में security.txt ज़रूरी है?

      नहीं। विनियमन चाहता है कि निर्माताओं के पास समन्वित भेद्यता प्रकटीकरण (CVD) की नीति हो और भेद्यताओं की रिपोर्ट करने का कोई प्रकाशित तरीक़ा हो। security.txt उस संपर्क को प्रकाशित करने का आम तरीक़ा है और विशेषज्ञ इसकी सलाह देते हैं, लेकिन विनियमन में इस फ़ॉर्मैट का नाम नहीं है। छोटे विक्रेताओं की गाइड देखें।

      फ़ाइल ठीक-ठीक कहाँ रखनी है?

      https://your-domain/.well-known/security.txt पर, HTTPS से और कंटेंट टाइप text/plain; charset=utf-8 के साथ। पुराने सेटअप के लिए RFC 9116 /security.txt पर एक कॉपी रखने की भी इजाज़त देता है। इसे हर उस डोमेन या सबडोमेन पर प्रकाशित करें जिसे आप कवर करना चाहते हैं।

      Expires कितनी दूर की तारीख़ पर रखें?

      RFC 9116 के अनुसार यह एक साल से कम आगे की होनी चाहिए, ताकि शोधकर्ता भरोसा कर सकें कि संपर्क की जानकारी अद्यतन रखी जाती है। जेनरेटर डिफ़ॉल्ट रूप से एक साल से थोड़ा कम रखता है। तारीख़ बीतने पर पाठकों को फ़ाइल अनदेखी करने को कहा जाता है, इसलिए समय रहते उसका नवीनीकरण करें।

      क्या फ़ाइल पर PGP से साइन करना ज़रूरी है?

      नहीं, साइन करना वैकल्पिक है, पर सलाह दी जाती है। साइन की हुई फ़ाइल OpenPGP क्लियरटेक्स्ट-साइन्ड संदेश होती है, जो gpg --clearsign security.txt से बनती है। चेकर साइन्ड फ़ॉर्मैट पहचानता है और उसकी बनावट जाँचता है, पर सिग्नेचर खुद वेरिफ़ाई नहीं कर सकता; उसके लिए gpg --verify इस्तेमाल करें।

      चेकर मेरी साइट से फ़ाइल क्यों नहीं लाता?

      ताकि पेज निजी रहे: यह पूरी तरह आपके ब्राउज़र में चलता है और दूसरी साइटों को कोई अनुरोध नहीं भेजता। अपनी फ़ाइल ब्राउज़र के एक टैब में खोलें, टेक्स्ट कॉपी करें और यहाँ पेस्ट करें। इससे यह भी जाँच हो जाती है कि आगंतुकों को असल में क्या मिलता है।

      Canonical फ़ील्ड किसलिए है?

      इसमें वे पते लिखे जाते हैं जहाँ से फ़ाइल परोसी जानी है, ताकि पाठक पक्का कर सकें कि किसी पते पर मिली फ़ाइल सच में वहीं की है। अगर आप वह पता डालते हैं जहाँ से फ़ाइल परोसते हैं, तो चेकर जाँचता है कि आपकी कोई Canonical लाइन उससे मेल खाती है या नहीं।