7 lỗ hổng bảo mật backend phải thuộc lòng: từ SQL Injection tới SSRF, kèm cheat sheet OWASP

API chạy được chưa chắc đã an toàn. Theo bộ ảnh của trang TechtoTech, có 7 lỗ hổng mà backend engineer nào cũng phải biết — từ SQL Injection tới SSRF — và chỉ cần sót một lớp kiểm tra là cả hệ thống có thể bị lộ. Mỗi lỗ hổng đi kèm code sai, code đúng và vị trí trong danh sách OWASP. Bài viết này tóm tắt bản chất, nơi thường xảy ra và cách phòng thủ của cả 7 lỗ hổng, để bạn tự tin review code và đi phỏng vấn.

Trả lời nhanh: Theo bộ ảnh của TechtoTech, 7 lỗ hổng bảo mật backend phải thuộc lòng là: SQL Injection (chặn bằng câu truy vấn tham số hóa), Broken Authentication (session an toàn, MFA), IDOR/BOLA (kiểm quyền sở hữu trên từng đối tượng), SSRF (giới hạn đích đến, chặn kết nối ra ngoài), Mass Assignment (DTO riêng, danh sách trường được phép), Insecure Deserialization (kiểu cố định, validate dữ liệu), và Sensitive Data Exposure (mã hóa, che secret, chỉ trả dữ liệu tối thiểu). Cả 7 đều nằm trong hai danh sách OWASP Top 10 và OWASP API Security Top 10, trong đó lỗi phân quyền đứng đầu cả hai — kiểm quyền là việc cần làm đầu tiên.

OWASP Top 10 là danh sách 10 rủi ro bảo mật nghiêm trọng nhất cho ứng dụng web do tổ chức OWASP công bố, còn OWASP API Security Top 10 là danh sách tương tự dành riêng cho API. Backend là phần máy chủ xử lý logic, dữ liệu và phân quyền phía sau giao diện — nơi một lớp kiểm tra bị sót có thể khiến cả hệ thống bị lộ.

1. SQL Injection — dữ liệu người dùng biến thành cú pháp SQL

Dữ liệu người dùng nhập bị ghép thẳng vào câu SQL và trở thành một phần của cú pháp. Một câu truy vấn không an toàn là đủ lộ cả database. Ví dụ code sai là ghép chuỗi: "SELECT ... WHERE email = '" + email + "'". Code đúng dùng PreparedStatement: "SELECT ... WHERE email = ?" kèm st.setString(1, email).

Lỗ hổng này thường gặp ở form đăng nhập, tìm kiếm và lọc dữ liệu. Nhập ' OR 1=1 -- vào ô email là đủ biến điều kiện WHERE thành luôn đúng. Cách phòng thủ: dùng câu truy vấn tham số hóa để dữ liệu tách khỏi câu lệnh; không ghép SQL động từ chuỗi; với tên cột, tên bảng động thì dùng danh sách cho phép. Chỉ kiểm tra dữ liệu đầu vào thôi là chưa đủ.

2. Broken Authentication — đăng nhập an toàn mới là một nửa

Đăng nhập an toàn mới là một nửa câu chuyện. Session yếu, token lộ hay không chặn đoán mật khẩu đều cho kẻ tấn công mạo danh người dùng. Cookie phiên làm việc cần được đặt đúng: Set-Cookie: HttpOnly; Secure; SameSite=Lax — HttpOnly để JavaScript không đọc được cookie, Secure để chỉ gửi qua HTTPS.

Các dạng hỏng thường gặp: không chặn credential stuffing (thử hàng loạt tài khoản/mật khẩu bị lộ), session sống lâu và không thu hồi được, token bị lộ hoặc lưu không an toàn. Cách phòng thủ: MFA, giới hạn số lần đăng nhập, cấp session mới sau khi đăng nhập và thu hồi được session. Cần phân biệt rõ: xác thực trả lời "bạn là ai"; phân quyền trả lời "bạn được làm gì".

3. IDOR / BOLA — đổi một con số trên URL là xem được dữ liệu người khác

