iframe এম্বেড পরীক্ষক

ফ্রি অনলাইন ইফ্রেম চেকার: যেকোনো ওয়েবপেজের ইউআরএল দিন যাতে এর এক্স-ফ্রেম-অপশনস এবং কন্টেন্ট-সিকিউরিটি-পলিসি ফ্রেম-অ্যান্সেস্টর্স হেডার পরিদর্শন করা যায়, পেজটি ইফ্রেমে এম্বেড করা সম্ভব কিনা জানুন এবং লাইভ প্রিভিউয়ের মাধ্যমে নিশ্চিত হোন। বর্তমান ব্রাউজার সেশনের জন্য হিস্ট্রি সংরক্ষিত থাকবে।

ইফ্রেম এম্বেডিং চেক

:

প্রতিটি লাইনকে একই হেডার চেক প্রক্রিয়ার মাধ্যমে চালানো হয় এবং নিচের সেশন হিস্ট্রিতে যোগ করা হয়। প্রতিটি ব্যাচে 20 ইউআরএলের সর্বোচ্চ সীমা রয়েছে; লক্ষ্য সাইটগুলোর উপর চাপ পড়তে দেওয়া থেকে বিরত থাকতে এটি একবারে কয়েকটি করে চেক করবে।

চেক করা হয়েছে: /
ইউআরএল ফলাফল এইচটিটিপি

লাইভ প্রিভিউ

হেডার পরিদর্শন একটি দ্রুত প্রাথমিক ধাপ, তবে এটি জাভাস্ক্রিপ্ট ফ্রেম-বাস্টিং সনাক্ত করতে পারে না: যদি হেডারে “এম্বেডযোগ্য” বলা হয় কিন্তু প্রিভিউ খালি থাকে, ব্রেক আউট করে বা এরর পেজ দেখায়, তবে পেজটি নিরাপদে এম্বেডযোগ্য নয়। লাইভ প্রিভিউই চূড়ান্ত সিদ্ধান্ত দেবে।

হিস্ট্রি (এই সেশন)

শুধুমাত্র এই ট্যাবেই সংরক্ষিত (sessionStorage); ট্যাব বন্ধ করলে এটি মুছে যাবে। কোনো তথ্যই সার্ভারে পাঠানো হবে না।

এই সেশনে এখন পর্যন্ত কোনো চেক করা হয়নি।

চেকটি কীভাবে কাজ করে

  1. টার্গেট ইউআরএল লিখুন এবং ‘চেক করুন’ এ ক্লিক করুন। সার্ভার একটি আসল ইফ্রেম রিকোয়েস্ট হিসেবে (Sec-Fetch-Dest: iframe সহ) পেজটি আনা হবে এবং এর রেসপন্স হেডার পড়বে।
  2. সিদ্ধান্ত এক্স-ফ্রেম-অপশনস (DENY / SAMEORIGIN ফ্রেমিং ব্লক করে) এবং কন্টেন্ট-সিকিউরিটি-পলিসি ফ্রেম-অ্যান্সেস্টর্সের ওপর ভিত্তি করে দেওয়া হয় (`*` বা স্কিম ওয়াইল্ডকার্ড ব্যতীত যেকোনো থার্ড-পার্টি প্যারেন্টকে অনুমতি দেওয়া হয় না)।
  3. লাইভ প্রিভিউ ইফ্রেমে একই ইউআরএলটি লোড করা হবে, যাতে আপনি নিশ্চিত করতে পারেন ব্রাউজার আসলে কী করছে, এর মধ্যে রয়েছে এমন জাভাস্ক্রিপ্ট ফ্রেম-বাস্টিং যা হেডার থেকে জানা যায় না।

একটি পেজ এম্বেড করা যাবে কিনা তা কী নির্ধারণ করে?

অন্য কোনো সাইটে একটি <iframe>-এর ভেতরে একটি ওয়েবপেজ দেখানো যাবে কিনা, তা ওই পেজের নিজস্ব রেসপন্স হেডারের উপর ভিত্তি করে ব্রাউজার ঠিক করে। এই টুলটিও একই ধরনের পরীক্ষা সার্ভার সাইডে চালিয়ে আপনাকে তাৎক্ষণিক ফলাফল দেখায়।

X-Frame-Options হল প্রচলিত হেডার: DENY প্রতিটি পেজে ফ্রেমিং সম্পূর্ণ নিষিদ্ধ করে, SAMEORIGIN শুধুমাত্র একই ওরিজিনের পেজগুলোকে এটি ফ্রেম করার অনুমতি দেয়, আর ALLOW-FROM আধুনিক ব্রাউজারগুলো থেকে বাদ পড়েছে। যদি এই হেডার অনুপস্থিত থাকে, তবে পুরনো নিয়ম অনুযায়ী ফ্রেমিং ব্লক হবে না।

