Mengamankan skrip dan perubahan halaman pembayaran

Apa yang perlu dilindungi pada checkout?

Periksa halaman yang diterima browser pembeli, bukan hanya kode yang tersimpan di server. Skrip tambahan dapat masuk melalui tag manager, layanan analitik, widget bantuan atau perubahan integrasi pembayaran. Halaman tanpa perubahan kode aplikasi pun dapat berubah perilakunya.

Pengantar resmi PCI SSC menjelaskan tujuan 6.4.3 dan 11.6.1: mengelola otorisasi serta integritas skrip dan mendeteksi perubahan yang tidak sah pada skrip maupun header yang memengaruhi keamanan. Suplemen memberi arahan tambahan, bukan mengganti standar atau menetapkan bahwa satu alat pasti patuh.

Panduan ini memakai penjelasan publik penerbit. Rincian persyaratan, pengujian dan frekuensi harus diperiksa terhadap naskah standar serta program validasi yang berlaku pada integrasi Anda.

Pastikan pola pembayaran dan pembagian tanggung jawab

Mulai dari panduan payment gateway. Gambarkan halaman toko, formulir penyedia, skrip dan pihak yang dapat mengubah masing-masing bagian. Nama gateway belum menentukan lingkup.

FAQ 1588 membedakan kriteria skrip SAQ A pada halaman dengan formulir penyedia tertanam, misalnya iframe, dari redirect atau pembayaran yang dialihkan seluruhnya. Konfirmasi dapat melalui teknik perlindungan yang sesuai atau konfirmasi penyedia patuh PCI DSS atas solusi yang dipasang sesuai instruksinya. Tetap periksa seluruh kelayakan SAQ dengan pihak penerima validasi.

Pemindaian ASV merupakan pekerjaan berbeda. FAQ 1604 juga membahas halaman merchant yang memakai redirect atau iframe. Jangan menganggap pengecualian kriteria tertentu menghapus semua pekerjaan keamanan.

Buat inventaris dari halaman yang benar-benar berjalan

Gunakan lingkungan uji dan data uji penyedia; jangan memasukkan nomor kartu pelanggan ke bukti. Periksa variasi checkout yang memang digunakan, misalnya pengguna login/tamu, perangkat berbeda serta keadaan pilihan cookie. Sebutkan variasi yang belum diuji.

Isi inventaris skrip pembayaran dengan skrip internal, pihak ketiga dan skrip inline yang ditemukan. Catat halaman, asal, tujuan, versi atau identitas, pemilik, persetujuan serta referensi hasil pemeriksaan. Domain yang sama dapat menyediakan beberapa skrip dengan pekerjaan berbeda.

Jika tag manager memuat skrip lanjutan, catat rantai pemuatan dan siapa yang memiliki hak publikasi. Menulis satu baris “tag manager” tanpa memeriksa hasil pemuatannya menyisakan pekerjaan yang belum diketahui.

Putuskan skrip mana yang diperlukan

Contoh fiktif checkout dengan iframe penyedia:

Temuan	Keputusan kerja contoh
Skrip integrasi penyedia	Periksa instruksi, versi dan pembagian tanggung jawab sebelum menyetujui pemasangan.
Analitik umum toko	Tanyakan apakah perlu berjalan di checkout; uji dampak jika dinonaktifkan hanya pada halaman tersebut.
Widget bantuan lama	Tujuan dan pemilik tidak ditemukan; tunda persetujuan dan periksa cara melepasnya tanpa merusak alur.
Skrip baru dari tag manager	Bandingkan dengan perubahan yang disetujui; eskalasikan bila tidak ada izin.

Persetujuan harus merujuk keadaan dan penggunaan tertentu. Izin memakai domain vendor tidak dengan sendirinya menjelaskan setiap skrip yang dimuatnya. Simpan alasan keputusan, termasuk pengecualian yang masih harus diselesaikan.

Periksa integritas dan batas teknik yang dipakai

Integritas membantu mengetahui apakah kode sesuai versi yang dipercaya. Pilih cara pemeriksaan bersama pengembang dan penyedia, lalu uji pada keadaan checkout yang relevan. Catat apakah skrip tetap, berubah dinamis atau memuat komponen lanjutan.

Content Security Policy (CSP) dapat membatasi pemuatan atau eksekusi sesuai kebijakan browser. Mode report-only mengirim laporan tanpa memblokir; jangan menghitungnya sebagai penolakan yang sudah berjalan. CSP adalah lapisan pengamanan, bukan hasil validasi PCI dengan sendirinya.

Tidak ada contoh konfigurasi yang langsung aman untuk semua gateway. Perubahan kebijakan yang belum diuji dapat mengganggu pembayaran. Siapkan pengujian dan cara pemulihan bersama pihak yang memahami integrasi.

Uji deteksi perubahan sampai ditangani

Sepakati kondisi pembanding yang disetujui. Dalam lingkungan uji, buat perubahan terkontrol: menambah skrip latihan, mengubah skrip, menghapusnya, atau mengubah header yang dipantau. Periksa apakah peringatan menunjukkan halaman, waktu dan perubahan yang benar, serta sampai kepada petugas.

Contoh catatan fiktif: peringatan muncul setelah skrip latihan ditambah, tetapi masuk ke inbox tim yang sudah tidak dipakai. Statusnya masih terbuka. Tim memperbaiki penerima, mengulangi uji, lalu mencatat penerimaan dan keputusan petugas. Peringatan yang dibuat alat saja belum membuktikan alur tindak lanjut bekerja.

Pantauan file server dapat melewatkan perubahan di browser akibat skrip pihak ketiga. Jelaskan titik pengamatan, variasi yang dicakup, kegagalan pemantauan dan keterbatasannya. Tetapkan jadwal sesuai persyaratan yang benar-benar berlaku; halaman ini tidak menetapkan frekuensi universal.

Bukti apa yang disimpan?

Simpan inventaris, persetujuan, instruksi pemasangan, versi pembanding, hasil uji dan tindak lanjut perubahan. Gunakan referensi yang dapat dibuka petugas berwenang, tanpa data kartu atau rahasia integrasi.

Periksa kembali setelah checkout, tag manager, penyedia atau skrip berubah. Bawa hal yang belum jelas ke penyedia dan pihak yang menerima validasi PCI. Inventaris terisi dan uji contoh yang berhasil bukan bukti seluruh persyaratan PCI DSS telah dipenuhi.