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.
Tôi đặt bốn cookie mang thuộc tính khác nhau rồi đo bằng Chromium thật: JavaScript chỉ thấy đúng cookie không có HttpOnly, máy chủ nhận đủ mọi cookie bất kể thuộc tính, còn Path chỉ đổi nơi cookie được gửi chứ không phải ranh giới bảo mật. Mỗi thuộc tính đóng đúng một cánh cửa — biết cửa nào mới đặt đúng thuộc tính.
Session fixation lật ngược mọi thứ bạn biết về trộm phiên: kẻ tấn công tự chọn ID phiên rồi gieo cho nạn nhân, nên HttpOnly và HTTPS đều vô dụng — không có gì bị đánh cắp cả. Tôi đo cuộc tấn công thật và cách chặn nó bằng đúng một dòng: cấp ID mới khi đăng nhập.
Bốn cách dùng sai JWT, dựng lại và tấn công thật: alg:none tự phong admin, secret 'secret' bị bẻ trong một vòng lặp bảy phần tử, và HS/RS confusion thủng đúng khi bạn tự viết verify (PyJWT thì chặn). Sợi chỉ chung: ba trong bốn lỗi là tin vào thứ do chính kẻ tấn công kiểm soát.
JWT không trạng thái mở rộng tuyệt vời vì máy chủ chẳng lưu gì — nhưng chính vì thế nó không thu hồi được: token bị thu hồi vẫn được chấp nhận cho tới khi exp trôi qua. Tôi đo cửa sổ đó (bằng đúng thời hạn), và cách thoát: access token ngắn + refresh token CÓ trạng thái thu hồi tức thì.