मॉड्यूल 17 · सिक्योरिटी टेस्टिंग

इनपुट वैलिडेशन और आउटपुट एन्कोडिंग

Mutqan Soft QA टीम द्वारा · · 22 मिनट · मध्यम

Input validation application में आने वाली हर value को उसके field के rules से जाँचती है और जो fit नहीं होता उसे server पर, value के इस्तेमाल से पहले, reject कर देती है। Output encoding stored value को उस जगह के लिए सुरक्षित रूप में बदलती है जहाँ वह लिखी जाती है, ताकि browser, URL parser या database उसे data माने, code कभी नहीं: HTML page में < बनता है &lt;, URL में space बनता है %20, और database को value query parameter के रूप में मिलती है।

उदाहरण: O'Brien & Sons नाम का customer valid input है जिसे किसी rule को reject नहीं करना चाहिए। Apostrophe और ampersand सिर्फ़ exit पर ख़तरनाक बनते हैं, अगर page या query text जोड़कर बनाई गई हो। Validation तय करती है कि अंदर क्या आए; encoding तय करती है कि वह बाहर कैसे लिखा जाए। Application को दोनों चाहिए, और tester दोनों जाँचता है।

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

Injection और cross-site scripting (XSS), जिन्हें अगले दो lessons विस्तार से टेस्ट करते हैं, एक ही root cause साझा करते हैं: बाहर से आई value database, shell या browser जैसे interpreter तक पहुँचती है और code की तरह चल जाती है। Injection OWASP Top 10:2025 की categories में से एक है और इसमें XSS शामिल है, और इसे रोकने वाले दो controls यही हैं: जो अंदर आए उसे validate करो, जो बाहर जाए उसे encode करो। एक unchecked entry point या एक unencoded output काफ़ी है।

Tester के लिए यह उपजाऊ ज़मीन है, क्योंकि defects layers के बीच की दरारों में छिपते हैं: form validate करता है पर API नहीं, list page encode करता है पर export नहीं। साफ़-सुथरी values वाले functional tests उन दरारों तक कभी नहीं पहुँचते। कुछ harmless marker values, हर entry point से हर उस जगह तक ले जाई गईं जहाँ value दिखती है, उन्हें मिनटों में पकड़ लेती हैं, बिना attack tools के, उन systems पर जिन्हें टेस्ट करने की आपको अनुमति है।

Input validation: allow-list rules, server पर लागू

OWASP Input Validation Cheat Sheet हर value पर दो checks माँगती है: उसका syntax, यानी अपेक्षित type और format (type, length, range, format, किसी तय set में होना), और उसकी semantics, यानी value उस operation के लिए समझ में आती है या नहीं: visit date बीते समय की नहीं, quantity stock से ज़्यादा नहीं। Testers इन्हें आम तौर पर syntactic और semantic validation कहते हैं। Rules allow-lists के रूप में लिखे जाते हैं: जो स्वीकार है वह तय करें और बाक़ी सब reject करें। मना की गई strings की block-list (deny-list) हमेशा अधूरी रहती है, क्योंकि ख़तरनाक value को किसी भी list से ज़्यादा तरीक़ों से लिखा जा सकता है, और वह सही data भी reject करती है: apostrophe block करने से O'Brien reject हो जाता है, पर कोई query सुरक्षित नहीं बनती। Cheat sheet deny-listing और input की "cleaning" को अपने common pitfalls में गिनती है। Free text की भी allow-list होती है, बस चौड़ी: सभी components में एक तय character encoding, malformed input reject, सही punctuation और scripts बने रहें, length limit हो, और जहाँ values compare होती हैं वहाँ validation और storage से पहले एक ही Unicode normalisation लागू हो (ताकि एक character के रूप में टाइप किया é और accent mark के साथ e एक ही value हों)।

