Semakan keselamatan laman web tanpa menggodam apa-apa

Semakan keselamatan pasif bagi kedai dalam talian: tamat tempoh sijil TLS, HSTS, CSP, nosniff, bendera kuki, kandungan bercampur, jQuery lapuk, security.txt, DMARC.

Pasukan Editorial FixReportsBacaan 10 minit

Anda boleh menyemak banyak aspek persediaan keselamatan kedai dalam talian dari luar, hanya dengan membaca apa yang sudah dihantar oleh laman web itu kepada setiap pelawat: sijil TLS, ubah hala, pengepala respons HTTP, kuki, skrip yang dimuatkan dan rekod DNS awamnya. Semakan pasif ini tidak menghantar trafik serangan dan tidak memerlukan log masuk, jadi bebannya pada kedai tidak lebih daripada satu lawatan biasa. Semakan ini mengesan jurang konfigurasi seperti sijil yang hampir tamat tempoh, HSTS yang tiada, kuki yang tidak selamat, kandungan bercampur (mixed content) atau versi jQuery yang mempunyai kelemahan yang diketahui. Ia bukan ujian penembusan dan tidak dapat membuktikan bahawa sesebuah kedai selamat.

Perkara utama

  • Sijil TLS yang dipercayai umum dan dikeluarkan sejak 15 Mac 2026 boleh sah paling lama 200 hari, menurun kepada 100 hari pada Mac 2027 dan 47 hari pada Mac 2029 (CA/Browser Forum (dibuka dalam tab baharu)).
  • Pelayar mengabaikan pengepala HSTS apabila ia dihantar melalui HTTP biasa (MDN (dibuka dalam tab baharu)).
  • Arahan CSP frame-ancestors tidak berfungsi dalam tag <meta>; ia mesti dihantar sebagai pengepala respons (MDN (dibuka dalam tab baharu)).
  • Versi jQuery sebelum 3.5.0 terjejas oleh dua kerentanan XSS, dan CISA menambah salah satu daripadanya, CVE-2020-11023, ke dalam katalog Known Exploited Vulnerabilities pada 23 Januari 2025 (NVD (dibuka dalam tab baharu)).
  • Fail security.txt mesti mengandungi medan Contact dan Expires dan diletakkan di /.well-known/security.txt (RFC 9116 (dibuka dalam tab baharu)).

Apakah yang dikira sebagai semakan keselamatan pasif?

Semakan pasif hanya membaca apa yang dikembalikan oleh laman web atau DNSnya kepada permintaan biasa.

Ini bermakna memuatkan halaman awam, membaca sijil dan pengepala respons, menyenaraikan kuki dan skrip yang ditetapkan oleh sesuatu halaman, dan membuat pertanyaan rekod DNS awam. Semakan pasif tidak meneka kata laluan, menghantar muatan suntikan (injection payload), menguji URL admin atau mengimbas port. Semua yang diterangkan di bawah boleh dilakukan dengan pelayar, curl, openssl dan dig.

Bagaimanakah cara menyemak sijil TLS anda dan tarikh tamat tempohnya?

Baca tarikh dan nama pada sijil secara terus, dan pastikan pembaharuan sijil dibuat secara automatik.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Pastikan notAfter masih jauh pada masa hadapan, sijil itu meliputi kedua-dua example.com dan www.example.com jika anda menggunakan kedua-duanya (pemapar sijil dalam pelayar menyenaraikan nama-nama itu), dan pelayar tidak memaparkan sebarang amaran. Jangka hayat sijil semakin pendek di bawah Baseline Requirements CA/Browser Forum (seksyen 6.3.2, versi 2.3.1 setakat Oktober 2026), susulan Ballot SC-081v3 (dibuka dalam tab baharu) yang diterima pakai pada 11 April 2025:

Sijil dikeluarkanTempoh sah maksimum
Sebelum 15 Mac 2026398 hari
15 Mac 2026 hingga 14 Mac 2027200 hari
15 Mac 2027 hingga 14 Mac 2029100 hari
Mulai 15 Mac 202947 hari

Jangka hayat yang pendek menjadikan pembaharuan manual berisiko, jadi pastikan hos atau alat sijil anda memperbaharui sijil secara automatik. Pastikan juga HTTP biasa diubah hala ke HTTPS:

curl -sI http://example.com/ | grep -i -E "^HTTP|^location"

Respons yang anda mahukan ialah 301 (atau 308) dengan pengepala location yang bermula dengan https://.

Pengepala keselamatan manakah yang patut dihantar oleh kedai dalam talian?

Sebilangan kecil pengepala respons dapat menyekat serangan biasa di sebelah pelayar dengan kos yang hampir tiada.