Chỉ cần đổi một con số trên URL là xem được dữ liệu của người khác: API tìm đúng bản ghi nhưng không kiểm tra người gọi có quyền với nó không. Ví dụ, GET /orders/{id} phải kiểm tra quyền và ném AccessDeniedException khi người gọi không có quyền.

Lỗ hổng này xảy ra ở chỗ xem đơn hàng của người khác, tài liệu riêng tư, hay dữ liệu thuộc tài khoản khác. Cách phòng thủ: kiểm quyền trên mọi thao tác với tài nguyên, theo quyền sở hữu, vai trò và luật chia sẻ; kiểm thử bằng cách đổi sang tài khoản khác. Dùng UUID khó đoán không thay thế được kiểm quyền — mã khó đoán vẫn có thể bị lộ hoặc đoán ra.

4. SSRF — server bị mượn để chọc vào mạng nội bộ

SSRF (Server-Side Request Forgery) xảy ra khi server tải bất kỳ URL nào người dùng đưa, kể cả địa chỉ nội bộ. Kẻ tấn công mượn server để chọc vào mạng bên trong: người dùng gửi URL tới Backend API, API lại gọi ra mạng nội bộ.

Lỗ hổng này thường gặp ở tính năng tạo bản xem trước cho link, nhập dữ liệu từ URL, test webhook và tải ảnh từ link. Cách phòng thủ: chỉ cho phép danh sách đích tin cậy, kiểm tra địa chỉ sau khi phân giải DNS, kiểm tra cả từng bước redirect, và chặn ở tầng mạng bằng egress control. Chỉ kiểm tra chuỗi URL thôi là chưa đủ, vì DNS và redirect có thể đổi đích thật.

5. Mass Assignment — API tự gán cả trường người dùng không được sửa

Mass Assignment xảy ra khi API tự gán mọi trường trong request vào đối tượng bên trong, kể cả trường người dùng không được sửa — như vai trò. Một request độc hại như {"name": "Asha", "role": "admin"} có thể nâng quyền nếu API bind thẳng vào entity. Cách đúng: dùng DTO chỉ nhận các trường được phép, và vai trò vẫn giữ là "user".

Lỗ hổng này thường gặp ở cập nhật hồ sơ người dùng và cài đặt tài khoản. Cách phòng thủ: DTO riêng cho từng request, danh sách trường được phép sửa, thuộc tính chỉ admin được đổi, và không bind thẳng request vào entity. Cần cả validation lẫn phân quyền: giá trị hợp lệ vẫn có thể là giá trị không được phép với người này.

6. Insecure Deserialization — dữ liệu không tin cậy quyết định đối tượng được tạo

Insecure Deserialization xảy ra khi dữ liệu không tin cậy quyết định đối tượng nào được tạo ra. Tùy công nghệ, hậu quả có thể là đổi trạng thái trái phép, thậm chí chạy mã. Code sai là dùng ObjectInputStream với readObject() trên dữ liệu ngoài; code đúng là đọc vào một DTO cố định rồi validate, ví dụ đọc thành UserDto rồi validate(u).

Lỗ hổng này gặp ở chỗ nhận đối tượng Java đã serialize, dùng ObjectInputStream với dữ liệu ngoài, hoặc JSON bật kiểu đa hình theo trường @type. Cách phòng thủ: không deserialize native dữ liệu ngoài; nếu bắt buộc thì đặt ObjectInputFilter; đọc vào DTO cố định, không đa hình mở; và validate dữ liệu sau khi đọc. JSON tự nó không nguy hiểm — rủi ro nằm ở cách cấu hình kiểu đa hình.

7. Sensitive Data Exposure — log không bao giờ được trở thành một vụ lộ dữ liệu

Thông tin riêng tư, mật khẩu và token có thể lộ qua log, response, nơi lưu trữ hay đường truyền. Ví dụ sai: ghi Authorization: Bearer <real-token> và địa chỉ email vào log. Cách đúng: che secret trong log (Authorization: [REDACTED]) và chỉ trả về những gì cần thiết.