required, maxlength और pattern जैसी browser checks feedback हैं, control नहीं: जैसा testing web forms वाले lesson में, कोई भी page बदल सकता है या page के बिना request भेज सकता है। Cheat sheet साफ़ कहती है: server पर validate करें, तब भी जब browser वही fields check करता हो, और internal APIs, partner feeds और queues से आया data भी validate करें। Form सिर्फ़ एक entry point है: mobile app जो JSON API call करता है, bulk import, query string, Accept-Language जैसा header, cookie और webhook सब बाहर से values लाते हैं। Tester साबित करता है कि हर path हर rule लागू करता है।

  • हर rule ऐसे लिखें कि उसे टेस्ट किया जा सके: order number के लिए ^ORD-[0-9]{5}$, यानी ORD- और ठीक पाँच digits (anchors ^ और $ पूरी value का match ज़रूरी बनाते हैं, जैसा cheat sheet कहती है; इनके बिना pattern xx ORD-12345 <b> भी स्वीकार कर लेता है); quantity के लिए 1 से 20 तक integer; country के लिए stored list की एक value; company name के लिए Unicode letters, digits, spaces और ' - & . के 2 से 80 characters, ताकि apostrophe और ampersand legal रहें।
  • Network panel से form की request cURL के रूप में copy करें, एक field को ऐसी value दें जिसे page reject करता है, test account से भेजें और 4xx की उम्मीद करें जो field और rule का नाम ले, कुछ भी store न हो, और message में stack trace या SQL न हो।
  • वही set API और import से भेजें: 81 characters, quantity 0 और 21, country ZZ, और नीचे की request, जिसमें company और notes अपने rules pass करते हैं जबकि quantity और country fail होते हैं। जो path वह स्वीकार कर ले जिसे form reject करता है, वह finding है।
  • Silent repair पर नज़र रखें: जो server 81 characters को बिना message के 80 पर काट देता है या < हटा देता है, वह user का data बदलता है। जब तक requirement इसकी इजाज़त न दे, report करें।
POST /api/customers HTTP/1.1
Host: crm.test.example
Content-Type: application/json

{"company": "O'Brien & Sons", "quantity": 21, "country": "ZZ",
 "notes": "Discount < 10% until <b>Ramadan</b>"}

HTTP/1.1 422 Unprocessable Content
Content-Type: application/json

{"errors": [{"field": "quantity", "rule": "integer 1-20"},
            {"field": "country", "rule": "not a known country code"}]}

आज़माएँ: Regex टेस्टर आज़माएँ: नेगेटिव टेस्ट जनरेटर आज़माएँ: स्पेशल कैरेक्टर डेटासेट जनरेटर

Output encoding: एक value, हर context के लिए एक encoding

Encoding output के समय होती है, उस code में जो value को page, link, script या query में लिखता है, और यह इस पर निर्भर है कि value कहाँ पहुँचती है। OWASP Cross Site Scripting Prevention Cheat Sheet हर HTML context को उसके अपने rules देती है: element content, attribute values, JavaScript, CSS और URLs। Database का अपना समकक्ष है: parameterised query value को SQL statement से अलग भेजती है, इसलिए database उसे कभी SQL की तरह parse नहीं करता; Injection Prevention Cheat Sheet input की escaping को आख़िरी उपाय मानती है। Stored value कभी नहीं बदलती, और ग़लत context के लिए encode की गई value असुरक्षित ही रहती है, क्योंकि URL या script string के अंदर HTML entities का वहाँ कोई मतलब नहीं।

  • HTML element content: & बनता है &amp;, < बनता है &lt;, > बनता है &gt;, " बनता है &quot; और ' बनता है &#x27; (&#39; और &apos; वही character हैं), ताकि page characters को वैसे ही दिखाए जैसे टाइप किए गए।
  • HTML attribute: वही entities, title या value जैसे quoted attribute के अंदर; unquoted attribute से space और कई दूसरे characters के ज़रिए बाहर निकला जा सकता है। onclick जैसा event attribute script context है: browser script चलने से पहले entities decode कर देता है, इसलिए वहाँ वे कुछ नहीं बचातीं।
  • URL parameter: percent-encoding, जिससे space बनता है %20, & बनता है %26 और strict RFC 3986 encoding में ' बनता है %27 (कई encoders apostrophe को वैसा ही छोड़ देते हैं); बिना encoding के नाम का & दूसरा parameter शुरू कर देता है। href में लिखा गया URL फिर attribute-encode भी होता है।
  • JavaScript और JSON: string escaping किसी maintained encoder से, हाथ से quotes escape करके नहीं: " को \", \ को \\, और जब data HTML page के अंदर हो तो < को \u003c, ताकि कोई value script बंद न कर सके। और सुरक्षित: value को script से बाहर रखें, जैसे data- attribute में जिसे dataset से पढ़ा जाए, और उसे page में textContent से लिखें, innerHTML से कभी नहीं।
  • SQL: parameterised query या prepared statement O'Brien को text छुए बिना data बनाए रखती है।
