Pemeriksa iframe

Pemeriksa iframe dalam talian percuma: masukkan sebarang URL laman web untuk memeriksa pengepala X-Frame-Options dan Content-Security-Policy frame-ancestorsnya, ketahui sama ada halaman boleh disematkan dalam iframe, dan sahkan dengan pratonton langsung. Sejarah disimpan hanya untuk sesi pelayar semasa.

Pemeriksaan penyematan IFrame

:

Menjalankan setiap baris melalui pemeriksaan pengepala yang sama dan menambahkannya ke sejarah sesi di bawah. Terhad kepada 20 URL setiap batch, diperiksa secara siri supaya tidak membebankan laman sasaran.

Diperiksa: /
URL Keputusan HTTP

Pratonton langsung

Pemeriksaan pengepala adalah langkah pertama yang pantas, tetapi ia tidak dapat mengesan teknik pecah bingkai JavaScript (frame-busting): jika pengepala menunjukkan "Boleh Disematkan" tetapi pratonton kekal kosong, keluar dari bingkai, atau memaparkan halaman ralat, halaman tersebut tidak selamat untuk disematkan. Pratonton langsung memberikan kata akhir.

Sejarah (sesi ini)

Disimpan hanya di tab ini (sessionStorage); dikosongkan apabila anda menutup tab. Tiada data dihantar ke pelayan.

Belum ada pemeriksaan dalam sesi ini.

Bagaimana pemeriksaan berfungsi

  1. Masukkan URL sasaran dan klik Periksa. Pelayan akan memuat turun halaman sebagai permintaan iframe sebenar (berserta Sec-Fetch-Dest: iframe) dan membaca pengepala responsnya.
  2. Keputusan ditentukan berdasarkan X-Frame-Options (DENY / SAMEORIGIN menyekat pembingkaian) dan Content-Security-Policy frame-ancestors (hanya * atau templat skema yang membenarkan laman induk pihak ketiga secara bebas).
  3. URL yang sama dimuatkan dalam iframe pratonton langsung agar anda dapat mengesahkan apa yang sebenarnya dilakukan oleh pelayar, termasuk teknik pecah bingkai JavaScript yang tidak boleh dikesan oleh pengepala.

Apa yang menentukan sama ada sesuatu halaman boleh disematkan?

Kebolehan sesuatu halaman web untuk dipaparkan di dalam <iframe> pada laman lain ditentukan oleh pelayar, berdasarkan header respons yang dihantar oleh halaman tersebut. Penguji ini menjalankan pemeriksaan yang sama di sisi pelayan dan memberikan keputusan serta-merta kepada anda.

X-Frame-Options merupakan header klasik: DENY melarang pembingkaian pada setiap halaman, SAMEORIGIN hanya membolehkan halaman dari sumber asal yang sama untuk membingkainya, dan ALLOW-FROM telah dialih keluar dari pelayar moden. Apabila header ini tiada, peraturan tradisional tidak akan menaham pembingkaian.

Arahan Content-Security-Policy frame-ancestors merupakan pengganti moden. Ia menyenaraikan sumber yang dibenarkan untuk menyisipkan halaman tersebut — contohnya frame-ancestors 'self' https://example.com. Nilai * (atau skema khusus seperti https:) membolehkan mana-mana laman induk HTTPS; sebarang nilai yang lebih sempit akan menaham penyisipan pihak ketiga.

Header bukanlah faktor tunggal penentu: skrip halaman mungkin melaksanakan kod penentang pembingkaian (membandingkan top !== self dan memaksa navigasi tahap atas), dan halaman log masuk atau titik akhir yang terhad geografi mungkin bertindak balas berbeza kepada permintaan daripada pusat data. Inilah sebab mengapa setiap hasil diperiksa bersama pratonton langsung.

Panduan pantas: penyediaan pengepala respons

Jika anda memiliki tapak web ini, kawal pembingkaian secara langsung melalui header respons.

Sekat penyisipan dari mana-mana halaman

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

Pelayar akan menolak untuk memaparkan halaman dalam mana-mana <iframe> — perlindungan paling ketat melawan serangan klik-jacking.

Benarkan penyisipan hanya dari sumber asal yang sama

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

Hanya halaman yang mempunyai skema, hos dan port yang sama boleh membingkainya; laman pihak ketiga akan disekat.

Benarkan penyisipan hanya dari sumber tertentu

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

