PHP 8 + PDO: Xây dựng bộ lọc tìm kiếm động thế nào để vẫn an toàn SQL?

Bạn có thể dùng prepared statement cho các giá trị lọc như status, author và date, truyền tham số vào placeholder để tránh injection. Với ORDER BY và LIMIT, không thể bind trực tiếp, nên tạo danh sách whitelist các cột được phép sắp xếp và chỉ cho phép chúng trong chuỗi. Ví dụ, nếu người dùng chọn sắp xếp theo 'created_at' và 'DESC', bạn concat chuỗi 'ORDER BY created_at DESC' sau khi kiểm tra. Đối với LIMIT, dùng placeholder cho số và bind tham số. Cách này vừa an toàn, vừa dễ bảo trì. Bạn đang áp dụng lọc nào nhất để test?

Bạn có thể giữ an toàn bằng cách chỉ sử dụng các tham số cho các giá trị, trong khi vẫn kiểm soát các phần có thể thay đổi của câu lệnh. Tạo một mảng các điều kiện `WHERE` riêng biệt, mỗi điều kiện sử dụng một tên vị trí (`:status`, `:author`, …). Chỉ thêm một điều kiện vào danh sách khi người dùng cung cấp giá trị cho nó, sau đó nối chúng bằng `AND`. Truyền toàn bộ mảng đến `PDO::execute()` – PDO sẽ tự động ánh xạ từng giá trị vào vị trí tương ứng. Đối với `ORDER BY` và `LIMIT`, bạn không bao giờ nên tham số hóa tên cột. Thay vào đó, hãy xác thực trước: định nghĩa một mảng các cột được phép sắp xếp và một danh sách các toán tử sắp xếp được phép (ví dụ: `ASC`, `DESC`). Sử dụng giá trị đã chọn từ mảng đó trong câu lệnh, đảm bảo rằng nó không bao gồm dữ liệu từ người dùng. Cuối cùng, hãy đóng gói logic này trong một hàm nhỏ (hoặc sử dụng một bộ tạo truy vấn đơn giản) để việc bảo trì trở nên dễ dàng hơn. Điều này giúp bạn có được các truy vấn động, có thể tái sử dụng mà vẫn đảm bảo an toàn. Bạn có cần xử lý các giá trị `IN` cho bất kỳ bộ lọc nào không, hoặc có bất kỳ quy tắc đặc biệt nào về ngày tháng không?

Cảm ơn admin đã chia sẻ cách tiếp cận chuẩn chỉnh. Việc tách biệt logic xây dựng câu truy vấn (chuỗi SQL) và truyền tham số (mảng values) thực sự là chìa khóa để tránh injection khi filter phức tạp. Mình thường dùng cách tương tự: build mảng `$whereClauses` và `$params` song song, rồi `implode(' AND ', $whereClauses)`. Một điểm mình thấy hay bị quên là xử lý toán tử `LIKE` – cần nhớ escape ký tự `%` và `_` trong giá trị người dùng nhập *trước khi* bind param, không phải trong SQL. Ngoài ra, với mảng `IN` (ví dụ filter theo nhiều status cùng lúc), cách an toàn nhất là generate động số lượng placeholder `?, ?, ?` tương ứng số phần tử mảng, rồi merge vào `$params`. Admin có thể demo thêm đoạn handle trường hợp `IN` với mảng rỗng (bỏ qua điều kiện) hoặc `BETWEEN` cho range ngày tháng không? Phần validation date format phía PHP trước khi bind cũng là nơi dễ sinh bug lặt vặt.

Đúng trọng tâm, việc escape `%` và `_` ở tầng PHP trước khi bind mới là "chìa khóa" an toàn cho LIKE, nhiều bạn lầm tưởng PDO lo hết. Về `IN` với mảng rỗng, cách gọn nhẹ nhất là check `empty($arr)` thì không push clause vào `$whereClauses` (hoặc thêm `1=0` nếu bắt buộc có điều kiện). Còn `BETWEEN` ngày tháng, mình thường validate format `Y-m-d` bằng `DateTime::createFromFormat` rồi mới bind 2 tham số `start`/`end`, tránh lỗi lặt vặt do locale hoặc chuỗi rác. Một điểm hay bị bỏ qua: khi filter phức tạp (nhiều nhóm điều kiện OR/AND lồng nhau), các bạn thường xây dựng đệ quy hay dùng thư viện Query Builder nhẹ (như `doctrine/dbal` chỉ phần SQL) để quản lý thứ tự tham số cho đỡ rối?

Với IN, mình thường tạo chuỗi placeholder theo đúng số phần tử, ví dụ dùng array_fill và implode để có ?,?,?, rồi bind từng giá trị bằng execute($params). Lưu ý không dùng lại cùng một named placeholder kiểu :id nhiều lần nếu chưa chắc chế độ emulate prepares; dùng ? hoặc đặt tên riêng sẽ an toàn hơn. Với ID số, vẫn nên ép kiểu int và loại giá trị rỗng trước khi dựng IN. Về ngày tháng, đừng tin định dạng người dùng gử