Stored value        O'Brien & Sons

HTML content        O&#x27;Brien &amp; Sons
HTML attribute      title="O&#x27;Brien &amp; Sons"
URL parameter       ?q=O%27Brien%20%26%20Sons
JSON / JavaScript   {"company": "O'Brien & Sons"}      (यहाँ escape करने को कुछ नहीं)
SQL                 WHERE company = ?                  (value parameter के रूप में bound)

एक character, तीन contexts:   <   ->   &lt; (HTML)   %3C (URL)   \u003c (script)

आज़माएँ: HTML एंटिटी एन्कोडर आज़माएँ: URL एन्कोडर आज़माएँ: JSON एस्केप / अनएस्केप

दोनों क्यों: दरवाज़े पर validation, हर exit पर encoding

कोई भी control दूसरे की जगह नहीं लेता। Validation O'Brien, Al-Harbi & Sons या price < 50 कहने वाली note को reject नहीं कर सकती, क्योंकि वे सही data हैं; सिर्फ़ encoding उन्हें बाहर जाते समय harmless रखती है। Encoding -1 की quantity, दस megabyte की note या ऐसे country को reject नहीं कर सकती जो मौजूद ही नहीं, क्योंकि वे बिल्कुल ठीक display होते हैं; सिर्फ़ validation ख़राब data को बाहर रखती है। Input Validation Cheat Sheet भी यही कहती है: validation न SQL के लिए parameterised queries की जगह लेती है, न XSS के विरुद्ध context-aware output encoding की।

इसलिए क्रम तय है: input, validate (accept या reject, चुपचाप repair कभी नहीं), accepted value को बिना बदले store करना, हर output पर context के लिए encode करना। पहले से encoded value store करना chain तोड़ देता है, क्योंकि तब हर दूसरे output को ग़लत data मिलता है: e-mail &amp; को text की तरह दिखाता है, CSV export में entities जाती हैं, और सही encode करने वाला page screen पर &amp; दिखाता है क्योंकि उसके source में अब &amp;amp; है, यानी double-encoding defect। Sanitisation तीसरी, अलग operation है उन गिने-चुने fields के लिए जिन्हें markup स्वीकार करना ही है, जैसे rich-text editor: sanitiser library सिर्फ़ tags और attributes की allow-list रखती है, और नतीजा जहाँ भी plain text के रूप में बाहर जाए वहाँ फिर भी encode होता है।

एक value का तय क्रम: server पर allow-list से validate, बिना बदले store, और हर output पर उसके context के लिए encode; उसे encoded store करना या ग़लत context के लिए encode करना chain तोड़ देता है।
  1. 1Input आता हैकोई भी entry point: form, JSON API, import, query string, header, cookie, webhookO'Brien & Sons
  2. 2Server पर validateहर field के लिए allow-list rule: type, length, range, format, set, फिर business meaningAllow-list

    शाखा: Reject: field और rule का नाम लेता 4xx; कुछ store नहीं, चुपचाप repair नहीं

    गेट: सिर्फ़ accepted values, बिना बदले

  3. 3Validated रूप में storeStored value कभी नहीं बदलती: न entities, न कुछ हटाया, न काटाO'Brien & Sons

    शाखा: Defect: पहले से encoded store हुई, इसलिए page &amp; को text की तरह दिखाता है (source में &amp;amp;) और e-mails व exports में raw entities जाती हैंफ़ेल

  4. 4Output पर context के अनुसार encodeउस code में जो value लिखता है, ठीक बाहर जाते समय
    एक value, हर context के लिए एक encoding
    • 5HTML content या quoted attributeEntitiesO&#x27;Brien &amp; Sons
    • 6URL parameterPercent-encoding?q=O%27Brien%20%26%20Sons
    • 7JavaScript या JSON string" और \ की string escaping, और page के अंदर < को \u003c; यहाँ escape करने को कुछ नहीं"O'Brien & Sons"
    • 8SQLParameterised query: value statement को कभी नहीं छूतीWHERE company = ?

    शाखा: Defect: ग़लत context के लिए encode, जैसे URL या script string के अंदर HTML entities, जहाँ वे कुछ नहीं बचातींफ़ेल

  5. 9OutputPage, link, script, query, e-mail, CSV export, API response: हर exit, वैसा ही दिखे जैसा टाइप हुआO'Brien & Sons