PengepalaFungsiNilai biasaSumber
Strict-Transport-SecurityMemberitahu pelayar supaya menggunakan HTTPS sahaja dan menghalang pengguna mengklik untuk melepasi ralat sijilmax-age=31536000; includeSubDomainsMDN (dibuka dalam tab baharu)
Content-Security-Policy: frame-ancestorsMengawal laman mana yang boleh membenamkan halaman anda, sebagai pertahanan terhadap clickjackingframe-ancestors 'self'MDN (dibuka dalam tab baharu)
X-Frame-OptionsKawalan pembingkaian yang lebih lama; OWASP menyatakan frame-ancestors menggantikannya dalam pelayar yang menyokongnyaDENY atau SAMEORIGINOWASP (dibuka dalam tab baharu)
X-Content-Type-OptionsMenghentikan MIME sniffing dan menyekat skrip serta helaian gaya yang dihantar dengan jenis yang salahnosniffMDN (dibuka dalam tab baharu)
Referrer-PolicyMengehadkan sejauh mana URL anda dihantar ke laman lainstrict-origin-when-cross-originOWASP
X-XSS-ProtectionPengepala penapis XSS pelayar; OWASP menyatakan ia boleh mewujudkan kerentanan XSS pada laman yang sebenarnya selamatJangan tetapkan, atau 0OWASP

Semak pengepala yang dihantar oleh kedai anda:

curl -sI https://example.com/

Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: frame-ancestors 'self'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

Dua peringatan. includeSubDomains menyekat mana-mana subdomain yang hanya berfungsi melalui HTTP, jadi semak subdomain anda dahulu. Pramuat HSTS (HSTS preloading) memerlukan max-age sekurang-kurangnya 31536000 dan includeSubDomains, jadi hanya tambah preload apabila setiap subdomain sudah bersedia untuk HTTPS. CSP penuh yang mengehadkan skrip memang berbaloi, tetapi OWASP menyatakan ia rumit untuk dikonfigurasi dan diselenggara, dan kedai yang menggunakan banyak aplikasi perlu mengujinya dengan teliti.

Adakah kuki anda ditetapkan dengan Secure, HttpOnly dan SameSite?

Kuki sesi dan troli patut mempunyai ketiga-tiga atribut ini, dan anda boleh melihatnya dalam pengepala respons Set-Cookie.

AtributKesan (menurut MDN (dibuka dalam tab baharu))Bila ia penting
SecureDihantar hanya melalui HTTPS; laman pada HTTP biasa tidak boleh menetapkannyaSetiap kuki pada kedai HTTPS
HttpOnlyJavaScript tidak boleh membacanya melalui document.cookie, yang membantu menangkis XSSSesi log masuk dan troli
SameSite=Lax atau StrictMengehadkan bila kuki dihantar pada permintaan merentas lamanSesi; Strict sesuai untuk kuki pengesahan dan troli
SameSite=NoneDihantar pada permintaan merentas laman; mesti digabungkan dengan SecureHanya ciri pihak ketiga terbenam yang memerlukannya

Jika tiada atribut SameSite ditetapkan, pelayar menganggap kuki itu sebagai Lax. Kuki yang perlu dibaca oleh skrip anda sendiri tidak boleh ditetapkan sebagai HttpOnly, jadi tumpukan pada kuki yang mengenal pasti pelanggan atau admin yang sedang log masuk.

curl -sI https://example.com/ | grep -i "^set-cookie"

Alat pembangun (developer tools) dalam pelayar menunjukkan maklumat yang sama, termasuk kuki yang ditetapkan oleh skrip selepas halaman dimuatkan.

Bagaimanakah cara mencari kandungan bercampur?

Kandungan bercampur ialah sebarang sumber yang dimuatkan melalui HTTP pada halaman yang dihidangkan melalui HTTPS, dan konsol pelayar menyenaraikannya.

MDN (dibuka dalam tab baharu) membahagikannya kepada dua kumpulan. Imej, audio dan video boleh “dinaik taraf” (upgradable): pelayar memintanya melalui HTTPS secara automatik. Skrip, helaian gaya, iframe, fon dan permintaan fetch() boleh “disekat” (blockable): pelayar menyekatnya, dan ini merosakkan apa-apa yang bergantung padanya. Permintaan yang dinaik taraf ke alamat IP terus (tanpa nama domain) juga disekat.

Untuk mencarinya, buka konsol pada templat utama anda (halaman utama, koleksi, produk, troli) dan cari http:// dalam kod tema, kandungan halaman dan tetapan aplikasi. Pusat bantuan Shopify menyatakan bahawa mana-mana halaman kedai yang mempunyai aset yang tidak dihantar melalui HTTPS dianggap tidak selamat (dibuka dalam tab baharu), dan mengesyorkan agar aset dihoskan di Shopify atau dihidangkan melalui HTTPS. Di WooCommerce, semak kandungan catatan lama dan pilihan tema jika laman itu pernah berjalan pada http://.

