Checklist bảo mật API trước khi ra mắt

Cách dùng checklist này trước giờ mở production

Checklist bảo mật API trước khi ra mắt nên là một release gate có bằng chứng, không phải danh sách được đánh dấu theo cảm giác. Với mỗi mục, đội ngũ cần ghi rõ endpoint hoặc luồng liên quan, tài khoản kiểm thử, request, response mong đợi, người xử lý và trạng thái retest.

Friday Works nhóm các kiểm tra theo rủi ro thực tế của web app, mobile app và hệ thống tích hợp. Cấu trúc này tham chiếu OWASP API Security Top 10 2023, đồng thời bổ sung kiểm soát trước runtime và runtime theo NIST SP 800-228. Checklist là baseline để sàng lọc; hệ thống xử lý thanh toán, dữ liệu nhạy cảm hoặc nhiều tenant vẫn cần đánh giá theo phạm vi cụ thể.

Trước khi chạy, hãy chốt danh sách host, version, endpoint, vai trò, tenant, dữ liệu thử và bên thứ ba. Chỉ kiểm thử chủ động trên môi trường và tài sản đã được phép; không dùng production làm nơi thử payload có thể thay đổi dữ liệu nếu chưa có kế hoạch an toàn.

• ✓Định nghĩa owner và người có quyền quyết định go/no-go.
• ✓Lập inventory host, version, endpoint, webhook và API bên thứ ba.
• ✓Tạo ít nhất hai tài khoản ở hai tenant cùng các vai trò user, quản trị hoặc vận hành phù hợp.
• ✓Chuẩn bị dữ liệu giả, cơ chế rollback và giới hạn phạm vi kiểm thử.
• ✓Gắn bằng chứng và retest vào từng phát hiện trước khi đóng release gate.

Một checklist tốt không hỏi API có chạy hay không; nó buộc đội ngũ chứng minh API từ chối đúng request sai.

1. Xác thực, token và phiên làm việc

API phải phân biệt chính xác ai hoặc hệ thống nào đang gọi trước khi xử lý chức năng không công khai. Test không token, token sai chữ ký, hết hạn, sai issuer hoặc audience, token của môi trường khác và token đã bị thu hồi. Đừng chỉ test happy path bằng một token hợp lệ.

Với OAuth hoặc OIDC, dùng flow phù hợp với loại client và tránh tự thiết kế cơ chế đăng nhập riêng. Với JWT, server phải khóa thuật toán được chấp nhận, kiểm tra toàn bộ claim bắt buộc và không quyết định thuật toán chỉ dựa trên dữ liệu do token cung cấp. API key cần scope tối thiểu, thời hạn hoặc cơ chế xoay vòng, và không được nhúng vào mã client có thể tải về.

Endpoint đăng nhập, refresh, quên mật khẩu, OTP và cấp token cần rate limit, phát hiện lạm dụng và phản hồi không làm lộ tài khoản tồn tại. Log sự kiện xác thực phải hữu ích cho điều tra nhưng không ghi secret hoặc token thô.

• ✓Endpoint riêng tư trả 401 khi thiếu, sai, hết hạn hoặc bị thu hồi credential.
• ✓JWT kiểm tra chữ ký, thuật toán, expiry, issuer, audience và clock skew đã định nghĩa.
• ✓Refresh token có rotation hoặc cơ chế thu hồi phù hợp; logout thực sự kết thúc quyền sử dụng tiếp.
• ✓API key có scope, owner, ngày tạo, trạng thái và quy trình rotate/revoke.
• ✓Không có token, secret hay credential thật trong URL, log, client bundle, mobile app hoặc repository.

2. Phân quyền object, property, function và tenant

OWASP xếp Broken Object Level Authorization ở vị trí đầu vì endpoint thường nhận ID do client gửi. Việc user đã đăng nhập không chứng minh họ được đọc, sửa hoặc xóa object đó. Mỗi truy cập dữ liệu theo ID phải kiểm tra owner, tenant và policy ở server.

Tạo ma trận role × action × object rồi biến thành negative tests. Dùng tài khoản A đọc hoặc sửa object của B; dùng user thường gọi route quản trị; thay tenant ID, organization ID, parent ID, HTTP method và field nhạy cảm. Response cũng phải lọc property theo quyền, còn request không được mass-assign các trường như role, price, status hoặc owner.