इसके बाद:Browser, URL parser या database value को data मानता है, code कभी नहीं

Worked example: एक customer उसके outputs से होकर

आपके test environment में एक CRM है, जिसे टेस्ट करने की लिखित अनुमति है, और उसमें ऊपर वाला customer form है। Tester company O'Brien & Sons और note Discount < 10% until <b>Ramadan</b> वाला customer save करता है, एक बार form से और एक बार valid quantity और country के साथ API से, फिर हर उस जगह जाता है जहाँ दोनों values दिखती हैं: customer list, नाम पर tooltip (title attribute), "find similar" link, CSV export और welcome e-mail।

  • Customer list: दोनों values वैसी ही दिखती हैं जैसी टाइप की गईं; source में &#x27;, &amp; और &lt; हैं। Pass।
  • Tooltip: सिर्फ़ O दिखाता है। Source में title='O'Brien & Sons' है: apostrophe ने single-quoted attribute ख़त्म कर दिया और बाक़ी value उसके बाहर जा गिरी। Finding: attribute encoding नहीं है। यहीं रुकें और report करें; XSS lesson यहीं से आगे बढ़ता है।
  • Find-similar link: /customers?q=O'Brien & Sons बिना percent-encoding के; search O'Brien के लिए चलती है और server को Sons नाम का दूसरा parameter मिलता है। Finding: URL encoding नहीं है, और ampersand वाले हर नाम के लिए functional defect।
  • CSV export: note Discount &lt; 10% until &lt;b&gt;Ramadan&lt;/b&gt; के रूप में पहुँचती है। Finding: export ने HTML-encoded text दोबारा इस्तेमाल किया, इसलिए जो भी उसे download करे उसे ग़लत data मिलता है; ग़लत context के लिए encoding।
  • Welcome e-mail: Ramadan bold में। Finding: template note को markup की तरह डालता है, इसलिए एक user का लिखा text दूसरे के mailbox में render होता है; इसे restricted visibility के साथ HTML injection के रूप में report करें और severity security lead को तय करने दें।
  • Entry points: API से quantity: 21 और country: ZZ पर 422 आता है जो दोनों fields का नाम लेता है, कुछ store नहीं होता। Pass। Import से 81 characters का company name स्वीकार होकर बिना message के 80 पर कट जाता है। Finding: import form से कम validate करता है।

आम गलतियाँ

  • Browser के required, maxlength या pattern को protection मानना, और page के बिना request कभी न भेजना।
  • सिर्फ़ main form टेस्ट करना, जबकि API, import और mobile client कमज़ोर rules के साथ उसी database तक पहुँचते हैं।
  • Allow-list rules की जगह "<script> reject करो" जैसी block-lists लिखना; जो spelling list में नहीं, वह पहली ही बार में निकल जाती है।
  • Store करने से पहले encode करना, या पहले से encoded value store करना, जिससे page के source में &amp;amp; और e-mails व exports में raw entities पहुँचती हैं।
  • ग़लत context के लिए encode करना, जैसे URL या script string के अंदर HTML entities, जहाँ वे कुछ भी नहीं बचातीं।
  • Harmless markers की जगह script payloads इस्तेमाल करना, या लिखित अनुमति के बिना system टेस्ट करना।

QA का नज़रिया

Validation rules test basis हैं। Refinement में हर नए field के लिए पूछें: type, length, range, format, allowed set, reject होने पर user क्या देखता है, और value कहाँ और किन contexts में दिखेगी। जवाब acceptance criteria में लिखें ताकि developer, tester और API documentation सहमत हों, फिर test design module की तरह equivalence partitioning और boundary value analysis से test cases निकालें।

Testing के दौरान एक marker set रखें और उसे हर entry point से हर output तक ले जाएँ, e-mails, PDFs, exports और admin screens समेत; request, response और page source record करें, सिर्फ़ screenshots नहीं, tokens mask करके। Server की missing check या missing encoding को restricted visibility वाली security finding के रूप में report करें, entry point और exact output का नाम लें, और severity security lead से तय करें। Fix के बाद हर output पर confirmation test करें और markers को regression suite में रखें: नया template, export या client दरार फिर खोल देता है।

अभ्यास

Booking form की validation और encoding review करें

आपका काम

