Viết plugin WordPress bằng Claude Code an toàn

Trả lời nhanh: Agent viết plugin WordPress rất nhanh, nhưng nó hay bỏ đúng ba thứ khiến plugin thành lỗ hổng: kiểm tra quyền người dùng, kiểm tra nonce cho mọi thao tác ghi, và làm sạch dữ liệu vào ra. Cách xử lý không phải là tự viết lại tất cả, mà là đặt ba điều đó thành luật bắt buộc trong file quy ước của dự án rồi rà lại đúng ba điểm ấy trước khi kích hoạt. Thêm một nguyên tắc: luôn thử trên bản nháp của trang, không thử trên trang đang chạy thật.

WordPress dễ mở rộng tới mức ai cũng viết được plugin, và đó vừa là điểm mạnh vừa là lý do nhiều trang bị chiếm quyền. Khi để agent viết, tốc độ tăng lên nhưng loại lỗi vẫn y hệt lỗi mà người mới hay mắc. Bài này chỉ ra chính xác chỗ cần siết và cách siết bằng luật thay vì bằng trí nhớ.

Ba lỗ hổng agent hay tạo ra

Không kiểm tra quyền. Agent viết một điểm cuối quản trị rồi quên hỏi xem người gọi có quyền không. Kết quả là bất kỳ ai đã đăng nhập, kể cả tài khoản khách vừa đăng ký, cũng gọi được chức năng quản trị.

if (!current_user_can('manage_options')) {    wp_die('Ban khong co quyen thuc hien thao tac nay');}

Không kiểm tra nonce. Thiếu bước này thì trang khác có thể lừa trình duyệt của quản trị viên gửi yêu cầu thay đổi dữ liệu mà chủ trang không hề hay biết.

check_admin_referer('luu_cai_dat_plugin');

Không làm sạch dữ liệu. Dữ liệu người dùng nhập phải được làm sạch khi lưu và thoát ký tự khi hiển thị. Bỏ bước hiển thị là mở đường cho mã độc chèn vào trang.

$ten = sanitize_text_field($_POST['ten'] ?? '');echo esc_html($ten);

Ba đoạn trên trông đơn giản, và đó chính là vấn đề: chúng dễ tới mức người ta cho rằng agent chắc chắn nhớ, trong khi thực tế nó bỏ qua rất thường xuyên khi tập trung vào phần chức năng chính.

Biến ba điều đó thành luật

Đừng nhắc bằng miệng ở mỗi lần yêu cầu, hãy ghi vào file quy ước của dự án như hướng dẫn ở bài CLAUDE.md:

# Luật cho plugin này - Mọi hàm xử lý form quản trị phải gọi current_user_can trước tiên- Mọi thao tác ghi phải kiểm tra nonce- Dữ liệu vào phải sanitize, dữ liệu ra phải escape- Dùng $wpdb->prepare cho mọi truy vấn có tham số- Tiền tố tất cả hàm và tùy chọn bằng tên plugin, tránh đụng plugin khác ## Không được làm- Không sửa file trong wp-content/plugins của plugin khác- Không thay đổi tùy chọn hệ thống của WordPress- Không gọi API bên ngoài khi chưa được duyệt

Ba dòng cấm cuối quan trọng không kém phần luật. Agent đang sửa một plugin mà gặp lỗi ở plugin khác thì rất hay tự tiện sang sửa, và đó là kiểu thay đổi bay mất ngay lần cập nhật kế tiếp.

Dùng hàm sẵn có thay vì truy vấn thẳng

WordPress có sẵn hàm cho gần như mọi việc, và các hàm đó đã xử lý bộ nhớ đệm cùng quyền hạn. Agent thì hay viết truy vấn thẳng vì như vậy ngắn hơn.

// Nen dung$bai = get_posts(['post_type' => 'san_pham', 'numberposts' => 10]); // Chi khi that su can, va bat buoc dung prepare$rows = $wpdb->get_results($wpdb->prepare(    "SELECT ID FROM {$wpdb->posts} WHERE post_type = %s LIMIT %d",    'san_pham', 10));

Hai lý do thực dụng để ưu tiên hàm có sẵn: chúng đi qua tầng bộ nhớ đệm nên nhẹ hơn cho database, và chúng không phụ thuộc vào cấu trúc bảng vốn có thể đổi giữa các phiên bản. Khi trang chậm mà bạn nghi truy vấn, cách chẩn đoán nằm ở bài WordPress chậm.

