किसी scanner, pentest report या customer की security questionnaire ने पूछा है कि आप जो JavaScript ship करते हैं वह पढ़ने योग्य है या नहीं, और आपको जवाब चाहिए।
एक automated scanner वास्तव में क्या जाँचता है
Scanner आपका code उस तरह नहीं पढ़ता जैसे एक इंसान पढ़ता है। वह response से जो भी text निकाल सकता है, उस पर जाँचों का एक तय सेट चलाता है: वह आपके string literals में secret जैसे दिखने वाले patterns खोजता है, sourceMappingURL comment मौजूद हो तो उसके सहारे आपके मूल source तक पहुँचता है, आपके bundle की गई libraries के versions का fingerprint लेता है, और फ़ाइल को plain text या minified का label देता है।
इनमें से किसी के लिए आपके logic को समझना ज़रूरी नहीं है। Pattern match किसी key को ढूँढ लेता है, चाहे आसपास का code कभी चले या नहीं। एक source map किसी scan को एक ही request में पूरे source को पढ़ने में बदल देता है। रिपोर्ट पढ़ने वाला व्यक्ति label देखता है, और plain या minified label उसे बताता है कि source वहीं मौजूद है।
एक obfuscated build रिपोर्ट में क्या बदलती है
Literals डिफ़ॉल्ट रूप से encode होते हैं, इसलिए secret-pattern जाँच जिस text को खोजती है वह फ़ाइल में नहीं होता। strings.leaks.max किसी readable literal के बच जाने पर build को fail कर देता है, और DIAG_SURVIVING_READABLE_LITERAL के साथ उसका नाम बताता है। एक production build कोई .map फ़ाइल और कोई sourceMappingURL comment तब तक नहीं लिखती जब तक आप sourceMap.enabled और sourceMap.emitUrl से उन्हें न माँगें, इसलिए source तक वापस ले जाने वाला कोई map नहीं होता।
Protection-level जाँच फिर भी फ़ाइल को obfuscated के रूप में रिपोर्ट करती है, और वह जाँच इसी के लिए है। Output का आकार उसे देखने वाले हर व्यक्ति को दिखता है; आपका logic और आपकी strings वे हिस्से हैं जो पढ़ने योग्य नहीं रहते।
एक release build जो questionnaire का जवाब देती है
एक release build जो अपनी strings encode करती है और map को output से बाहर रखती है:
{
"preset": "hard",
"strings": {
"encode": true,
"leaks": { "max": 0 }
},
"sourceMap": { "enabled": false }
}Production build में sourceMap.enabled पहले से बंद होता है। इसे यहाँ सेट करने से हर उस मशीन पर जवाब एक जैसा रहता है जो build चलाती है।
पहले अपने deployment को scan करें
Customer से पहले, वे जाँचें अपने deployment पर चलाएँ जो एक scanner चलाता है:
$ npx afterpack@latest audit https://your-site.example.comafterpack audit पहले exposed secrets और source maps खोजता है, फिर protection level, ख़तरनाक patterns, पहचाना गया stack, और जिनका वह fingerprint ले सकता है उनमें known CVEs। Pipeline के लिए --diagnostics.format=json जोड़ें ताकि result को scrape करने के बजाय parse किया जा सके, और --diagnostics.level से चुनें कि कितना detail वापस आए। इसे हर उस environment पर चलाएँ जिसमें आप deploy करते हैं, staging सहित।
Local रूप से protectionMap.enabled चालू रखें। Protection Map audit में मिली किसी भी चीज़ को उस source region तक trace करता है जहाँ से वह आई।
साफ़ scan का क्या मतलब नहीं है
अपनी site को audit करने से पता चलता है कि कोई भी reader उससे पहले से क्या निकाल सकता है, और encoded literals वाली और बिना shipped map वाली build में उस source की तुलना में कहीं कम पढ़ने योग्य text होता है जिससे वह build हुई।
Obfuscation, scan में मिली चीज़ को ठीक नहीं करती। एक vulnerable dependency, एक injection bug, या एक credential जो पहले ही बाहर जा चुका है, build के बाद भी चल रहे application में मौजूद रहता है, इसलिए उन्हें source पर ठीक करें और credential को rotate करें।
आगे
- Audit: command reference और results को कैसे पढ़ें।
- Threat model: एक static reader और आपका code चलाने वाले व्यक्ति के बीच की सीमा।
- Diagnostics: हर code जो एक build या audit emit कर सकता है।