Bảo mật API trong môi trường phát triển ứng dụng Web

Bảo mật API trong phát triển web xoay quanh một nguyên tắc: không tin bất kỳ yêu cầu nào chỉ vì nó đến từ ứng dụng của bạn. Mỗi endpoint cần xác thực người gọi, kiểm tra quyền trên từng đối tượng dữ liệu, kiểm tra đầu vào, giới hạn tần suất và chỉ trả về đúng những trường cần thiết. Phần lớn sự cố lộ dữ liệu qua API không đến từ kỹ thuật tấn công phức tạp mà từ một endpoint quên kiểm tra quyền hoặc trả về quá nhiều thông tin.

Vì sao API là mục tiêu hấp dẫn

Ứng dụng web hiện đại tách giao diện và dữ liệu: trình duyệt hoặc ứng dụng di động gọi API để lấy và ghi dữ liệu. Điều này có nghĩa API phơi bày trực tiếp logic nghiệp vụ và dữ liệu. Kẻ tấn công không cần dùng giao diện; họ đọc lưu lượng mạng, tìm endpoint, rồi gửi yêu cầu tùy ý bằng công cụ dòng lệnh.

Ứng dụng di động là ví dụ rõ: nhiều nhóm phát triển nghĩ API "ẩn" sau ứng dụng nên không ai thấy. Thực tế, giải nén ứng dụng hoặc chặn lưu lượng trên thiết bị của chính mình là đủ để liệt kê mọi endpoint.

Những lỗi bảo mật API phổ biến

Dự án OWASP có một danh sách riêng cho API (OWASP API Security Top 10). Một số nhóm lỗi nổi bật:

Bức tranh rộng hơn về các nhóm lỗ hổng ứng dụng web có trong bài phân tích OWASP Top 10.

Xác thực: biết ai đang gọi

• Dùng chuẩn đã được kiểm chứng như OAuth 2.0 và OpenID Connect thay vì tự chế cơ chế.
• Token truy cập có thời hạn ngắn, kết hợp refresh token được bảo vệ và có thể thu hồi.
• Không đặt token hay khóa API trong URL, vì URL bị ghi vào log, lịch sử, header Referer.
• Giới hạn số lần đăng nhập sai, có cơ chế khóa tạm thời.
• Khóa API cho máy với máy cần được phân quyền tối thiểu và luân chuyển định kỳ.

Nếu dùng JWT, có nhiều chi tiết dễ sai như chấp nhận thuật toán "none" hay không kiểm tra hạn; xem bài triển khai xác thực JWT an toàn.

Phân quyền: kiểm tra trên từng đối tượng

Xác thực trả lời "bạn là ai", phân quyền trả lời "bạn được làm gì với dữ liệu này". Lỗi BOLA nguy hiểm vì endpoint vẫn yêu cầu đăng nhập, chỉ quên kiểm tra rằng đối tượng được yêu cầu thuộc về người gọi.

• Mỗi truy vấn dữ liệu phải kèm điều kiện sở hữu hoặc quyền, ví dụ lọc theo ID người dùng lấy từ token chứ không lấy từ tham số yêu cầu.
• Tập trung logic phân quyền ở một lớp dùng chung thay vì rải rác từng endpoint.
• Dùng ID khó đoán (UUID) giúp giảm dò tìm nhưng không thay thế kiểm tra quyền.
• Endpoint quản trị đặt ở đường riêng, có kiểm tra vai trò và nếu được thì giới hạn mạng truy cập.

Dữ liệu vào và dữ liệu ra

Kiểm tra đầu vào

Định nghĩa lược đồ (schema) cho mọi yêu cầu: kiểu dữ liệu, độ dài, định dạng, giá trị cho phép. Từ chối trường không có trong lược đồ để chặn mass assignment. Dùng truy vấn tham số hóa khi làm việc với cơ sở dữ liệu để tránh lỗi chèn mã, chi tiết trong bài lỗ hổng SQL Injection.

Kiểm soát dữ liệu trả về

Dùng đối tượng trả về (DTO) riêng, chỉ chứa trường mà client cần. Không trả nguyên bản ghi cơ sở dữ liệu rồi trông chờ giao diện ẩn bớt. Thông báo lỗi trả cho client nên chung chung; chi tiết kỹ thuật như stack trace chỉ ghi vào log nội bộ.

Giới hạn tần suất và tài nguyên

• Áp giới hạn số yêu cầu theo người dùng, theo khóa API, theo IP.
• Giới hạn kích thước trang, kích thước tệp tải lên, độ sâu truy vấn với GraphQL.
• Đặt thời gian chờ cho các thao tác tốn kém.
• Endpoint nhạy cảm như đăng nhập, quên mật khẩu, gửi OTP cần giới hạn chặt hơn.

Quản lý bí mật trong quá trình phát triển

Khóa API, chuỗi kết nối cơ sở dữ liệu, khóa ký token không được nằm trong mã nguồn hay ứng dụng di động. Dùng biến môi trường hoặc dịch vụ quản lý bí mật, tách riêng giữa môi trường phát triển, thử nghiệm và sản xuất. Đây là chủ đề của bài bảo mật tệp cấu hình nhạy cảm.

Vận hành: nhìn thấy những gì đang xảy ra

• Lập danh mục mọi API đang chạy, gồm cả phiên bản cũ và endpoint nội bộ; tắt những gì không dùng.
• Ghi nhật ký yêu cầu với ID người dùng, endpoint, mã trạng thái, không ghi mật khẩu hay token.
• Cảnh báo khi một người dùng truy cập số lượng bất thường đối tượng khác nhau, dấu hiệu dò BOLA.
• Bắt buộc HTTPS, cấu hình CORS chặt chẽ chỉ cho phép nguồn cần thiết.

API thường xử lý dữ liệu cá nhân của khách hàng, nên các yêu cầu về bảo vệ dữ liệu cũng áp dụng trực tiếp. Bạn có thể tham khảo khung tiêu chuẩn trong bài bảo vệ dữ liệu khách hàng theo tiêu chuẩn quốc tế.

Đưa kiểm thử bảo mật vào quy trình

Viết test tự động cho phân quyền: với mỗi endpoint, kiểm tra rằng người dùng A không đọc, sửa, xóa được dữ liệu của người dùng B. Loại test này rẻ, chạy mỗi lần build và bắt được đúng nhóm lỗi phổ biến nhất. Kết hợp với quét bảo mật tự động trong pipeline và rà soát thủ công trước khi phát hành tính năng quan trọng; đặc biệt là những tính năng chạm tới thanh toán hoặc dữ liệu cá nhân.

Tài liệu API (OpenAPI/Swagger) cũng là công cụ bảo mật: khi mọi endpoint, tham số và quyền yêu cầu được mô tả rõ, nhóm phát triển dễ phát hiện chỗ thiếu kiểm tra và công cụ tự động có cơ sở để kiểm thử.