Bảo mật API: Lỗ hổng phổ biến và cách kiểm thử theo OWASP API Top 10

API là nơi ứng dụng web, mobile, đối tác và automation chạm trực tiếp vào dữ liệu cùng nghiệp vụ. Giao diện có thể ẩn một nút, nhưng request vẫn tồn tại; gateway có thể kiểm tra token, nhưng không biết người dùng có được xem đơn hàng cụ thể hay sửa thuộc tính “role” hay không. Vì vậy, một chương trình bảo mật API không bắt đầu từ việc mua gateway. Nó bắt đầu từ inventory, mô hình quyền và hiểu các luồng tạo giá trị hoặc thiệt hại.

Bài này dùng OWASP API Security Top 10 2023 — bản stable chính thức hiện hành — làm khung rủi ro, nhưng chuyển nó thành câu hỏi mua và kiểm thử cho doanh nghiệp. Top 10 là tài liệu nhận thức, không phải checklist chứng nhận và cũng không bảo đảm bao phủ mọi kiến trúc. Scope phải được điều chỉnh theo REST, GraphQL, gRPC, webhook, async messaging và logic của chính hệ thống.

Vì sao API dễ “đúng kỹ thuật” nhưng sai quyền?

API thường xử lý một request hợp lệ về cú pháp: token còn hạn, JSON đúng schema, route tồn tại. Nhưng quyết định an ninh nằm sâu hơn: token này có được truy cập object này, field này, action này, trong tenant này và trạng thái nghiệp vụ này không? Khi authorization bị trải giữa gateway, service, database policy và client, một giả định lệch có thể mở dữ liệu hàng loạt mà không tạo lỗi hệ thống.

• Mobile/web client không phải security boundary: kẻ tấn công có thể tự gửi request và bỏ mọi kiểm tra phía giao diện.
• Identifier khó đoán không thay authorization; UUID chỉ làm enumeration chậm hơn, không biến dữ liệu thành riêng tư.
• Microservice tăng số trust boundary: service-to-service token, queue, cache và internal API đều cần owner cùng policy.
• API phát triển theo version; endpoint cũ, debug route hoặc shadow API có thể vẫn truy cập database dù không còn trong tài liệu.
• Logic chống abuse phải hiểu hành vi theo user, device, tenant và business action; rate limit theo IP đơn thuần dễ bị vượt hoặc chặn nhầm.

OWASP API Security Top 10 2023 dưới góc nhìn doanh nghiệp

BOLA là Broken Object Level Authorization; BOPLA là Broken Object Property Level Authorization; BFLA là Broken Function Level Authorization. Ba tên khác nhau cùng nhắc một nguyên tắc: quyết định quyền phải bám đối tượng, thuộc tính và hành động, không chỉ trạng thái “đã đăng nhập”. Việc gộp chúng thành một middleware `isAuthenticated` là nguồn gốc của nhiều lỗ hổng logic.

Authorization: kiểm tra object, property và function như thế nào?

Dựng ma trận principal–resource–action–condition. Principal gồm anonymous, customer A/B, merchant, support, admin, service account. Resource gồm profile, invoice, payout, API key, report. Action gồm read, create, update, approve, delete, export. Condition gồm tenant, ownership, trạng thái, hạn mức và segregation of duties. Ma trận này vừa là đầu vào test vừa là artefact để product, backend và security thống nhất kỳ vọng.

• Đổi object ID giữa hai tài khoản cùng vai trò và giữa hai tenant; kiểm tra cả object lồng, export, attachment và history.
• Thêm field không hiển thị trên client, sửa field read-only, dùng nested object hoặc content type khác để tìm mass assignment.
• Gọi admin/support route bằng user token; thử method, version, alternate path và batch endpoint tương đương.
• Kiểm tra authorization sau thay đổi trạng thái: đơn đã khóa, tài khoản bị vô hiệu, lời mời hết hạn, quyền vừa bị thu hồi.
• Kiểm tra indirect reference qua webhook, async job, file URL và cache; quyết định quyền phải tồn tại ở điểm tiêu thụ, không chỉ điểm tạo.

Authentication và abuse: hai lớp thường bị trộn lẫn

Authentication xác định danh tính; abuse control hạn chế cách một danh tính hoặc bot sử dụng workflow. Kiểm thử login, reset password, refresh/revoke token, MFA enrollment/recovery, OAuth redirect/scope, API key lifecycle và service account. Với JWT, kiểm tra validation issuer, audience, algorithm, key rotation, expiration và quyền lấy từ nguồn nào; không chỉ decode payload rồi nhìn thấy chữ ký.