Senaraikan sumber yang dipercayai dalam frame-ancestors; sumber yang tidak disenaraikan akan disekat.

Benarkan penyisipan dari mana-mana halaman

Jangan tetapkan X-Frame-Options Content-Security-Policy: frame-ancestors *

Mana-mana laman web boleh membingkai halaman ini dalam <iframe>. Sila pertimbangkan impak keselamatan yang terlibat.

Nota: X-Frame-Options telah digantikan oleh arahan CSP frame-ancestors. Apabila kedua-duanya wujud, arahan CSP akan mengatasi — sila utamakan frame-ancestors.

Bagaimanakah pelayan mengesan permintaan berasal dari iframe?

Sejarah sekitar tahun 2020, pelayar berasaskan Chromium dan Firefox secara automatik menyertakan set header permintaan Fetch Metadata kepada setiap navigasi dan permintaan sumber subsumber. Yang paling berguna untuk semakan pembingkaian ialah Sec-Fetch-Dest — ia memberitahu pelayan konteks jenis apa yang meminta sumber tersebut, tanpa memerlukan kerjasama daripada halaman yang memintanya.

  • Sec-Fetch-Dest: document — navigasi tahap atas, tidak berada di dalam mana-mana bingkai.
  • Sec-Fetch-Dest: iframe — permintaan dimuatkan di dalam elemen <iframe>.
  • Sec-Fetch-Dest: frame — dimuatkan di dalam elemen <frame> warisan (frameset).
  • Sec-Fetch-Dest: embed / object — dimuatkan di dalam elemen <embed> atau <object>.

Pengimbas ini menghantar sondesendiri dengan `Sec-Fetch-Dest: iframe`, yang meniru secara tepat cara pelayar sebenar menghantar data semasa menyematkan halaman — maka penilaian yang diterbitkan akan memantulkan bagaimana pelayan sasaran benar-benar bertindak balas kepada permintaan iframe sebenar, bukannya sekadar permintaan `fetch` am.

`Sec-Fetch-Dest` merupakan isyarat yang berguna namun bukan satu sempadan keselamatan: ia hanya dihantar oleh pelayar moden, manakala klien selain pelayar seperti `curl`, bot, beberapa `webview` serta pelayar lama boleh mengabaikannya sepenuhnya atau menghantar sebarang nilai. Pelayan seharusnya mencatatkan log atau menetapkan had kadar (`rate-limit`) berdasarkan isyarat ini, tetapi tidak sepatutnya bergantung padanya secara tunggal untuk menentukan sama ada bingkai tersebut selamat; penentuan sedemikian tetap dikawal oleh `X-Frame-Options` dan `CSP frame-ancestors`, yang dipatuhi oleh pelayar secara merdeka daripada header permintaan.

Di pihak klien, halaman juga dapat mengesan diri ia sedang berjalan di dalam bingkai tanpa memerlukan header tertentu, contohnya dengan membandingkan `window.top !== window.self` (atau mengakses `window.frameElement` bagi bingkai ber-Asal Sama), seterusnya bertindak balas — memaparkan amaran atau memaksa pengalihan ke tetingkap utama. Ini merujuk kepada teknik `frame-busting` yang disebutkan sebelumnya, dan ia kekal berfungsi tanpa mengira kandungan header permintaan.

Contoh konfigurasi pelayan: sekatan penyematan iframe

Cuplikan kod di bawah menunjukkan cara mengkonfigurasi setiap pelayan atau kerangka kerja (framework) untuk menahan sepenuhnya penyisipan <iframe> (X-Frame-Options: DENY + CSP frame-ancestors 'none') — langkah paling ketat berbanding cadangan dalam panduan pantas di atas.

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 });
  },
};

Hanya mahu membenarkan laman web anda sendiri, atau senarai benarkan (allow-list) yang pendek, untuk membingkai halaman tersebut sambil menghalang semua yang lain? Tukarkan DENY kepada SAMEORIGIN, dan 'none' kepada 'self' atau senarai sumber spesifik — konfigurasi selebihnya kekal sama.

Nota platform penting

Di luar garis panduan header umum, sesetengah platform terkenal mempunyai kelainan atau ciri tersendiri — perkara yang perlu diketahui sebelum anda membuat andaian "diblokir" atau "boleh disematkan" hanya berdasarkan header semata-mata.