आपके test environment में एक clinic booking site है, जिसे टेस्ट करने की लिखित अनुमति आपके पास है, और उसके form में Name (2 से 60 characters: letters, spaces, apostrophe और hyphen), Mobile (05 और आठ digits), Reason (free text, 500 characters तक) और Slot (offered times में से एक) हैं। नीचे एक API request उसके response के साथ और page source के तीन fragments हैं जहाँ saved values दिखती हैं।

पाँच observations में से हर एक के लिए तय करें कि वह pass है या finding: स्वीकार हुआ name, स्वीकार हुआ slot और तीनों fragments। Missing control का नाम लें (validation rule, server-side enforcement, या encoding और उसका context) और bug title लिखें। फिर वे अगली checks लिखें जो आप चलाएँगे।

सामग्री
POST /api/bookings
{"name": "Sara <b>qa</b>", "mobile": "0512345678",
 "reason": "Follow-up, pain < 3/10 since 'Sunday'", "slot": "2026-11-03T25:00"}

HTTP/1.1 201 Created
{"id": 8821, "name": "Sara <b>qa</b>", "slot": "2026-11-03T25:00"}

Fragment 1: reception की list
<td>Sara &lt;b&gt;qa&lt;/b&gt;</td>

Fragment 2: doctor की screen
<p class="reason">Follow-up, pain < 3/10 since 'Sunday'</p>

Fragment 3: reminder page
<a href="/r?name=Sara <b>qa</b>&id=8821">Reschedule</a>
चरण
  1. Request की values को चारों rules से मिलाएँ और response पढ़ें: server ने कौन-से rules लागू किए और कौन-से नहीं?
  2. हर fragment के लिए output context और उसे जो encoding चाहिए उसका नाम लें, फिर source जो दिखाता है उससे मिलाएँ।
  3. Findings को risk के क्रम में रखें और हर एक के लिए एक bug title लिखें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Name: Sara <b>qa</b> में <, > और / हैं, जिन्हें allow-list इजाज़त नहीं देती, फिर भी 201 Created उसे वापस echo करता है। Finding: server वह name rule लागू नहीं करता जो form दिखाता है। Bug title: "POST /api/bookings name में वे markup characters स्वीकार करता है जिन्हें form reject करता है"।

Slot: 2026-11-03T25:00 offered times में से नहीं है और hour 25 मौजूद ही नहीं, फिर भी store हो गया। Finding: slot पर set या semantic validation नहीं। Bug title: "Booking API ऐसा slot store करता है जो कभी offer ही नहीं हुआ"।

Fragment 1: &lt;b&gt;qa&lt;/b&gt; सही element-content encoding है; receptionist नाम वैसा ही देखती है जैसा टाइप हुआ। Pass।

Fragment 2: reason raw लिखा गया है। यह सही सिर्फ़ इसलिए दिखता है क्योंकि < के बाद space है, जिसे browsers text पढ़ते हैं; <b> वाला reason doctor की screen पर markup की तरह render होगा। Finding: patients के stored text की HTML encoding missing, probable stored XSS (एक बार save हुआ input जो बाद के हर viewer के लिए render होता है, XSS lesson का विषय)। Bug title: "Doctor की screen booking reason को बिना HTML encoding के दिखाती है"। Restricted visibility के साथ report करें और आगे probe न करें।

Fragment 3: href बिना percent-encoding के बना है: space, <, > और / को %20, %3C, %3E और %2F होना चाहिए, और & वाला नाम, जो इसलिए पहुँच जाता है कि server name rule लागू नहीं करता, नया parameter शुरू कर देगा। Finding: URL encoding missing, functional defect भी। Bug title: "Special characters वाले नामों के लिए Reschedule link टूट जाता है"।

क्रम: पहले fragment 2, फिर दोनों validation gaps, फिर link। इस request में mobile और reason valid हैं, इसलिए यह नहीं दिखता कि server उनके rules लागू करता है या नहीं। अगली checks: API से invalid mobile number और 501 characters का reason, field का नाम लेने वाले 422 की उम्मीद के साथ; वही values mobile app के endpoint और import से; confirmation e-mail और PDF appointment letter; और हर finding की severity security lead के साथ तय करना।

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

अगर API सिर्फ़ हमारे अपने pages इस्तेमाल करते हैं, तो क्या client-side validation काफ़ी है?