Business flow nhạy cảm có thể hoàn toàn hợp lệ từng request nhưng gây hại ở quy mô: giữ hàng, tạo coupon, gửi OTP, scrape giá, mở tài khoản hoặc thử credential. Rate limit cần gắn với cost và identity graph phù hợp, có quota, cooldown, step-up verification, idempotency và detection. CAPTCHA/Turnstile có thể tăng chi phí bot ở điểm hợp lý nhưng không thay rule server-side và không nên chặn luồng máy–máy hợp pháp.

Inventory và vòng đời: không quản được thứ mình không nhìn thấy

Catalog API tối thiểu cần host/base path, protocol, version, owner, consumer, môi trường, exposure, authentication, dữ liệu, dependency, repository, gateway và retirement status. Kết hợp nguồn từ gateway, code, cloud, DNS, mobile app và traffic; tài liệu thủ công một nguồn luôn có blind spot. Đặt owner và ngày review, vì inventory không có người chịu trách nhiệm sẽ già đi như mọi spreadsheet khác.

Retirement phải có telemetry để biết consumer còn dùng, thông báo, migration, chặn dần và xác minh dữ liệu/credential cũ. API v1 không còn link trên frontend vẫn có thể được bot gọi. Shadow API tìm thấy phải được phân loại: đưa vào quản trị, cô lập hoặc gỡ; đừng chỉ thêm vào scanner rồi coi là xong. Inventory cũng là đầu vào cho RFP và scope pentest, giúp vendor báo effort thay vì đoán.

Thiết kế một đợt pentest API có giá trị

1. Chốt mục tiêu và dữ liệu. Xác định flow critical, loại dữ liệu và abuse case mà lãnh đạo cần assurance.
2. Cung cấp artefact. OpenAPI/GraphQL schema, Postman collection, auth flow, kiến trúc, role matrix và thay đổi gần đây; white/grey box tăng độ sâu.
3. Chuẩn bị test identities. Nhiều user cùng vai trò, khác tenant, role cao/thấp, service account và dữ liệu liên kết; không chia một admin account cho tất cả.
4. Xác định coverage. Route/operation, object/property/function auth, workflow, resource consumption, SSRF, config, inventory và third-party consumption.
5. Viết RoE. Rate, payload, concurrency, callback domain, egress, production restrictions, stop condition và critical escalation.
6. Yêu cầu evidence có trách nhiệm. Request/response đã redact, test IDs, điều kiện, impact và fix; không lưu token hoặc dữ liệu thật không cần thiết.
7. Re-test và regression. Xác minh fix, bypass và test tự động chống tái phát; finding logic cần quay lại threat model và coding pattern.

Scanner dựa trên schema hữu ích cho coverage, fuzzing và misconfiguration, nhưng tester cần hiểu state và relationship. Hãy yêu cầu nhà cung cấp giải thích effort thủ công, cách test authorization và business flow. Chi phí pentest tăng theo số role, tenant, operation và logic; giảm chúng khỏi scope phải được ghi thành limitation chứ không biến mất trong proposal.

Đưa bảo mật API vào SDLC mà không chờ pentest

Định nghĩa authorization requirement và abuse case trong thiết kế; dùng schema contract, input allowlist, safe defaults và centralized policy khi phù hợp nhưng giữ kiểm tra gần resource. Code review tập trung controller/service nào lấy object trước khi authorize, mass assignment, outbound request và secret. CI chạy unit/integration test với nhiều principal; DAST/schema fuzzing bổ sung chứ không thay test logic.

• Gateway: authentication, coarse policy, rate/quota, schema limit, routing và telemetry — không gánh toàn bộ business authorization.
• Service: object/property/function authorization, state transition, validation và idempotency.
• Platform: secrets, mTLS/service identity, egress control, logging có correlation ID và bảo vệ log khỏi token/PII.
• Operations: alert theo hành vi, inventory drift, key/token anomaly, error spike và access pattern chéo tenant.
• Governance: owner, classification, deprecation, third-party review và incident playbook cho credential/data exposure.

Khi có dấu hiệu lạm dụng hoặc rò dữ liệu, cần nối API telemetry vào kế hoạch 72 giờ đầu ứng phó sự cố: bảo toàn log, thu hồi token/key, giới hạn flow, xác định object bị truy cập và đánh giá nghĩa vụ thông báo. Logging phải được thiết kế trước; sau sự cố không thể tái tạo request context mà hệ thống chưa từng ghi.

Kết luận: bảo mật API là bài toán quyền và vòng đời

OWASP API Top 10 giúp đặt tên các failure mode, nhưng doanh nghiệp giảm rủi ro bằng ownership, role/resource matrix, inventory sống, test nhiều ngữ cảnh và telemetry có thể điều tra. Gateway tốt làm nền; authorization đúng trong nghiệp vụ mới giữ dữ liệu. Pentest tốt kiểm chứng các giả định đó và biến lỗi tìm thấy thành test chống tái phát.