Không lấy ID ngẫu nhiên hoặc UUID làm lớp phân quyền. ID khó đoán chỉ giảm khả năng dò tuần tự; kiểm tra quyền vẫn phải chạy cho từng request và từng object.

• ✓User A không thể đọc, sửa hoặc xóa object của user B khi thay ID.
• ✓Tenant A không thể truy cập dữ liệu tenant B qua path, query, body, header hoặc nested object.
• ✓User thường không gọi được function quản trị dù biết URL hay đổi HTTP method.
• ✓Response không trả field nhạy cảm ngoài nhu cầu và quyền của caller.
• ✓Request chỉ bind field cho phép; role, owner, price, approval và trạng thái được kiểm soát phía server.
• ✓Policy được test ở endpoint batch, export, search, file, webhook và GraphQL resolver nếu có.

3. Input, output, tài nguyên và luồng nghiệp vụ

Validate schema, kiểu, độ dài, enum, format và quan hệ giữa các field ở server. Giới hạn kích thước body, file, số phần tử batch, độ sâu JSON hoặc GraphQL, pagination và thời gian xử lý. Error response phải ổn định, không lộ stack trace, câu SQL, đường dẫn nội bộ hoặc cấu hình hạ tầng.

Rate limit không chỉ là số request mỗi IP. Hãy đặt quota theo user, token, tenant, endpoint và chi phí thực tế. Một request gửi email, tạo báo cáo, gọi AI, xuất file hoặc kích hoạt SMS có thể tốn tiền và tài nguyên khác nhau. OWASP gọi đây là Unrestricted Resource Consumption.

Ngoài tài nguyên kỹ thuật, test các business flow nhạy cảm như đăng ký tài khoản, giữ chỗ, áp mã, đặt hàng, gửi lời mời, hoàn tiền hoặc vote. API có thể đúng về code nhưng vẫn bị bot khai thác ở tốc độ máy.

• ✓Schema từ chối field lạ, sai kiểu, quá dài, giá trị ngoài enum và payload vượt giới hạn.
• ✓Pagination, batch, upload, query depth, timeout và chi phí downstream đều có trần.
• ✓Rate limit áp theo định danh phù hợp và trả tín hiệu nhất quán để client xử lý.
• ✓Luồng tốn tiền như email, SMS, AI, export và payment có quota cùng cảnh báo riêng.
• ✓URL do người dùng cung cấp được allowlist/validate để giảm SSRF; chặn đích nội bộ và redirect nguy hiểm.
• ✓Error không lộ secret, token, stack trace, SQL, hostname hoặc cấu trúc nội bộ.

4. Secret, cấu hình, inventory và API bên thứ ba

Secret phải nằm trong hệ thống quản lý phù hợp, được cấp theo least privilege và có khả năng rotate mà không cần sửa mã nguồn. Kiểm tra credential ở CI/CD, biến môi trường, log, backup, image container và file cấu hình; xóa secret khỏi Git hiện tại chưa đủ nếu nó từng xuất hiện trong lịch sử.

Lập inventory gồm hostname, environment, base path, version, owner, dữ liệu xử lý, tình trạng public/internal và ngày ngừng hỗ trợ. So sánh tài liệu OpenAPI hoặc GraphQL schema với route thực tế để phát hiện shadow API, debug endpoint, version cũ và host staging bị public.

Dữ liệu từ API bên thứ ba vẫn là input không tin cậy. Xác minh TLS và chữ ký webhook khi có, đặt timeout, retry có giới hạn, circuit breaker, schema validation và idempotency. Không để lỗi hoặc response bất thường từ nhà cung cấp phá vỡ boundary của hệ thống mình.

• ✓Secret không nằm trong source, client, log, URL, ticket hoặc artifact build.
• ✓Mỗi credential có owner, scope tối thiểu, cơ chế rotate/revoke và audit trail.
• ✓Production tắt debug, sample route, directory listing và cấu hình mặc định không cần thiết.
• ✓OpenAPI/schema, gateway và route triển khai thực tế khớp nhau; version cũ có kế hoạch retire.
• ✓Webhook xác minh chữ ký, timestamp và chống replay; handler có idempotency.
• ✓API bên thứ ba có timeout, validation, retry có giới hạn và xử lý fail-closed cho quyết định nhạy cảm.

5. Log, cảnh báo và khả năng điều tra