नहीं। Browser की नज़र से कोई private API नहीं होती: page जो भेज सकता है, developer tools वाला व्यक्ति उसे अलग तरह से भेज सकता है। OWASP Input Validation Cheat Sheet server पर validation ज़रूरी मानती है, तब भी जब browser वही fields check करता हो; browser checks तेज़ feedback के लिए उपयोगी रहती हैं।

क्या application को encoded value store करनी चाहिए ताकि हर output सुरक्षित रहे?

नहीं। Value को validated रूप में store करें और हर output पर उसके context के लिए encode करें। Stored &lt; e-mail, export या API response में ग़लत data है, और सही encode करने वाला page उसे screen पर &lt; दिखाता है, क्योंकि तब उसके source में &amp;lt; होता है। Rich text अपवाद है, जिसे encoding नहीं, sanitiser संभालता है।

Validation, sanitisation और encoding में क्या फ़र्क़ है?

Validation value को rules से जाँचकर accept या reject करती है और कुछ नहीं बदलती। Sanitisation value को हिस्से हटाकर या बदलकर बदलती है, जैसे वे tags जो rich-text field में नहीं हो सकते। Encoding सिर्फ़ एक output context के लिए representation बदलती है, और stored value वही रहती है। Tests तीनों में से किसी एक की कमी ढूँढते हैं, और ऐसी sanitisation जो चुपचाप वहाँ हो जाए जहाँ reject होने की उम्मीद थी।

क्या मैं ये defects security tools के बिना ढूँढ सकता हूँ?

हाँ। Apostrophe, ampersand, किसी शब्द के चारों ओर angle brackets, सीमा से लंबी string और range से बाहर number जैसे harmless markers, साथ में developer tools और page के बिना requests भेजने वाला command-line client, missing checks और missing encoding पकड़ लेते हैं। Weakness exploit हो सकती है यह साबित करना security team का काम है; missing control अपने आप में report करने लायक defect है।

संदर्भ

  • OWASP Cheat Sheet Series: Input ValidationOWASP Foundationअलाउ-लिस्ट वैलिडेशन, सिंटैक्टिक बनाम सेमांटिक जाँच, और क्लाइंट-साइड वैलिडेशन कभी सुरक्षा नियंत्रण क्यों नहीं है।
  • OWASP Cheat Sheet Series: Cross Site Scripting PreventionOWASP FoundationXSS से बचाव: हर context के अनुसार output encoding, उपयोगकर्ता के लिखे HTML का sanitization, सुरक्षित DOM sinks और framework सुरक्षा, और CSP केवल defence in depth के रूप में।
  • OWASP Cheat Sheet Series: Injection PreventionOWASP Foundationपैरामीटराइज़ेशन, वैलिडेशन और एस्केपिंग से SQL, OS-कमांड और अन्य इंजेक्शन की रोकथाम।
  • OWASP Top 10:2025OWASP Foundation · 2025वेब एप्लिकेशन की दस सबसे गंभीर सुरक्षा जोखिम, हर एक की जाँच और रोकथाम के साथ।
टूल्स

Mutqan tools से अभ्यास करें

Regex टेस्टर

रेगुलर एक्सप्रेशन को लाइव टेस्ट करें — मैच हाइलाइटिंग, कैप्चर ग्रुप और रिप्लेस प्रीव्यू के साथ।

यूटिलिटीज़

नेगेटिव टेस्ट जनरेटर

फ़ॉर्म फ़ील्ड और API के लिए negative टेस्ट केस बनाएँ: खाली, null, ग़लत टाइप, बहुत लंबा, injection, अमान्य फ़ॉर्मेट।

टेस्ट डिज़ाइन

HTML एंटिटी एन्कोडर

XSS रोकने के लिए HTML के विशेष कैरेक्टर (<, >, &, कोट्स) को एंटिटी में एस्केप करें।

एन्कोडिंग

URL एन्कोडर

URL, क्वेरी स्ट्रिंग और फ़ॉर्म डेटा में सुरक्षित इस्तेमाल के लिए टेक्स्ट को percent-encode करें।

एन्कोडिंग

JSON एस्केप / अनएस्केप

टेक्स्ट को JSON स्ट्रिंग के भीतर सुरक्षित रूप से रखने के लिए एस्केप करें, या JSON स्ट्रिंग लिटरल को अनएस्केप करें।

JSON और डेटा

और गहराई से

इस topic में आपकी प्रगति

QA रोडमैप का हिस्सा