1. API security là gì?
API security (bảo mật API) là tập hợp các biện pháp, quy trình và công nghệ nhằm bảo vệ giao diện lập trình ứng dụng khỏi bị truy cập trái phép, khai thác lỗ hổng và rò rỉ dữ liệu.
Bảo mật API bao gồm việc kiểm soát ai được phép gọi API, dữ liệu nào được phép truyền tải, và hành vi nào bị coi là bất thường. Không chỉ bảo vệ ở lớp mạng, API security còn phải xử lý logic ứng dụng, quyền truy cập theo từng đối tượng và toàn vẹn dữ liệu ở mỗi endpoint.
Trong kiến trúc microservices, mỗi service giao tiếp với nhau qua API. Một lỗ hổng tại một endpoint có thể dẫn đến việc kẻ tấn công di chuyển ngang (lateral movement) sang toàn bộ hệ thống. Với mobile app, API là cầu nối duy nhất giữa client và dữ liệu back-end, khiến mọi API endpoint đều là bề mặt tấn công tiềm năng. Với tích hợp bên thứ ba, mỗi API key bị lộ có thể mở ra quyền truy cập không giới hạn vào dữ liệu nhạy cảm của doanh nghiệp.
Theo báo cáo State of API Security của Salt Security (Q1 2023), hơn 94% tổ chức gặp sự cố bảo mật liên quan đến API trong vòng 12 tháng. Điều này cho thấy bảo mật API không còn là vấn đề của riêng đội ngũ bảo mật chuyên sâu, mà là ưu tiên chiến lược của toàn bộ doanh nghiệp.
2. Bảo mật API khác gì với bảo mật ứng dụng web?
Bảo mật API và bảo mật ứng dụng web đều thuộc lĩnh vực bảo mật lớp ứng dụng, nhưng phạm vi bảo vệ, điểm tấn công và công cụ áp dụng có sự khác biệt rõ ràng.
Bảo mật ứng dụng web tập trung vào giao diện người dùng (UI) và luồng tương tác trình duyệt, trong khi bảo mật API bảo vệ các endpoint truyền dữ liệu có cấu trúc giữa máy với máy (machine-to-machine). Điểm khác biệt quan trọng nhất là API không có giao diện trực quan để kiểm tra bằng mắt thường, khiến các lỗ hổng logic khó phát hiện hơn và thường bị bỏ sót trong các quy trình kiểm thử truyền thống.
| Tiêu chí | Bảo mật API | Bảo mật ứng dụng web |
|---|---|---|
| Phạm vi bảo vệ | Endpoint, dữ liệu JSON/XML, machine-to-machine | Giao diện UI, luồng người dùng, session trình duyệt |
| Giao thức chính | REST, GraphQL, gRPC, SOAP | HTTP/HTTPS, WebSocket |
| Điểm tấn công phổ biến | Broken authorization, injection qua payload, excessive exposure | XSS, CSRF, clickjacking, session hijacking |
| Công cụ bảo vệ | API gateway, WAF lớp 7, rate limiting theo endpoint | WAF truyền thống, CSP, cookie flags |
| Tiêu chuẩn tham chiếu | OWASP API Security Top 10 | OWASP Web Application Top 10 |
| Khả năng kiểm tra tự động | Cao (schema validation, fuzzing) | Trung bình (cần browser automation) |
Dù khác biệt về cách tiếp cận, hai lĩnh vực này bổ trợ nhau. Một hệ thống bảo mật toàn diện cần bảo vệ cả ứng dụng web lẫn API một cách đồng thời, đặc biệt trong các kiến trúc SPA (Single Page Application) nơi toàn bộ logic được thực thi qua API call.
3. Các mối đe dọa bảo mật API phổ biến nhất
OWASP API Security Top 10 là tài liệu tham chiếu được sử dụng rộng rãi nhất để nhận diện rủi ro bảo mật API. Dưới đây là các mối đe dọa phổ biến nhất mà IT Manager, Security Engineer và Developer cần nắm rõ.
3.1. Broken Object Level Authorization & Broken Authentication
Hai lỗ hổng này thường xuất hiện song song và có thể bị khai thác kết hợp để leo thang đặc quyền hoàn toàn trong hệ thống. BOLA xảy ra khi API không kiểm tra quyền sở hữu đối tượng, cho phép kẻ tấn công truy cập tài nguyên của người dùng khác chỉ bằng cách thay đổi ID trong request. Broken Authentication xảy ra khi cơ chế xác thực được triển khai sai, như token không có thời hạn, API key bị lộ hoặc thiếu xác thực đa lớp. Khi kết hợp, attacker có thể vừa vượt qua xác thực vừa truy cập tùy ý dữ liệu của các đối tượng khác mà không bị phát hiện. .
3.2. Excessive Data Exposure
Nhiều API trả về toàn bộ dữ liệu của một đối tượng và để client tự lọc phần cần thiết. Điều này dẫn đến việc các trường dữ liệu nhạy cảm như mật khẩu đã hash, token nội bộ hoặc thông tin cá nhân bị lộ trong response mà không cần khai thác bất kỳ lỗ hổng phức tạp nào. Lỗi này thường gặp ở các API được phát triển nhanh mà không có quy trình review response schema.
3.3.Injection attacks qua API endpoint
Tấn công injection qua API bao gồm SQL injection, command injection và NoSQL injection được gửi qua tham số request, header hoặc payload JSON/XML. Không giống tấn công injection truyền thống qua form HTML, các cuộc tấn công này nhắm thẳng vào logic xử lý dữ liệu phía back-end và thường khó bị phát hiện hơn nếu không có cơ chế validate input chặt chẽ.
3.4. DDoS lớp ứng dụng
DDoS lớp ứng dụng (Layer 7) nhắm trực tiếp vào các endpoint API bằng cách gửi số lượng lớn request hợp lệ về mặt cú pháp nhưng với tần suất vượt ngưỡng xử lý của server. Khác với DDoS truyền thống tấn công băng thông, hình thức này khai thác logic nghiệp vụ của API như các endpoint nặng tính toán, truy vấn CSDL phức tạp hoặc luồng xác thực để làm cạn kiệt tài nguyên hệ thống. Lỗi thường gặp ở các API không triển khai rate limiting, thiếu cơ chế phát hiện bất thường và không có lớp bảo vệ phía trước.
| Loại tấn công | Cơ chế | Hậu quả | Mức độ nghiêm trọng |
|---|---|---|---|
| BOLA | Thay đổi ID đối tượng trong request | Truy cập dữ liệu trái phép của người dùng khác | Rất cao |
| Broken Authentication | Token không hết hạn, API key lộ | Chiếm quyền tài khoản, leo thang đặc quyền | Rất cao |
| Excessive Data Exposure | API trả về toàn bộ trường dữ liệu thay vì chỉ trường cần thiết | Lộ thông tin nhạy cảm trong response | Trung bình đến cao |
| Injection qua API | Payload độc hại trong JSON/XML/header | Truy vấn CSDL trái phép, thực thi lệnh từ xa | Cao |
| DDoS lớp ứng dụng | Gọi API tần suất cao để làm quá tải | Gián đoạn dịch vụ, ảnh hưởng uptime | Cao |
4. Các giải pháp và nguyên tắc bảo mật API
Bảo mật API hiệu quả không phụ thuộc vào một công cụ duy nhất mà là sự kết hợp của nhiều lớp bảo vệ, từ thiết kế kiến trúc đến vận hành hàng ngày.
4.1. Xác thực và phân quyền (Authentication và Authorization)
Xác thực API xác minh danh tính của bên gọi, còn phân quyền xác định bên đó được làm gì. Hai cơ chế này cần được triển khai độc lập và không thể thay thế nhau. Các chuẩn phổ biến bao gồm OAuth 2.0 cho ủy quyền, OpenID Connect cho xác thực danh tính, và JWT (JSON Web Token) cho truyền tải thông tin xác thực. Với mọi endpoint nhạy cảm, cần bổ sung xác thực đa yếu tố và kiểm tra phân quyền ở tầng business logic, không chỉ ở tầng gateway.
4.2. Mã hóa dữ liệu và kiểm soát truy cập
Toàn bộ lưu lượng API phải được mã hóa qua TLS 1.2 trở lên. Ngoài mã hóa truyền tải, các trường dữ liệu nhạy cảm trong payload cũng cần được mã hóa riêng trước khi lưu trữ. Kiểm soát truy cập cần áp dụng nguyên tắc đặc quyền tối thiểu (least privilege), chỉ cấp cho mỗi API consumer quyền truy cập đúng với phạm vi cần thiết.
4.3. Rate limiting, throttling và chống DDoS lớp ứng dụng
Rate limiting giới hạn số lượng request mỗi client có thể gửi trong một khoảng thời gian, ngăn chặn cả tấn công brute force lẫn DDoS lớp 7. Throttling điều tiết lưu lượng khi hệ thống tiếp cận giới hạn tài nguyên. Hai cơ chế này cần được cấu hình riêng cho từng endpoint theo mức độ nhạy cảm, không áp dụng một ngưỡng chung cho toàn bộ API.
4.4. Validate input và ngăn chặn injection
Mọi tham số đầu vào từ request đều phải được validate nghiêm ngặt về kiểu dữ liệu, định dạng và phạm vi giá trị cho phép. Ngoài validate ở client, cần validate lại ở server trước khi xử lý. Với các API nhận dữ liệu phức tạp, áp dụng JSON Schema validation để đảm bảo payload đúng cấu trúc trước khi chuyển vào business logic.
4.5. Logging, giám sát và phát hiện hành vi bất thường
Mỗi API call cần được ghi log đầy đủ bao gồm thời gian, endpoint, phương thức, mã phản hồi, IP nguồn và định danh người dùng. Hệ thống giám sát cần có khả năng phát hiện bất thường theo thời gian thực, chẳng hạn spike đột ngột về số lượng request, pattern truy cập lạ hoặc chuỗi lỗi 401/403 liên tiếp từ cùng một nguồn.
4.6. WAF và API gateway, lớp bảo vệ tầng ứng dụng
Web Application Firewall (WAF) lớp 7 lọc và kiểm tra lưu lượng HTTP/HTTPS trước khi đến ứng dụng, chặn các payload độc hại như SQL injection và XSS. API gateway đảm nhiệm vai trò trung gian, thực thi xác thực, rate limiting, routing và logging tập trung cho toàn bộ API. Hai lớp bảo vệ này thường được triển khai kết hợp để tạo thành tuyến phòng thủ đầu tiên cho hệ thống bảo mật ứng dụng web và API.
5. Các yêu cầu pháp lý và tiêu chuẩn bảo mật API
Bên cạnh các biện pháp kỹ thuật, doanh nghiệp triển khai API còn phải đáp ứng các yêu cầu tuân thủ bắt buộc từ cơ quan quản lý và tổ chức tiêu chuẩn quốc tế. Mức độ áp dụng phụ thuộc vào ngành và loại dữ liệu mà API xử lý, nhưng ba tiêu chuẩn dưới đây ảnh hưởng trực tiếp đến cách thiết kế và vận hành API tại Việt Nam.
5.1. Thông tư 64/2024/TT-NHNN
Thông tư 64/2024/TT-NHNN do Ngân hàng Nhà nước Việt Nam ban hành quy định các yêu cầu kỹ thuật bắt buộc đối với hệ thống thông tin của tổ chức tín dụng, trong đó có API kết nối với hệ thống core banking, ví điện tử và cổng thanh toán. Các yêu cầu trực tiếp liên quan đến API bao gồm:
- Xác thực mạnh cho mọi API call xử lý giao dịch tài chính, không chấp nhận xác thực đơn lớp
- Mã hóa toàn bộ dữ liệu nhạy cảm trong payload trước khi truyền tải, không chỉ mã hóa ở lớp transport
- Ghi vết (audit log) đầy đủ bao gồm định danh người gọi, thời gian, endpoint và kết quả xử lý cho mọi API liên quan đến giao dịch
- Kiểm tra và phê duyệt định kỳ danh sách API được phép kết nối vào hệ thống core
Với các doanh nghiệp Fintech, ngân hàng số và đơn vị cung cấp dịch vụ trung gian thanh toán, Thông tư 64 là văn bản pháp lý có tính ràng buộc cao nhất đối với bảo mật API tại Việt Nam hiện nay.
5.2. PCI-DSS
PCI-DSS (Payment Card Industry Data Security Standard) là tiêu chuẩn bảo mật dữ liệu thẻ thanh toán do Hội đồng Tiêu chuẩn Bảo mật PCI ban hành, áp dụng bắt buộc cho mọi tổ chức lưu trữ, xử lý hoặc truyền tải dữ liệu thẻ, kể cả qua API. PCI-DSS phiên bản 4.0 bổ sung các yêu cầu kỹ thuật cụ thể hơn cho môi trường API so với các phiên bản trước:
- Kiểm soát truy cập theo nguyên tắc đặc quyền tối thiểu cho từng API endpoint có liên quan đến dữ liệu thẻ
- Mã hóa số thẻ và CVV ở cấp độ trường dữ liệu trong payload, không được để dạng plaintext dù chỉ tạm thời trong bộ nhớ
- Quét lỗ hổng bảo mật API định kỳ và sau mỗi thay đổi cấu trúc endpoint
- Giám sát và cảnh báo tự động khi phát hiện pattern truy cập bất thường vào API xử lý dữ liệu thanh toán
Doanh nghiệp TMĐT, ví điện tử và cổng thanh toán không đạt chuẩn PCI-DSS có thể bị tổ chức thẻ quốc tế (Visa, Mastercard) đình chỉ khả năng xử lý giao dịch.
5.3. NIST SP 800-204
NIST SP 800-204 (Security Strategies for Microservices-based Application Systems) là tài liệu kỹ thuật do Viện Tiêu chuẩn và Công nghệ Quốc gia Hoa Kỳ ban hành, cung cấp hướng dẫn chi tiết về bảo mật API trong kiến trúc microservices. Khác với Thông tư 64 và PCI-DSS mang tính ràng buộc pháp lý, NIST SP 800-204 là framework kỹ thuật tham chiếu được nhiều tổ chức áp dụng tự nguyện để nâng cao mức độ bảo mật API:
- Triển khai zero trust cho toàn bộ giao tiếp service-to-service qua API nội bộ, không tin tưởng mặc định dù traffic đến từ trong mạng nội bộ
- Sử dụng mutual TLS (mTLS) để xác thực hai chiều giữa các service trong kiến trúc microservices
- Tập trung quản lý chính sách bảo mật API qua API gateway thay vì cấu hình phân tán ở từng service
- Áp dụng service mesh để giám sát và kiểm soát lưu lượng API nội bộ theo thời gian thực
NIST SP 800-204 phù hợp nhất với các đội ngũ Developer và DevOps đang xây dựng hoặc nâng cấp kiến trúc microservices, đặc biệt trong các tổ chức có yêu cầu tuân thủ tiêu chuẩn quốc tế hoặc làm việc với đối tác nước ngoài.
6. Bảo vệ API toàn diện với VNIS
VNIS (VNETWORK Internet Security) là nền tảng bảo mật ứng dụng và CDN tích hợp. Không đơn thuần là WAF, VNIS kết hợp nhiều lớp bảo vệ trên cùng một nền tảng, giúp doanh nghiệp bảo vệ toàn bộ bề mặt tấn công API mà không cần vận hành nhiều hệ thống riêng lẻ.
Với các tổ chức đang xây dựng hoặc vận hành API ở quy mô lớn, VNIS cung cấp:
- Cloud WAAP với hơn 2.400 bộ quy tắc được cập nhật liên tục, tự động chặn các cuộc tấn công injection, broken authentication và các vector tấn công trong OWASP API Security Top 10
- Kiểm soát rate limiting và throttling theo từng endpoint, ngăn chặn tấn công DDoS lớp ứng dụng và brute force API
- Giám sát lưu lượng API theo thời gian thực với dashboard trực quan, cảnh báo bất thường tức thì qua email và webhook
- Tích hợp CDN toàn cầu giảm độ trễ API đồng thời tăng khả năng chịu tải, phù hợp với kiến trúc microservices phân tán
- Triển khai nhanh không cần thay đổi cơ sở hạ tầng hiện có, phù hợp với doanh nghiệp cần bổ sung lớp bảo mật API mà không gián đoạn hệ thống đang chạy
VNIS phù hợp với các đội ngũ IT không muốn quản lý hạ tầng bảo mật riêng lẻ, trong khi vẫn cần mức độ bảo vệ API đạt chuẩn doanh nghiệp. Nền tảng này cũng hỗ trợ Developer tích hợp quy tắc bảo mật tùy chỉnh theo đặc thù từng API endpoint thông qua giao diện quản lý tập trung.
7. Kết luận
API security là nền tảng không thể bỏ qua trong chiến lược bảo mật của bất kỳ tổ chức nào đang vận hành hệ thống số. Từ việc hiểu đúng bản chất của bảo mật API, nhận diện các mối đe dọa theo OWASP API Security Top 10, đến áp dụng đúng lớp bảo vệ phù hợp với từng ngữ cảnh, mỗi bước đều đòi hỏi sự kết hợp chặt chẽ giữa IT Manager, Developer và đội bảo mật.
Liên hệ đội ngũ VNETWORK để được tư vấn và demo thực tế:
- Hotline: 028 7306 8789
- Email: contact@vnetwork.vn
FAQ - Câu hỏi thường gặp về API security
1. Doanh nghiệp nhỏ có cần triển khai API security không?
Có. Doanh nghiệp nhỏ thường là mục tiêu dễ tấn công hơn vì ít có nguồn lực để vá lỗ hổng kịp thời. Nếu hệ thống có API kết nối với ứng dụng mobile, thanh toán trực tuyến hoặc tích hợp bên thứ ba, bảo mật API là bắt buộc dù quy mô tổ chức nhỏ hay lớn.
2. API gateway có đủ để bảo mật API không?
Không. API gateway xử lý tốt việc xác thực, routing và rate limiting nhưng không phải là giải pháp bảo mật toàn diện. API gateway cần được kết hợp với WAF lớp 7, validate input ở tầng ứng dụng và hệ thống giám sát để tạo thành tuyến phòng thủ đa lớp.
3. Làm thế nào để kiểm tra lỗ hổng bảo mật API?
Quy trình kiểm thử bảo mật API thường bao gồm: kiểm thử thủ công theo danh sách OWASP API Security Top 10, fuzz testing tự động để phát hiện lỗi xử lý input bất thường, và kiểm tra schema validation để đảm bảo API chỉ chấp nhận đúng cấu trúc dữ liệu được định nghĩa. Nên thực hiện định kỳ và đặc biệt trước mỗi lần phát hành phiên bản mới.
4. OWASP API Security Top 10 là gì?
OWASP API Security Top 10 là danh sách 10 lỗ hổng bảo mật API phổ biến và nguy hiểm nhất do tổ chức OWASP (Open Web Application Security Project) công bố. Danh sách này được cập nhật định kỳ dựa trên dữ liệu thực tế từ cộng đồng bảo mật toàn cầu và là tài liệu tham chiếu tiêu chuẩn cho các đội ngũ bảo mật, Developer và kiểm thử viên.
5. API security có liên quan đến tiêu chuẩn ISO 27001 không?
Có. ISO 27001 yêu cầu tổ chức thiết lập kiểm soát truy cập, mã hóa dữ liệu và giám sát hệ thống thông tin, tất cả đều áp dụng trực tiếp cho API. Việc triển khai API security đúng chuẩn là một phần trong lộ trình đạt chứng nhận ISO 27001, đặc biệt liên quan đến các control thuộc Annex A về kiểm soát truy cập và mật mã.