React Security की Best Practices

React में Security best practices अपने doors और windows lock करने जैसी हैं — React बहुत सारी basic safety automatically handle करता है, लेकिन फिर भी आपको खुद door propping open से बचना है।

In this page:

React का Built-In XSS Protection
dangerouslySetInnerHTML का Danger
Client-Side Validation Real Security नहीं है

Syntax

markup

// Safe: React escapes the value
<p>{userInput}</p>

// Dangerous: only use with sanitized HTML
<div dangerouslySetInnerHTML={{ __html: sanitizedHtml }} />

React का Built-In XSS Protection

जब आप JSX के अंदर {userInput} जैसी एक value render करते हैं, React इसे DOM में insert करने से पहले automatically escape करता है, मतलब even अगर userInput में HTML/script tags हैं, यह code के रूप में execute होने के बजाय plain text के रूप में displayed होता है।

यह default behavior cross-site scripting (XSS) attacks की एक बड़ी class से automatically protect करता है।

Note: यह automatic escaping normal JSX interpolation पर apply होता है — आपको यह protection सिर्फ React को normal तरीके से उपयोग करके free में मिलता है।

Warning: यह protection सिर्फ normal JSX rendering पर apply होता है — यह dangerouslySetInnerHTML तक extend नहीं होता, जो explicitly इससे opt out होता है।

उदाहरण: React's Built-In XSS Protection

markup

<!DOCTYPE html>
<html>
<head>
  <script src="https://unpkg.com/react@18/umd/react.development.js"></script>
  <script src="https://unpkg.com/react-dom@18/umd/react-dom.development.js"></script>
  <script src="https://unpkg.com/@babel/standalone/babel.min.js"></script>
</head>
<body>
  <div id="root"></div>
  <script type="text/babel">
function App() {
  const userInput = "<img src=x onerror=alert('hacked')>";
  return <p>{userInput}</p>; // Rendered as literal text, NOT executed as HTML
}
ReactDOM.createRoot(document.getElementById('root')).render(<App />);
  </script>
</body>
</html>

dangerouslySetInnerHTML का Danger

dangerouslySetInnerHTML आपको directly DOM में raw HTML inject करने देता है, React की automatic escaping को पूरी तरह bypass करते हुए। अगर वह HTML user input (या किसी untrusted source) से बिना sanitize किए आता है, यह attacker के लिए आपके page पर arbitrary JavaScript run करने का एक direct path खोल देता है।

Note: अगर आपको user-provided HTML render करना ज़रूरी है (जैसे एक rich-text comment), इसे dangerouslySetInnerHTML में pass करने से पहले एक dedicated library जैसे DOMPurify से sanitize करें।

Warning: नाम बिना वजह dramatic नहीं है — unsanitized, untrusted content के साथ इसे उपयोग करना एक genuine, exploitable XSS vulnerability है, कोई theoretical risk नहीं।

उदाहरण: The Danger of dangerouslySetInnerHTML

markup

<!DOCTYPE html>
<html>
<head>
  <script src="https://unpkg.com/react@18/umd/react.development.js"></script>
  <script src="https://unpkg.com/react-dom@18/umd/react-dom.development.js"></script>
  <script src="https://unpkg.com/@babel/standalone/babel.min.js"></script>
</head>
<body>
  <div id="root"></div>
  <script type="text/babel">
function App() {
  const trustedContent = "<strong>This is safe because WE wrote it, not a user</strong>";
  return <div dangerouslySetInnerHTML={{ __html: trustedContent }} />;
  // Never pass raw, unsanitized USER input here without a sanitizer like DOMPurify first
}
ReactDOM.createRoot(document.getElementById('root')).render(<App />);
  </script>
</body>
</html>

Client-Side Validation Real Security नहीं है

Browser में एक form field validate करना (जैसे submit से पहले email format check करना) instant feedback देकर user experience improve करता है, लेकिन एक malicious user सारी client-side JavaScript पूरी तरह bypass कर सकता है और directly आपके server को जो भी data चाहे भेज सकता है।

Real security और validation हमेशा server-side पर भी होनी चाहिए।

Note: Client-side validation को purely एक UX nicety के रूप में सोचें — server को हर request को independently re-validate और authorize करना चाहिए जैसे client-side checks कभी हुए ही न हों।

Warning: किसी security-sensitive चीज़ (permissions, data validation, pricing) के लिए सिर्फ client-side checks पर निर्भर रहना browser devtools या एक direct API request उपयोग करने वाले किसी के लिए trivially bypassable है।

उदाहरण: Client-Side Validation Isn't Real Security

markup

<!DOCTYPE html>
<html>
<head>
  <script src="https://unpkg.com/react@18/umd/react.development.js"></script>
  <script src="https://unpkg.com/react-dom@18/umd/react-dom.development.js"></script>
  <script src="https://unpkg.com/@babel/standalone/babel.min.js"></script>
</head>
<body>
  <div id="root"></div>
  <script type="text/babel">
function App() {
  const [email, setEmail] = React.useState("");
  const isValidLooking = email.includes("@"); // UX nicety only
  return (
    <div>
      <input value={email} onChange={e => setEmail(e.target.value)} />
      <p>{isValidLooking ? "Looks valid (still re-check on the server!)" : "Enter an email"}</p>
    </div>
  );
}
ReactDOM.createRoot(document.getElementById('root')).render(<App />);
  </script>
</body>
</html>

Chapter Quiz — Complete all 14 topics to unlock

0/14 topics done

Complete these topics first:

← Previous Lesson i18n with react-i18next Next Lesson → Why Performance Matters

React Security की Best Practices

React का Built-In XSS Protection

dangerouslySetInnerHTML का Danger

Client-Side Validation Real Security नहीं है

Chapter Quiz — Complete all 14 topics to unlock

Login to run this code