Content-Security-Policy frame-ancestors হল এর আধুনিক প্রতিস্থাপন। এটি সেই ওরিজিনগুলির তালিকা করে যেগুলো পেজটি এম্বেড করার অনুমতি পাবে — উদাহরণস্বরূপ frame-ancestors 'self' https://example.com। এর মান হিসেবে * (অথবা শুধু https: যেমন প্রোটোকল) নির্দিষ্ট করলে যেকোনো HTTPS ওয়েবসাইট এটি ফ্রেম করতে পারবে; আর আরও সংকীর্ণ মান রাখলে থার্ড-পার্টি এম্বেডিং ব্লক করা হবে।

হেডার দিয়েই শেষ নয়: পেজের স্ক্রিপ্ট ফ্রেম-বাস্টিং কোড চালাতে পারে (যেমন top !== self তুলনা করে মেইন উইন্ডোতে নিয়ে যাওয়া), আবার লগইন পেজ বা জিও-সীমাবদ্ধ এন্ডপয়েন্ট ডেটাসেন্টার আইপি থেকে আসা অনুরোধের ক্ষেত্রে ভিন্ন আচরণ করতে পারে। তাই প্রতিটি ফলাফলের পাশাপাশি একটি লাইভ প্রিভিওও দেখানো হয়।

দ্রুত গাইড: রেসপন্স হেডার সেটআপ

সাইটটি আপনার থাকলে, রেসপন্স হেডার ব্যবহার করে সরাসরি ফ্রেমিং নিয়ন্ত্রণ করুন।

যেকোনো ওয়েবপেজ থেকে এম্বেডিং ব্লক করুন

X-Frame-Options: DENY Content-Security-Policy: frame-ancestors 'none'

ব্রাউজার যেকোনো <iframe>-এ এই পেজটি রেন্ডার করতে অস্বীকার করবে — যা ক্লিকজ্যাকিংয়ের বিরুদ্ধে সবচেয়ে কঠোর সুরক্ষা।

শুধুমাত্র একই ওরিজিন থেকে এম্বেডিং অনুমতি দিন

X-Frame-Options: SAMEORIGIN Content-Security-Policy: frame-ancestors 'self'

একই প্রোটোকল (স্কিম), হোস্ট এবং পোর্ট বিশিষ্ট পেজগুলোকেই এটি ফ্রেম করার অনুমতি থাকবে; থার্ড-পার্টি সাইট ব্লক করা হবে।

শুধুমাত্র নির্দিষ্ট ওরিজিনগুলিকে অনুমতি দিন

Content-Security-Policy: frame-ancestors 'self' https://trusted.example.com

frame-ancestors-এ বিশ্বস্ত ওরিজিনগুলির তালিকা দিন; যাদের তালিকাতে নেই, তাদের ব্লক করা হবে।

যেকোনো ওয়েবপেজ থেকে এম্বেডিং অনুমতি দিন

X-Frame-Options হেডার সেট করবেন না Content-Security-Policy: frame-ancestors *

যেকোনো সাইট <iframe>-এর মাধ্যমে এই পেজটি এম্বেড করতে পারবে। নিরাপত্তার সুবিধা-অসুবিধা বিবেচনা করে সিদ্ধান্ত নিন।

নোট: X-Frame-Options এর পরিবর্তে এখন CSP frame-ancestors ব্যবহার করা হয়। যদি উভয়ই সেট থাকে, তবে CSP প্রাধান্য পাবে — তাই frame-ancestors ব্যবহার করাই শ্রেয়।

সার্ভার কীভাবে শনাক্ত করে যে রিকোয়েস্টটি একটি ইফ্রেম থেকে এসেছে?

