Tham số hoá là cách chặn SQL injection duy nhất thật sự đủ — nhưng chỉ ở vị trí giá trị. Có một chỗ nó không đặt vào được: tên cột trong ORDER BY. Tôi đo ở đó và đọc trọn một khoá bí mật không route nào hiển thị, một bit mỗi request, 144 request cho cả chuỗi.
SQL không phải nơi duy nhất trộn dữ liệu vào mã. Tôi dựng lại cùng lỗ hổng trên lệnh hệ thống (bộ lọc quên ký tự xuống dòng để lọt) và LDAP (mật khẩu '*' thành admin không cần biết mật khẩu). Cùng một lỗ mặc ba bộ quần áo, cùng một cách chặn: tách dữ liệu khỏi mã.
Tôi không đếm xem payload có mặt trong HTML hay không — tôi mở Chromium thật và chờ hộp thoại alert bật lên. Autoescape thắng mọi payload trong nội dung HTML, nhưng để lọt trơn khi biến rơi vào href. Bài học: chặn đúng cho ngữ cảnh này không tự nhiên đủ cho ngữ cảnh kia.
Tôi dựng một trang có năm đường chạy JavaScript, đổi header CSP và dùng Chromium thật xem đường nào bị chặn. Kết quả: 'self' làm nhiều hơn tên gọi (chặn luôn inline và eval — đúng chỗ XSS sống), 'unsafe-inline' mở lại đúng cánh cửa CSP sinh ra để đóng, và 'unsafe-eval' vô dụng nếu đứng một mình. Kèm một bài học đo lường: công cụ đo suýt bị chính thứ nó đang đo chặn lại.
Ba thư viện làm sạch HTML trên chín payload XSS, xác minh bằng Chromium thật — script có THỰC SỰ chạy không. Cấu hình chặt: cả ba 0/9. Nhưng chính bleach đó, thêm on* handlers vào allowlist, để lọt 3/9. Bài học: bảo mật làm sạch nằm ở danh sách cho phép, không ở tên thư viện.
Tôi dựng một 'ngân hàng' có phiên thật, một trang tấn công ở tên miền khác và một Chromium thật ở giữa, rồi đo: SameSite=Lax một mình chặn CSRF cho POST không cần token, nhưng một route GET đổi trạng thái vẫn mất 500 đồng ngay cả với Lax. Token và SameSite cắt ở hai mắt xích khác nhau, và bạn nên có cả hai.