Lỗ hổng này xảy ra khi ghi token, mật khẩu vào log, khi response trả thừa dữ liệu cá nhân, hay khi gửi dữ liệu nhạy cảm mà không mã hóa. Cách phòng thủ: mã hóa khi truyền và khi lưu trữ, che secret trong log, chỉ trả các trường cần thiết, và giới hạn quyền truy cập dữ liệu. Chỉ mã hóa thôi không chặn được việc trả thừa dữ liệu qua log hay response.

7 lỗ hổng nằm ở đâu trong danh sách OWASP?

Theo bộ ảnh, cả 7 lỗ hổng đều nằm trong hai danh sách bảo mật phổ biến nhất: OWASP Top 10 cho web và OWASP API Security Top 10. Bảng đối chiếu theo bộ ảnh như sau:

Lỗ hổng	Vị trí theo bộ ảnh
IDOR / BOLA	API1 — Broken Object Level Authorization; A01 Broken Access Control
Broken Authentication	API2 — Broken Authentication; A07 Authentication Failures
Mass Assignment	API3 — Object Property Level
SQL Injection	A05 Injection
SSRF	A01 Broken Access Control (gộp cả SSRF); SSRF cũng có một mục riêng
Sensitive Data Exposure	A04 Cryptographic Failures
Insecure Deserialization	A08 Software or Data Integrity Failures

Điểm nhấn của bộ ảnh: lỗi phân quyền đứng đầu cả hai danh sách — kiểm quyền là việc cần làm đầu tiên.

Cheat sheet: 7 lỗ hổng, 7 cách chặn

Ảnh cuối của bộ ảnh là cheat sheet tóm tắt để kiểm tra lại dự án của mình:

#	Lỗ hổng	Cách chặn
1	SQL Injection	Câu truy vấn tham số hóa
2	Broken Auth	Session an toàn, MFA
3	IDOR / BOLA	Kiểm quyền trên từng đối tượng
4	SSRF	Giới hạn đích, chặn kết nối ra ngoài
5	Mass Assignment	DTO, danh sách trường được phép
6	Deserialization	Kiểu cố định, validate dữ liệu
7	Data Exposure	Mã hóa, che secret, trả tối thiểu

Thông điệp kết của bộ ảnh: nhận ra điểm yếu, biết cách phòng thủ — bảo mật không phải một tính năng, nó là một phần của nghề backend.

Câu hỏi thường gặp

1. Lỗ hổng backend nào nguy hiểm nhất theo OWASP? Theo bộ ảnh, lỗi phân quyền (Broken Access Control, gồm IDOR/BOLA) đứng đầu cả OWASP Top 10 và OWASP API Security Top 10 — kiểm quyền là việc cần làm đầu tiên.

2. SQL Injection chặn bằng cách nào? Dùng câu truy vấn tham số hóa (PreparedStatement) để dữ liệu tách khỏi câu lệnh; không ghép SQL động từ chuỗi; tên cột, tên bảng động thì dùng danh sách cho phép.

3. Xác thực và phân quyền khác nhau thế nào? Xác thực trả lời "bạn là ai"; phân quyền trả lời "bạn được làm gì". Đăng nhập an toàn mới là một nửa — session và token cũng phải được quản lý an toàn.

4. Vì sao UUID khó đoán không thay thế được kiểm quyền? Vì mã khó đoán vẫn có thể bị lộ hoặc đoán ra; API vẫn phải kiểm tra người gọi có quyền với từng đối tượng cụ thể hay không.

5. SSRF nguy hiểm ở điểm nào? Server tải bất kỳ URL nào người dùng đưa, kể cả địa chỉ nội bộ — kẻ tấn công mượn server để chọc vào mạng bên trong, nên phải giới hạn đích tin cậy, kiểm tra sau DNS và redirect, và chặn ở tầng mạng.

Bài viết được viết lại từ bộ ảnh của trang TechtoTech đăng ngày 14/11/2026. Nội dung, ví dụ code và bảng đối chiếu OWASP theo bộ ảnh gốc.