২০২০ সালের দিকে থেকে ক্রোমিয়াম এবং ফায়ারফক্স-ভিত্তিক ব্রাউজারগুলো স্বয়ংক্রিয়ভাবে প্রতিটি পেজ নেভিগেশন এবং সাব-রিসোর্স রিকোয়েস্টে Fetch Metadata হেডার সেট সংযুক্ত করে দেয়। ফ্রেমিং পরীক্ষার জন্য সবচেয়ে কার্যকর হেডারটি হল Sec-Fetch-Dest — এটি অনুরোধকারী পেজের কোনো সহায়তা ছাড়াই সার্ভারকে জানিয়ে দেয় কোন প্রেক্ষাপট থেকে রিসোর্সটি আহ্বান করা হয়েছে।

  • Sec-Fetch-Dest: document — মেইন বা টপ-লেভেল নেভিগেশন, যেকোনো ফ্রেমের ভেতরে নয়।
  • Sec-Fetch-Dest: iframe — অনুরোধটি একটি <iframe> এর ভেতরে লোড হচ্ছে।
  • Sec-Fetch-Dest: frame — অনুরোধটি একটি পুরনো <frame> (ফ্রেমসেট)-এর ভেতরে লোড হচ্ছে।
  • 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 পড়ে); এরপর প্রয়োজনীয় ব্যবস্থা নেওয়া যায়, যেমন সতর্কবার্তা দেওয়া বা টপ-লেভেল রিডাইরেক্ট প্রয়োগ করা। এটিই পূর্বে উল্লিখিত ফ্রেম-বাস্টিং (frame-busting) কৌশল, যা রিকোয়েস্ট হেডারে যাই থাকুক না কেন কাজ করে।

সার্ভার কনফিগ উদাহরণ: ইফ্রেম এম্বেডিং ব্লক করা

নিচের কোড স্নিপেটগুলো দেখিয়েছে কীভাবে প্রতিটি সার্ভার বা ফ্রেমওয়ার্ক কনফিগার করতে হবে, যাতে <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 });
  },
};

সম্পূর্ণ ব্লকের পরিবর্তে শুধুমাত্র আপনার নিজের সাইট বা কিছু নির্দিষ্ট ওরিজিনের তালিকাকে ফ্রেমিং অনুমতি দিতে চান? DENY এর পরিবর্তে SAMEORIGIN, এবং 'none' এর পরিবর্তে 'self' বা ওরিজিনের সুনির্দিষ্ট তালিকা ব্যবহার করুন — অবশিষ্ট কনফিগারেশনের কোনো পরিবর্তন হবে না।

পরিচিত প্ল্যাটফর্ম সতর্কতা

সাধারণ হেডার নীতিমালা বাদ দিলেও, কিছু জনপ্রিয় প্ল্যাটফর্কের নিজস্ব কিছু বৈশিষ্ট্য বা অসঙ্গতি রয়েছে। শুধুমাত্র হেডারের ভিত্তিতে "blocked" বা "embeddable" ধরে নেওয়ার আগে এগুলো জানা জরুরি।

প্ল্যাটফর্ম / পরিস্থিতি আচরণ কারণ
YouTube watch page (youtube.com/watch) ব্লক করা হয়েছে পরিবর্তে অফিশিয়াল youtube.com/embed/{id} প্লেয়ার URL ব্যবহার করুন—সাধারণ ওয়াচ পেজ একটি সীমাবদ্ধ ফ্রেমিং নীতি পাঠায়।
Google Maps place page ব্লক করা হয়েছে শুধুমাত্র ম্যাপস এম্বেড API-এর iframe URL (google.com/maps/embed) ফ্রেম করার জন্য ডিজাইন করা হয়েছে।
Google / Microsoft OAuth login pages ব্লক করা হয়েছে ২০১৫ সাল থেকে ইচ্ছাকৃতভাবে ব্লক করা হয়েছে iframes এর ভেতরে ক্রেডেনশিয়াল ফিশিং রোধ করতে; লগইন প্রবাহ অবশ্যই টপ-লেভেল উইন্ডো বা পপআপে চলতে হবে।
Payment checkout pages (Stripe Checkout, PayPal, most bank gateways) ব্লক করা হয়েছে পেমেন্ট ফর্ম ফ্রেম করা একটি ক্লাসিক ক্লিকজ্যাকিং ভেক্টর, তাই প্রসেসরগুলো সরাসরি এটি প্রত্যাখ্যান করে।
GitHub repository / file pages ব্লক করা হয়েছে সাইট-ব্যাপী frame-ancestors 'none'; iframe-এর বদলে REST/GraphQL API বা একটি স্ক্রিনশট ব্যবহার করুন।
Notion / Google Docs "Publish to web" pages এম্বেডযোগ্য এটি স্পষ্টভাবে এম্বেড করার জন্য ডিজাইন করা হয়েছে, এবং এই প্রোডাক্টটি রেডিমেড এম্বেড কোড সরবরাহ করে।
Wikipedia articles এম্বেডযোগ্য ডিফল্টভাবে কোনো সীমাবদ্ধ X-Frame-Options/CSP নেই, তবে বৃহৎ পরিসরে এম্বেড করার আগে লাইসেন্সিং এবং অ্যাট্রিবিউশন শর্তাবলী পরীক্ষা করুন।