Log bảo mật phải trả lời được ai làm gì, với tài nguyên nào, từ client nào, kết quả ra sao và correlation ID là gì. Nên ghi thất bại xác thực, từ chối phân quyền, thay đổi role hoặc secret, thao tác quản trị, rate-limit spike, webhook lỗi và hành vi bất thường trên business flow.

Không ghi password, API key, access token, refresh token, session ID thô hoặc payload chứa dữ liệu nhạy cảm không cần thiết. Chuẩn hóa redaction và phân quyền truy cập log; nếu log trở thành nơi tập trung bí mật thì chính hệ thống quan sát lại tạo rủi ro mới.

Một alert chỉ có giá trị khi có owner, ngưỡng, kênh nhận và runbook. Trước release, tạo sự kiện thử có kiểm soát để chứng minh log tới đúng nơi, alert kích hoạt và người trực biết bước tiếp theo.

• ✓Mỗi request quan trọng có correlation ID nhưng không dùng ID đó làm credential.
• ✓Sự kiện xác thực, phân quyền, thay đổi đặc quyền và lạm dụng tài nguyên được ghi nhận.
• ✓Log đã redaction secret/PII, có retention, quyền truy cập và bảo vệ chống sửa phù hợp.
• ✓Alert quan trọng có owner, runbook và đã được kiểm tra end-to-end trước launch.

6. Negative test và bằng chứng go/no-go

Functional test chứng minh request đúng được chấp nhận; security negative test chứng minh request sai bị từ chối đúng cách. Bộ test tối thiểu nên bao gồm thiếu/sai token, token sai scope, cross-user, cross-tenant, role thấp gọi function cao, field thừa, payload quá lớn, replay webhook và lạm dụng quota.

Mỗi case cần expected status và expected side effect. Chỉ kiểm tra mã 403 là chưa đủ nếu dữ liệu đã bị thay đổi trước khi response trả về. Với create, payment, email, webhook hoặc job bất đồng bộ, kiểm tra database, queue và downstream để xác nhận không có tác động trái phép.

Friday Works khuyến nghị chốt release bằng ba nhóm bằng chứng: test tự động lặp lại trong CI, kiểm tra thủ công có ngữ cảnh cho phân quyền/nghiệp vụ, và danh sách rủi ro còn lại được owner chấp nhận. Phát hiện quan trọng phải có remediation, retest và người chịu trách nhiệm, không chỉ có ảnh chụp scanner.

• ✓Có test ma trận role, tenant và object cho endpoint nhạy cảm.
• ✓Có test token, input boundary, quota, replay, idempotency và error leakage.
• ✓Kiểm tra cả response lẫn side effect trong database, queue và dịch vụ downstream.
• ✓Lỗi mức nghiêm trọng đã sửa và retest; rủi ro còn lại có owner cùng quyết định chấp nhận rõ ràng.
• ✓Bộ test và inventory được lưu để chạy lại sau thay đổi lớn, không dùng một lần rồi bỏ.

Khi nào checklist chưa đủ?

Checklist phù hợp để đội sản phẩm tự kiểm trước release và tạo baseline có thể lặp lại. Nó chưa đủ khi API xử lý thanh toán, hồ sơ nhạy cảm, nhiều tenant, quyền quản trị phức tạp, webhook public, file upload, URL fetch hoặc luồng có tác động tài chính lớn. Những trường hợp này cần đánh giá theo threat model, tài khoản và dữ liệu thử cụ thể.

Scanner API có thể giúp tìm cấu hình sai và một số mẫu lỗi, nhưng thường không tự suy ra ownership, tenant boundary, điều kiện nghiệp vụ hay side effect bất đồng bộ. Kết quả tốt nhất là kết hợp inventory, automated checks, manual review, bằng chứng request/response và retest sau khắc phục.

Nếu cần một phạm vi độc lập trước launch, Friday Works thực hiện đánh giá bảo mật web app và API theo mục tiêu đã thống nhất, tập trung vào xác thực, phân quyền, input, cấu hình và luồng quan trọng; đầu ra gồm bằng chứng, mức ưu tiên khắc phục và retest theo phạm vi.

• ✓Dùng checklist cho self-review và release gate lặp lại.
• ✓Bổ sung đánh giá có ngữ cảnh khi dữ liệu, tenant hoặc nghiệp vụ có tác động cao.
• ✓Không quảng bá một lần scan là chứng nhận hệ thống an toàn.
• ✓Luôn retest sau sửa và cập nhật checklist từ lỗi thực tế đã phát hiện.