Thử ở đâu cho an toàn

Nguyên tắc không thương lượng: plugin mới không bao giờ được kích hoạt lần đầu trên trang đang phục vụ khách. Một lỗi cú pháp thôi cũng đủ làm trắng cả trang, và nếu lỗi nằm trong hàm chạy sớm thì bạn mất luôn đường vào trang quản trị.

Ba cách dựng chỗ thử, từ nhẹ tới đầy đủ:

• Máy cá nhân với môi trường đóng gói sẵn theo bài devcontainer. Nhanh nhất để thử logic.
• Bản nháp trên máy chủ, tức một bản sao của trang thật với dữ liệu tương tự. Đây là nơi phát hiện xung đột với các plugin đang cài, thứ mà máy cá nhân sạch sẽ không lộ ra.
• Máy chủ riêng cho khâu thử, hợp khi đội có nhiều người và cần thử song song.

Cách dựng bản nháp nằm ở bài riêng trong cụm này. Nếu bạn dùng bản sao dữ liệu thật, nhớ xóa hoặc che thông tin cá nhân của khách trước khi đưa lên môi trường thử.

Danh mục rà soát trước khi kích hoạt

Bốn điểm, làm mất vài phút và chặn được phần lớn rủi ro:

1. Tìm mọi chỗ đọc dữ liệu gửi lên, xem ngay phía trên có kiểm tra quyền và nonce chưa.
2. Tìm mọi chỗ hiển thị dữ liệu, xem có thoát ký tự không.
3. Tìm mọi truy vấn thẳng, xem có dùng hàm chuẩn bị tham số không.
4. Xem danh sách file plugin đã đụng vào, phải nằm trọn trong thư mục của plugin bạn đang làm.

Có thể nhờ chính agent chạy phần rà soát này trong một phiên riêng, chỉ đọc chứ không sửa, rồi báo cáo bằng danh sách đường dẫn kèm số dòng. Cách tách việc đó nằm ở bài về subagent. Nhưng kết luận cuối vẫn là của bạn, vì đây là phần quyết định trang có bị chiếm hay không.

Ba lỗ hổng công cụ tự động hay tạo ra

Bốn thứ này là bốn thứ mà công cụ tự động hay bỏ sót nhất, vì chúng không ảnh hưởng tới việc mã chạy được hay không. Mã vẫn chạy đúng, chỉ là có lỗ hổng. Đây là lý do phải đọc lại trước khi kích hoạt.

Biến bốn điều đó thành luật

# Dat trong file luat cua du an, tro ly doc moi lan lam viec - Moi ham xu ly hanh dong phai kiem quyen nguoi dung o dong dau tien- Moi bieu mau phai sinh ma chong gia mao, va moi ham xu ly phai kiem ma do- Moi truy van co so du lieu phai dung ham chuan bi co tham so,  khong duoc ghep chuoi- Moi du lieu in ra trang phai duoc loc bang ham chuan- Khong ghi truc tiep vao bang cua WordPress, dung ham co san- Khong sua file loi WordPress hay file cua giao dien mua san

Soi từng hàm xử lý trước khi bật

1. Đọc từng hàm xử lý hành động, kiểm có kiểm quyền và mã chống giả mạo không.
2. Tìm mọi chỗ ghép chuỗi vào truy vấn. Đây là việc năm phút và chặn được lỗ hổng nghiêm trọng nhất.
3. Kiểm mọi chỗ in dữ liệu ra trang đã lọc chưa.
4. Chạy trên môi trường thử trước, với dữ liệu giả, không bao giờ thử trên trang đang chạy thật.
5. Sao lưu trước khi kích hoạt trên trang thật, và kích hoạt vào khung giờ ít khách.

Bản sao riêng với khóa thanh toán chế độ thử

Môi trường thử phải là một bản sao riêng, cơ sở dữ liệu riêng, và khóa thanh toán ở chế độ thử. Thử trên trang thật với lý do chỉ thử một chút là nguyên nhân của phần lớn sự cố nghiêm trọng trong các dự án WordPress. Xem bài về tùy biến WooCommerce an toàn.