Platform / Senario Kelakuan Sebab
Halaman tonton YouTube (youtube.com/watch) Diblokir Gunakan URL pemain rasmi youtube.com/embed/{id} sebagai gantinya — halaman tonton biasa menghantar polisi pembingkaian yang restriktif.
Halaman lokasi Google Maps Diblokir Hanya URL iframe API Pemaparan Peta (`google.com/maps/embed`) yang ditetapkan untuk disematkan.
Halaman log masuk OAuth Google / Microsoft Diblokir Disekat secara sengaja sejak 2015 bagi menghalang phishing kelayakan di dalam iframe; proses log masuk wajib dijalankan di tetingkap utama atau tetingkap muat naik (pop-up).
Halaman pembayaran (Stripe Checkout, PayPal, kebanyakan gateway perbankan) Diblokir Membingkai borang pembayaran merupakan vektor klasik serangan clickjacking, maka pemproses pembayaran menolak perkara ini terus-menerus.
Halaman repositori / fail GitHub Diblokir Tetapan `frame-ancestors 'none'` diterapkan pada keseluruhan laman; gunakan API REST/GraphQL atau tangkap layar sebagai alternatif kepada iframe.
Halaman "Terbit ke Web" Notion / Google Docs Boleh Disematkan Dirangka secara khusus untuk disematkan, dan produk ini menyediakan kod sematan sedia ada.
Artikel Wikipedia Boleh Disematkan Secara lalai, tiada kekangan `X-Frame-Options` atau `CSP`; namun sila semak terma lesen dan syarat pengiktirafan kandungan sebelum menyematkannya dalam skala besar.

Kesgunaan biasa

  • Tentukan terlebih sama ada widget, papan pemuka, atau dokumen pihak ketiga boleh disematkan ke dalam produk anda sebelum bermula menulis kod integrasi.
  • Sahkan bahawa laman web anda menghantar polisi `X-Frame-Options` atau `CSP frame-ancestors` seperti yang diinginkan.
  • Nyahpepijat perlindungan klik-jacking: fahami mengapa halaman memaparkan about:blank atau mesej penolakan di dalam iframe.
  • Lakukan tapisan pukal ke atas URL calon semasa pengumpulan kandungan atau integrasi portal, guna sejarah sesi untuk menyemak semula hasil.
  • Sedia untuk semakan keselamatan atau ujian penembusan dengan mendokumentasikan dasar pembingkaian bagi kebergantungan luaran.

Soalan Lazim (FAQ)

Mengapa halaman yang dinyatakan sebagai "Boleh Disematkan" kekal kosong dalam pratonton?
Header respons membolehkan pembingkaian, tetapi halaman tersebut mungkin mempunyai kod 'frame-busting' dalam JavaScript, memerlukan log masuk atau kuki, atau memaparkan kandungan berbeza bergantung kepada pelawat. Hasil pratonton boleh dipercayai.
Bolehkah saya memintas header X-Frame-Options atau CSP?
Tidak. Header ini dikuatkuasakan oleh pelayarweb untuk tujuan keselamatan (perlindungan daripada klik-jacking); langkah sampingan di sisi klien adalah tidak boleh dijamin. Untuk menyematkan kandungan yang anda tidak mengawalnya, sila hubungi pemilik laman web untuk menambah 'asal' anda dalam senarai benarkan pada arahan `frame-ancestors`, atau gunakan solusi embed/API rasmi yang disediakan oleh mereka.
Apakah perbezaan antara DENY dan SAMEORIGIN?
`DENY` menyekat halaman daripada dimuatkan dalam mana-mana iframe, termasuk halaman yang berkongsi asal yang sama; manakala `SAMEORIGIN` hanya membenarkan pembingkaian jika halaman pengundang berasal daripada skema, hos dan port yang sama.
Adakah alat semakan ini menyimpan URL anda?
Sejarah hanya disimpan dalam tab pelayarweb anda sahaja melalui `sessionStorage` dan akan terpadam apabila tab ditutup. Pelayan semakan hanya menghantar permintaan kepada URL tersebut untuk membaca header responsnya.
Mengapa satu URL yang sama boleh memberikan hasil berbeza pada waktu yang berlainan?
Sesebuah laman web mungkin menghantar header yang berbeza bergantung kepada laluan, selepas melakukan redirect, mengikut User-Agent, atau berdasarkan percubaan A/B dan peraturan WAF. Sila jalankan semakan semula untuk melihat status terkini.