Security Cơ bản

Phần này hiện có 7 bài, mỗi bài xoay quanh một cơ chế hay bị nhầm là đã bảo vệ hơn thực tế: đăng nhập không phải phân quyền, chặn đọc response không phải chặn request, validate chuỗi URL không phải kiểm soát đích kết nối.

Phạm vi (đọc trước)

Đã có: phân quyền theo object (BOLA/IDOR), CORS và CSRF, SSRF, session cookie và JWT, hash mật khẩu, OAuth 2.0/OIDC với PKCE, và secure coding (SQL injection, secret, log, mật khẩu, path traversal, prototype pollution, ReDoS).

Chưa có: MFA, XSS, logging/audit chuyên sâu. Rate limiting nằm ở nhóm API: Rate limiting cho API. Đừng coi phần này là checklist bảo mật đầy đủ; nó là một số mảnh cụ thể, mỗi mảnh đi sâu tới mức có thể kiểm chứng.

Lộ trình đọc

Thứ tự	Bài	Level	Bạn sẽ trả lời được
1	BOLA/IDOR	basic	Vì sao token hợp lệ vẫn đọc được đơn người khác? Scope query viết thế nào? BOLA khác BFLA và BOPLA ra sao? List, bulk, nested cần check gì?
2	CORS và CSRF	intermediate	Request nào bị preflight? SameSite=Lax chặn gì và để lọt gì? Vì sao CORS không chống CSRF? Token, Origin, Sec-Fetch-Site dùng thế nào?
3	SSRF	intermediate	Vì sao chặn localhost không đủ? Metadata endpoint và IMDSv2 là gì? Redirect, DNS rebinding bypass thế nào và safe-fetch trông ra sao?
4	Session cookie hay JWT	intermediate	Chọn session hay JWT theo nhu cầu thu hồi nào? Cookie cần thuộc tính gì? Verify JWT phải kiểm tra những gì? Refresh token rotation phát hiện token bị đánh cắp ra sao?
5	Secure coding	intermediate	Lỗ hổng nào nằm ngay trong code: SQL injection (cả ORDER BY), mass assignment, secret và log, hash mật khẩu, path traversal, prototype pollution, ReDoS?
6	Hash mật khẩu	intermediate	Vì sao SHA-256 có salt vẫn vỡ? Chọn argon2id, scrypt, bcrypt hay PBKDF2 với tham số nào? Nâng cấp hash cũ thế nào?
7	OAuth 2.0, OIDC và PKCE	intermediate	Vì sao dùng Authorization Code + PKCE thay vì implicit hay password grant? Token của SPA nên nằm ở đâu? API phải kiểm tra gì trên access token?

Bài 1 là nền (authorization), bài 2 và 3 độc lập với nhau nên đọc theo nhu cầu. Bài 4 nên đọc sau bài 2 vì dựa trên cookie, SameSite và CSRF.

Gặp triệu chứng này, đọc bài nào

Triệu chứng hoặc câu hỏi	Bài
User đổi ID trên URL và thấy dữ liệu người khác	BOLA/IDOR
User thường gửi thêm trường role hoặc gọi route admin được	BOLA/IDOR (phần BOPLA/BFLA)
Email hoặc cài đặt tài khoản bị đổi sau khi user mở một trang lạ	CORS và CSRF
Lỗi “blocked by CORS policy”, hay muốn mở API cho domain khác	CORS và CSRF
Có endpoint “nhập URL” (avatar, preview, webhook)	SSRF
Log thấy request từ server tới 127.0.0.1, IP private hoặc 169.254.169.254	SSRF

Liên quan

Webhook và idempotency bàn phía server-to-server của cùng kiểu nhầm lẫn: xác minh chữ ký khác với chống xử lý trùng.