Bagaimanakah cara mengesan pustaka JavaScript lapuk yang mempunyai CVE yang diketahui?

Senaraikan pustaka yang dimuatkan oleh setiap halaman, baca versinya, dan bandingkan dengan National Vulnerability Database (NVD).

Mulakan dengan jQuery. Dalam konsol pelayar, $.fn.jquery mengembalikan versi yang dimuatkan (jQuery API (dibuka dalam tab baharu)). Versi yang perlu diberi perhatian:

CVEVersi terjejasIsuSkor NVD (v3.1)
CVE-2020-11022 (dibuka dalam tab baharu)1.12.0 hingga sebelum 3.5.0Menghantar HTML yang tidak dipercayai kepada kaedah seperti .html() atau .append() boleh menjalankan kod6.1 Sederhana
CVE-2020-11023 (dibuka dalam tab baharu)1.0.3 hingga sebelum 3.5.0Sama, untuk HTML yang mengandungi elemen <option>; dalam katalog KEV CISA sejak 23 Januari 20256.1 Sederhana
CVE-2019-11358 (dibuka dalam tab baharu)Sebelum 3.4.0Pencemaran prototaip (prototype pollution) melalui jQuery.extend(true, ...)6.1 Sederhana

Kedua-dua isu 2020 telah dibaiki dalam jQuery 3.5.0. Versi yang terdedah bermakna kod yang cacat itu wujud; sama ada ia boleh dieksploitasi bergantung pada cara laman web menghantar data kepadanya. WordPress telah menyertakan jQuery 3.5.1 sejak versi 5.6 (dibuka dalam tab baharu), jadi jQuery lama pada kedai WooCommerce menunjukkan WordPress yang lapuk, atau tema atau pemalam yang memuatkan salinannya sendiri. Di Shopify, semak fail tema anda dan aplikasi yang menyuntik skrip.

Apakah security.txt dan adakah kedai anda memerlukannya?

Ia ialah fail teks biasa yang memberitahu penyelidik keselamatan cara melaporkan kerentanan kepada anda.

RFC 9116 (dibuka dalam tab baharu) (April 2022, sebuah RFC bertaraf Informational, jadi mematuhinya adalah sukarela) menyatakan fail itu mesti dihidangkan melalui HTTPS di /.well-known/security.txt sebagai text/plain. Contact dan Expires adalah wajib, dan RFC itu mengesyorkan tarikh Expires kurang daripada setahun ke hadapan.

Contact: mailto:security@example.com
Expires: 2027-09-30T23:00:00.000Z
Preferred-Languages: en
Policy: https://example.com/security-policy

Di WooCommerce, anda boleh meletakkan fail itu pada pelayan anda. Pada platform yang dihoskan, semak sama ada anda boleh menerbitkan fail pada laluan itu; jika tidak, maklumat hubungan keselamatan yang dilabel dengan jelas pada halaman hubungi anda tetap membantu.

Bagaimanakah DMARC melindungi kedai anda daripada pemalsuan e-mel?

DMARC membolehkan anda meminta penyedia peti mel mengkuarantin atau menolak e-mel yang menggunakan domain anda dalam alamat From tanpa lulus SPF atau DKIM yang sejajar.

Rekod pada p=none hanya mengumpul laporan; ia tidak menghentikan e-mel palsu. Pelanggan menjangkakan e-mel pengesahan pesanan dan tetapan semula kata laluan daripada domain anda, jadi mesej pancingan data (phishing) yang memaparkan domain anda yang sebenar wajar disekat. Semak dasar anda dengan dig +short TXT _dmarc.example.com, dan rujuk RFC 9989 (dibuka dalam tab baharu) untuk spesifikasinya. DMARC tidak meliputi domain tiruan yang hampir serupa, hanya domain yang menerbitkan rekod itu.

Apakah yang diuruskan oleh Shopify, dan apakah yang anda kawal di WooCommerce?

Shopify mengendalikan pelayan di sebalik kedai dalam taliannya, manakala kedai WooCommerce yang dihoskan sendiri menyerahkan tetapan pelayan kepada anda dan hos anda.

SemakanShopifyWooCommerce (dihoskan sendiri)
Sijil TLSPercuma untuk semua domain yang ditambah ke Shopify (dibuka dalam tab baharu); mungkin mengambil masa sehingga 48 jam untuk domain pihak ketigaHos anda atau persediaan anda sendiri
Ubah hala HTTP ke HTTPSPlatformTetapan pelayan web, CDN atau hos
Pengepala keselamatanDihantar oleh pelayan ShopifyPelayan web, CDN atau pemalam
Bendera kukiKuki Shopify sendiri ditetapkan oleh platform; kuki aplikasi dan tema ialah tanggungjawab andaTeras WordPress, pemalam dan pelayan
Kandungan bercampur dan pustaka JSTema, kandungan dan aplikasi andaTema, kandungan dan pemalam anda
security.txt dan DMARCDomain dan DNS andaDomain dan DNS anda