সাধারণ ব্যবহার ক্ষেত্র

  • ইন্টিগ্রেশন কোড লিখার আগে সিদ্ধান্ত নিন যে আপনার নিজস্ব প্রোডাক্টে থার্ড-পার্টি উইজেট, ড্যাশবোর্ড, বা ডকুমেন্ট এম্বেড করা সম্ভব কিনা।
  • নিশ্চিত করুন যে আপনার নিজস্ব ওয়েবসাইট আপনি যে X-Frame-Options বা CSP frame-ancestors নীতি সেট করেছিলেন, তা সঠিকভাবে পাঠাচ্ছে।
  • ক্লিকজ্যাকিং সুরক্ষা ডিবাগ করুন: iframe-এর ভেতরে একটি পেজ কেন about:blank বা কোনো প্রত্যাখ্যানের বার্তা দেখাচ্ছে তা বোঝুন।
  • কন্টেন্ট সংকলন বা পোর্টাল ইন্টিগ্রেশনের সময় সম্ভাব্য URL-গুলো ব্যাচ স্ক্রিন করুন; সেশন হিস্টোরি ব্যবহার করে ফলাফল পুনরায় পরিদর্শন করুন।
  • বাহ্যিক নির্ভরশীলতার (external dependencies) ফ্রেমিং নীতিমালা দলিলভুক্ত করে নিরাপত্তা পর্যালোচনা বা পেনেট্রেশন টেস্টের জন্য প্রস্তুত থাকুন।

সচরাচর জিজ্ঞাসিত প্রশ্নাবলী

যে পৃষ্ঠাকে "এমবেডযোগ্য" হিসেবে চিহ্নিত করা হয়েছে, তা প্রিভিউতে কেন খালি থাকে?
Response হেডারগুলিতে ফ্রেমিংয়ের অনুমতি রয়েছে, তবে সম্ভবত পৃষ্ঠাতে জাভাস্ক্রিপ্ট ফ্রেম-বাষ্টিং কোড আছে, বা এটির জন্য লগইন/কুকিজ প্রয়োজন, অথবা ভিজিটরের ধরন অনুযায়ী ভিন্ন কন্টেন্ট সার্ভ করে। প্রিভিউয়ের ফলাফলের উপর নির্ভর করুন।
আমি কি X-Frame-Options বা CSP এড়িয়ে যেতে পারি?
না। নিরাপত্তার স্বার্থে (ক্লিকজ্যাকিং সুরক্ষা) ব্রাউজার দ্বারা এই হেডারগুলো কঠোরভাবে কার্যকর করা হয়; ক্লায়েন্ট-সাইডের কোনো বিকল্প পদ্ধতি নির্ভরযোগ্য নয়। আপনার নিয়ন্ত্রণে নয় এমন সামগ্রী এমবেড করার ক্ষেত্রে সাইট মালিককে অনুরোধ করুন frame-ancestors হেডারে আপনার অরিজিনকে (origin) অ্যালাউলিস্ট করার জন্য, অথবা তাদের প্রদত্ত আনুষ্ঠানিক embed/API সমাধানটি ব্যবহার করুন।
DENY এবং SAMEORIGIN-এর মধ্যে পার্থক্য কী?
DENY সেটিংটি সবচেয়ে কঠোর, এটি একই উৎসের পেজ সহ প্রতিটি iframe-এ পৃষ্ঠাটি প্রদর্শনে বাধা দেয়; অন্যদিকে SAMEORIGIN শুধুমাত্র একই স্কিম, হোস্ট এবং পোর্টযুক্ত পৃষ্ঠা থেকেই ফ্রেমিং অনুমতি দেয়।
এই চেকার কি আমার URL-গুলো সংরক্ষণ করে?
ইতিহাস কেবলমাত্র আপনার ব্রাউজারের ট্যাবের sessionStorage-এ সংরক্ষিত থাকে এবং ট্যাব বন্ধ হলে তা মুছে যায়। চেকিং সার্ভার শুধুমাত্র অনুরোধকৃত URL-টি fetch করে তার Response Headers পড়ে নেয়।
একই URL-টি বিভিন্ন সময়ে কেন ভিন্ন ফলাফল দেয়?
সাইটগুলো পথ (path), রিডাইরেক্টের পর, User-Agent বা A/B পরীক্ষা ও WAF নিয়মের ভিত্তিতে ভিন্ন Response Headers পাঠাতে পারে। বর্তমান অবস্থা জানতে পরীক্ষাটি পুনরায় চালান।