iframe एम्बेड चेकर
मुफ़्त ऑनलाइन iframe चेकर: किसी भी वेबपेज URL दर्ज करें ताकि इसके X-Frame-Options और Content-Security-Policy frame-ancestors हेडर्स की जाँच की जा सके, यह पता लगाया जा सके कि पेज को iframe में एम्बेड किया जा सकता है या नहीं, और लाइव प्रीव्यू के साथ पुष्टि की जा सके। इतिहास वर्तमान ब्राउज़र सेशन के लिए संग्रहीत रहता है।
इतिहास (वर्तमान सेशन)
केवल इस टैब में सहेजा गया (sessionStorage); टैब बंद करने पर हटा दिया जाएगा। कुछ भी सर्वर पर भेजा नहीं जाता है।
जाँच कैसे काम करती है
- लक्षित URL दर्ज करें और 'जाँच' पर क्लिक करें। सर्वर पेज को एक वास्तविक iframe अनुरोध के रूप में प्राप्त करता है (Sec-Fetch-Dest: iframe सहित) और उसके रिस्पॉन्स हेडर्स को पढ़ता है।
- निष्कर्ष X-Frame-Options (DENY / SAMEORIGIN फ्रेमिंग पर रोक लगाते हैं) और Content-Security-Policy frame-ancestors पर आधारित होता है। (* या स्कीम विल्डकार्ड ही किसी भी थर्ड-पार्टेंट को अनुमति देते हैं)।
- लाइव प्रीव्यू iframe में वही URL लोड किया जाता है ताकि आप पुष्टि कर सकें कि ब्राउज़र वास्तव में क्या करता है, जिनमें JavaScript फ्रेम-बस्तिंग भी शामिल है जिसे हेडर दिखा नहीं सकते।
क्या निर्धारित करता है कि कोई पेज एम्बेड किया जा सकता है या नहीं?
किसी वेबपेज को दूसरी साइट पर <iframe> में दिखाना संभव है या नहीं, इस बारे में ब्राउज़र उस पेज द्वारा भेजे गए रेस्पॉन्स हेडर्स के आधार पर निर्णय लेता है। यह चेकर सर्वर-साइड पर वही जांच ऑपरेशन करता है और आपको तुरंत रिपोर्ट देता है।
X-Frame-Options एक पारंपरिक हेडर है: DENY सभी पेजों पर फ्रेमिंग को प्रतिबंधित करता है, SAMEORIGIN केवल समान मूल (origin) वाली साइटों को ही एम्बेड करने देता है, और ALLOW-FROM को आधुनिक ब्राउज़रों में निकाल दिया गया है। जब यह हेडर अनुपस्थित होता है, तो पुराने नियम फ्रेमिंग को ब्लॉक नहीं करते।
Content-Security-Policy के `frame-ancestors` निर्देश इसका आधुनिक विकल्प है। यह उन origins की सूची बताता है जिन्हें पेज को एम्बेड करने की अनुमति प्राप्त है — उदाहरण के लिए: `frame-ancestors 'self' https:\/\/example.com`। `*` (या केवल `https:` जैसे अकेले स्कीम) किसी भी HTTPS पैरेंट साइट को अनुमति देता है; इसके विपरीत, अधिक कठोर मान तीसरी साइटों की एम्बेडिंग को रोक देगा।
केवल हेडर्स ही पूरी कहानी नहीं हैं: पेज के स्क्रिप्ट 'फ्रेम-बस्टर' कोड चला सकते हैं (जैसे `top !== self` की जांच करके मुख्य विंडो में रीडायरेक्ट करना), और लॉगिन पेज या क्षेत्र-प्रतिबंधित एंडप्वाइंट्स डेटासेंटर अनुरोधों पर अलग व्यवहार कर सकते हैं। इसीलिए प्रत्येक स्कैन परिणाम के साथ एक लाइव प्रीव्यू भी शामिल है।
त्वरित मार्गदर्शिका: रिस्पॉन्स हेडर सेटअप
यदि आप साइट के संचालक हैं, तो रेस्पॉन्स हेडर्स के माध्यम से फ्रेमिंग पर सीधा नियंत्रण रखें।
किसी भी पेज से एम्बेडिंग ब्लॉक करें
X-Frame-Options: DENY
Content-Security-Policy: frame-ancestors 'none'
ब्राउज़र किसी भी iframe में इस पेज को रिंडर करने से मना कर देते हैं — यह क्लिक्सैकिंग (clickjacking) के खिलाफ सबसे कड़ा सुरक्षा उपाय है।
केवल समान-मूल (same-origin) एम्बेडिंग की अनुमति दें
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self'
केवल समान URI स्कीम, होस्ट और पोर्ट वाली साइटें ही इसे फ्रेम कर सकती हैं; अन्य तीसरी साइटों का एम्बेडिंग ब्लॉक रहेगा।
केवल विशिष्ट उद्गम (origins) की अनुमति दें
Content-Security-Policy: frame-ancestors 'self' https:\/\/trusted.example.com
frame-ancestors में केवल विश्वसनीय origins की सूची डालें; जिन origins की सूची में गिनती नहीं है, वे ब्लॉक रहेंगे।
किसी भी पेज से एम्बेडिंग की अनुमति दें
X-Frame-Options सेट न करें
Content-Security-Policy: frame-ancestors *
किसी भी साइट द्वारा इस पेज को iframe में एम्बेड किया जा सकता है। लागू करने से पूर्व सुरक्षा जोखिमों का आकलन अवश्य करें।
महत्वपूर्ण: X-Frame-Options हेडर अब CSP के frame-ancestors निर्देश द्वारा प्रतिस्थापित हो चुका है। जब दोनों हेडर्स उपलब्ध होते हैं, तो CSP की प्राथमिकता होती है — इसलिए frame-ancestors का उपयोग करना बेहतर है।
सर्वर कैसे पहचानता है कि अनुरोध एक iframe से आ रहा है?
लगभग 2020 के बाद से, Chromium और Firefox आधारित ब्राउज़र स्वचालित रूप से हर नेविगेशन और सब-रिसोर्स अनुरोध के साथ Fetch Metadata हेडर्स जोड़ना शुरू कर देते हैं। फ्रेमिंग जाँच के लिए इसमें से सबसे उपयोगी `Sec-Fetch-Dest` है — यह सर्वर को बिना किसी रिक्वेस्टिंग पेज की सहमति के ही यह बता देता है कि रिसोर्स किस संदर्भ (context) में माँगा गया है।
- Sec-Fetch-Dest: document — यह टॉप-लेवल नेविगेशन दर्शाता है, यानी पेज किसी iframe या फ्रेम के अंदर नहीं, बल्कि पूरी विंडो में खुल रहा है।
- Sec-Fetch-Dest: iframe — अनुरोध किसी `<iframe>` तत्व के अंदर लोड हो रहा है।
- Sec-Fetch-Dest: frame — अनुरोध पुराने `<frame>` (frameset) तत्व के अंदर लोड हो रहा है।
- Sec-Fetch-Dest: embed / object — अनुरोध किसी `<embed>` या `<object>` तत्व के अंदर लोड हो रहा है।
यह चेकर `Sec-Fetch-Dest: iframe` के साथ अपना प्रोब भेजता है, जो एक असली ब्राउज़र द्वारा पेज एम्बेड करते समय ठीक वैसा ही डेटा भेजता है — ताकि परिणाम यह दर्शा सके कि लक्षित सर्वर वास्तव में मूल iframe अनुरोधों पर कैसे व्यवहार करता है, न कि सिर्फ किसी सामान्य फ़ेच पर।
`Sec-Fetch-Dest` एक उपयोगी संकेत है लेकिन सुरक्षा सीमा नहीं: इसे केवल आधुनिक ब्राउज़र भेजते हैं, और गैर-ब्राउज़र क्लाइंट — curl, बॉट्स, कुछ वेब व्यू और पुराने ब्राउज़र — इसे पूरी तरह छोड़ सकते हैं या मनमाना मान भेज सकते हैं। एक सर्वर इसके आधार पर लॉग कर सकता है या रेट-लिमिट लगा सकता है, लेकिन इसे अकेले इमबेडिंग (फ्रेमिंग) के सुरक्षित होने का निर्णय लेने पर कभी भरोसा नहीं करना चाहिए; यह निर्णय अभी भी `X-Frame-Options` और `CSP frame-ancestors` पर होता है, जिन्हें ब्राउज़र अनुरोध हेडर्स से स्वतंत्र रूप से लागू करते हैं।
क्लाइंट साइड पर, कोई पेज बिना किसी हेडर के यह भी पहचान सकता है कि वह एक फ्रेम के अंदर चल रहा है, उदाहरण के लिए `window.top !== window.self` की तुलना करके (या समान ओरिजिन फ्रेम के लिए `window.frameElement` पढ़कर), और फिर प्रतिक्रिया दे सकता है — जैसे चेतावनी दिखाना या टॉप-लेवल रीडायरेक्ट फोर्स करना। इसे पहले ज़िक्र की गई फ्रेम-बस्तिंग तकनीक कहा जाता है, और यह अनुरोध हेडर्स चाहे कुछ भी हों, इसके बावजूद काम करती है।
सर्वर कॉन्फ़िगरेशन उदाहरण: iFrame एम्बेडिंग को ब्लॉक करना
नीचे दिए गए कोड स्निपेट यह दिखाते हैं कि अपने सर्वर या फ्रेमवर्क को ऐसे कॉन्फ़िगर करने के लिए क्या बदलाव करने चाहिए ताकि iframe एम्बेडिंग पूरी तरह रोके जाए (X-Frame-Options: DENY + CSP frame-ancestors 'none') — यह ऊपर दी गई क्विक गाइड में बताए गए विकल्पों में से सबसे सुरक्षित माना जाता है।
server {
location / {
add_header X-Frame-Options "DENY" always;
add_header Content-Security-Policy "frame-ancestors 'none'" always;
}
}
<IfModule mod_headers.c>
Header always set X-Frame-Options "DENY"
Header always set Content-Security-Policy "frame-ancestors 'none'"
</IfModule>
app.use((req, res, next) => {
res.setHeader('X-Frame-Options', 'DENY');
res.setHeader('Content-Security-Policy', "frame-ancestors 'none'");
next();
});
// next.config.js
module.exports = {
async headers() {
return [
{
source: '/:path*',
headers: [
{ key: 'X-Frame-Options', value: 'DENY' },
{ key: 'Content-Security-Policy', value: "frame-ancestors 'none'" },
],
},
];
},
};
class SetFrameOptions
{
public function handle(Request $request, Closure $next): Response
{
$response = $next($request);
$response->headers->set('X-Frame-Options', 'DENY');
$response->headers->set('Content-Security-Policy', "frame-ancestors 'none'");
return $response;
}
}
export default {
async fetch(request) {
const response = await fetch(request);
const headers = new Headers(response.headers);
headers.set('X-Frame-Options', 'DENY');
headers.set('Content-Security-Policy', "frame-ancestors 'none'");
return new Response(response.body, { status: response.status, headers });
},
};
यदि आप सभी को ब्लॉक करने के बजाय केवल अपनी साइट या कुछ विशिष्ट origins को एम्बेड करने की अनुमति देना चाहते हैं, तो DENY को SAMEORIGIN और 'none' को 'self' या origins की स्पष्ट लिस्ट से बदल दें — कॉन्फ़िगरेशन का बाकी सब कुछ वैसा ही रहेगा।
प्रमुख प्लेटफ़ॉर्म सावधानियाँ
सामान्य हेडर नियमों को छोड़कर, कुछ प्रमुख प्लेटफ़ॉर्म की अपनी विशेषताएं होती हैं — हेडर्स से अकेले "ब्लॉक" या "एम्बेड योग्य" मानने से पहले इन बातों को जानना उपयोगी होगा।
| प्लेटफ़ॉर्म \/ परिदृश्य | स्थिति | कारण |
|---|---|---|
| YouTube वॉच पेज (youtube.com\/watch) | ब्लॉक | इसके बजाय आधिकारिक `youtube.com\/embed\/{id}` प्लेयर यूआरआई का उपयोग करें — सामान्य वॉच पेज प्रतिबंधित फ्रेमिंग नीति भेजता है। |
| Google Maps प्लेस पेज | ब्लॉक | केवल मैप्स एम्बेड एपीआई आईफ्रेम यूआरआई (google.com\/maps\/embed) को फ्रेम करने के लिए डिज़ाइन किया गया है। |
| Google \/ Microsoft OAuth लॉगिन पेज | ब्लॉक | 2015 से जानबूझकर ब्लॉक किए गए हैं ताकि iframe के अंदर क्रेडेंशियल-फिशिंग रोकी जा सके; लॉगिन फ़्लो को टॉप-लेवल विंडो या पॉपअप में ही चलना चाहिए। |
| भुगतान चेकआउट पेज (Stripe Checkout, PayPal, अधिकांश बैंक गेटवे) | ब्लॉक | पेमेंट फ़ॉर्म को फ्रेम करना क्लिकजैकिंग का एक क्लासिक तरीका है, इसलिए प्रोसेसर इसे सीधे अस्वीकार कर देते हैं। |
| GitHub रिपॉज़िटरी \/ फ़ाइल पेज | ब्लॉक | साइट-वाइड `frame-ancestors 'none'`; iframe के बजाय REST\/GraphQL API या स्क्रीनशॉट का उपयोग करें। |
| Notion \/ Google Docs "वेब पर प्रकाशित करें" पेज | एम्बेड योग्य | इनہیں एम्बेड करने के लिए स्पष्ट रूप से डिज़ाइन किया गया है, और उत्पाद तैयार एम्बेड कोड प्रदान करता है। |
| विकिपीडिया अनुच्छेद | एम्बेड योग्य | डिफ़ॉल्ट रूप से कोई प्रतिबंधित X-Frame-Options\/CSP नहीं है, लेकिन व्यापक रूप से एम्बेड करने से पहले लाइसेंसिंग और एट्रीब्यूशन शर्तों की जांच जरूर करें। |
सामान्य उपयोग के मामले
- इंटीग्रेशन कोड लिखने से पहले यह तय करें कि आपके अपने उत्पाद में थर्ड-पार्टी विजेट, डैशबोर्ड या दस्तावेज़ को एम्बेड किया जा सकता है या नहीं।
- पुष्टि करें कि आपकी साइट उसी X-Frame-Options या CSP frame-ancestors नीति को भेज रही है जिसकी आप अपेक्षा रखते हैं।
- क्लिकजैक सुरक्षा का त्रुटि निवारण करें: समझें कि कोई पेज iframe के अंदर about:blank या अस्वीकृति संदेश क्यों दिखा रहा है।
- सामग्री संग्रहण या पोर्टल एकीकरण के दौरान, सत्र इतिहास का उपयोग करके प्रस्तावित URL को बैच मोड में स्क्रीन करें और परिणामों पर पुनः विचार करें।
- बाहरी निर्भरताओं की फ्रेमिंग नीति को दस्तावेज़बद्ध करके सुरक्षा समीक्षा या पेनेट्रेशन टेस्ट के लिए तैयार हों।