Apabila kami menyemak beberapa kedai yang dihoskan oleh Shopify pada Oktober 2026, respons mereka termasuk HSTS dengan max-age kira-kira 91 hari, X-Content-Type-Options: nosniff dan CSP dengan upgrade-insecure-requests, manakala frame-ancestors berbeza antara kedai. Shopify menyatakan ia diperakui mematuhi PCI DSS Tahap 1 (dibuka dalam tab baharu). Tema dan aplikasi yang anda pasang kekal menjadi tanggungjawab anda.

Di WooCommerce, panduan pengukuhan (dibuka dalam tab baharu) WordPress menyarankan agar WordPress dan pemalam sentiasa dikemas kini, pemalam yang tidak digunakan dipadam, dan anda bertanya kepada hos anda tentang langkah keselamatan yang mereka ambil.

Mengapakah ini bukan ujian penembusan?

Ujian penembusan secara aktif mencuba serangan; semakan pasif hanya memerhati.

NIST SP 800-115 mentakrifkan ujian penembusan sebagai ujian keselamatan yang mana penilai meniru serangan dunia sebenar untuk mencari cara memintas ciri keselamatan sesuatu sistem (glosari NIST (dibuka dalam tab baharu)). Semakan pasif tidak dapat melihat kelemahan di sebelah pelayan dalam pemalam, kata laluan admin yang lemah atau digunakan semula, pengesahan dua faktor yang tidak diaktifkan, kawalan akses yang rosak atau kod terdedah yang tidak pernah muncul dalam sumber halaman. Gunakan semakan ini sebagai garis dasar yang boleh anda ulang pada bila-bila masa. Untuk jaminan yang lebih mendalam, dapatkan ujian penembusan dengan skop bertulis, pada sistem yang anda miliki atau yang anda diberi kebenaran untuk menguji.

Imbasan percuma menjalankan semakan awal pada kedai anda. Laporan Keselamatan Laman Web meliputi semakan pasif dalam artikel ini, daripada TLS dan ubah hala hingga pengepala, kuki, kandungan bercampur, pustaka lapuk, security.txt dan DMARC, beserta pembaikan untuk setiap penemuan. Seperti mana-mana semakan pasif, ia tidak dapat menjamin bahawa sesebuah kedai selamat.

Soalan lazim

Adakah semakan keselamatan pasif membahayakan kedai saya?

Tidak lebih daripada lawatan biasa. Semakan ini meminta halaman awam dan rekod DNS yang sama seperti mana-mana pelayar atau pelayan mel, dan tidak cuba log masuk atau menghantar muatan serangan.

Bolehkah saya menambah pengepala keselamatan di Shopify?

Pengepala respons kedai datang daripada pelayan Shopify, jadi hubungi Sokongan Shopify jika pengepala yang anda perlukan tiada. Tag CSP <meta> dalam tema anda boleh menambah sesetengah arahan, tetapi MDN menyatakan bahawa frame-ancestors tidak disokong dalam <meta>.

Adakah versi jQuery lama bermakna kedai saya telah digodam?

Tidak. Ia bermakna kod yang mempunyai kerentanan yang diketahui sedang dimuatkan, dan ini meningkatkan risiko jika laman web menghantar HTML yang tidak dipercayai kepada kaedah yang terjejas. Kemas kini jQuery, atau buang tema atau pemalam yang memuatkannya.

Berapa lamakah tempoh sah maksimum sijil TLS sekarang?

Sijil yang dipercayai umum dan dikeluarkan mulai 15 Mac 2026 boleh sah paling lama 200 hari. Had ini menurun kepada 100 hari mulai 15 Mac 2027 dan 47 hari mulai 15 Mac 2029.

Adakah fail security.txt diwajibkan?

RFC 9116 ialah RFC bertaraf Informational, jadi menerbitkan fail ini adalah sukarela di bawah piawaian tersebut. Kosnya rendah untuk diterbitkan dan ia memberi penyelidik cara yang jelas untuk menghubungi anda.

Adakah imbasan pasif yang bersih bermakna kedai saya selamat?

Tidak. Ia hanya menunjukkan bahawa konfigurasi awam kelihatan betul. Kerentanan di sebelah pelayan, keselamatan akaun dan kelemahan logik perniagaan memerlukan jenis ujian lain.

Sumber

Semua panduan