API Security là gì? Hướng dẫn bảo mật API Gateway, REST, GraphQL, OAuth, JWT và Rate Limiting

Ảnh preview GitHub Open Graph của repo OWASP/API-Security, dùng làm minh họa cho OWASP API Security. Ảnh raster, không phải SVG.¹

Ảnh preview GitHub Open Graph của repo Kong/kong, dùng làm minh họa cho API Gateway. Ảnh raster, không phải SVG.²

Ảnh preview GitHub Open Graph của repo envoyproxy/envoy, dùng làm minh họa cho proxy/service mesh/API traffic. Ảnh raster, không phải SVG.³

Ảnh preview GitHub Open Graph của repo apache/apisix, dùng làm minh họa cho API Gateway mã nguồn mở. Ảnh raster, không phải SVG.⁴

Tóm tắt nhanh

API Security là tập hợp các phương pháp bảo vệ API khỏi truy cập trái phép, lạm dụng, rò rỉ dữ liệu, tấn công logic nghiệp vụ, injection, SSRF, brute force, credential stuffing, denial of service và lỗi cấu hình. API có thể là REST, GraphQL, gRPC, WebSocket hoặc internal service-to-service API.

OWASP API Security Top 10 2023 xếp các rủi ro hàng đầu gồm Broken Object Level Authorization, Broken Authentication, Broken Object Property Level Authorization, Unrestricted Resource Consumption, Broken Function Level Authorization, Unrestricted Access to Sensitive Business Flows, SSRF, Security Misconfiguration, Improper Inventory Management và Unsafe Consumption of APIs.⁵ RFC 9700, OAuth 2.0 Security Best Current Practice, cập nhật và mở rộng hướng dẫn bảo mật OAuth 2.0 để phản ánh các kinh nghiệm thực tế và mối đe dọa mới.⁶

Nói đơn giản: API Security không chỉ là “có JWT là xong”. Bạn cần thiết kế đúng authentication, authorization, input validation, rate limiting, schema validation, logging, token security, mTLS, API inventory, gateway policy và runtime monitoring.

Vì sao API là mục tiêu tấn công lớn?

API thường là đường đi trực tiếp tới dữ liệu và logic nghiệp vụ. Frontend có thể thay đổi, mobile app có thể bị reverse engineering, nhưng API vẫn là nơi xử lý request thật.

Một request API có thể:

Client
  ↓
API Gateway / WAF
  ↓
Auth service
  ↓
Business API
  ↓
Database / Queue / Third-party API

Nếu API kiểm soát yếu, attacker có thể:

• đổi user_id để đọc dữ liệu người khác;
• gọi endpoint admin không được bảo vệ;
• brute force login hoặc OTP;
• gửi payload lớn làm tốn CPU/memory;
• spam flow mua vé/đăng ký/đặt hàng;
• khai thác SSRF để gọi metadata service;
• tận dụng GraphQL query sâu để làm quá tải;
• dùng token bị lộ để truy cập dữ liệu;
• khai thác API cũ không còn ai quản lý;
• lợi dụng third-party API response không tin cậy.

API Security không phải là gì?

HTTPS cần thiết, nhưng không đủ. JWT phổ biến, nhưng không đủ. API Gateway hữu ích, nhưng không thay thế authorization trong business service.

OWASP API Security Top 10 2023 giải thích dễ hiểu

Điểm quan trọng: nhiều lỗi API là lỗi authorization và business logic, không phải lỗi cú pháp code.

API Gateway là gì?

API Gateway là lớp trung gian nhận request từ client, áp chính sách chung, rồi chuyển tiếp tới backend service.

Client
  ↓
API Gateway
  ├── TLS termination
  ├── authentication
  ├── rate limiting
  ├── request validation
  ├── routing
  ├── logging
  ├── WAF / bot protection
  └── mTLS upstream
        ↓
Backend APIs

API Gateway có thể xử lý tốt:

• routing;
• TLS;
• JWT verification;
• OAuth/OIDC integration;
• rate limiting;
• IP allow/deny;
• request size limit;
• schema validation;
• CORS;
• logging/metrics/tracing;
• canary/blue-green routing;
• mTLS tới upstream;
• policy enforcement cơ bản.

Nhưng gateway không nên là nơi duy nhất kiểm tra quyền. Object-level authorization như “user này có được đọc order này không?” phải nằm trong service hoặc authorization layer gần business logic.

API Gateway không thay thế authorization trong service

Ví dụ nguy hiểm:

GET /api/orders/1001
Authorization: Bearer token-of-user-A

Nếu user A đổi thành:

GET /api/orders/1002

Gateway thường không biết order 1002 thuộc user nào. Backend phải kiểm tra:

order.user_id == current_user.id

Nếu backend không kiểm tra, đó là Broken Object Level Authorization.

Authentication và Authorization khác nhau thế nào?

Sai lầm phổ biến: “User đã login nên được truy cập object.” Không đúng. Login chỉ xác định danh tính. Authorization mới quyết định quyền.

OAuth, OIDC và JWT nên hiểu thế nào?

OAuth 2.0

OAuth 2.0 là framework ủy quyền. Nó thường dùng để cấp access token cho client gọi API thay mặt user hoặc service.

Không nên dùng OAuth như một lớp login tự chế nếu bạn chưa hiểu flow.

OpenID Connect

OpenID Connect là lớp identity nằm trên OAuth 2.0. OpenID Connect Core mô tả OIDC là identity layer đơn giản trên OAuth 2.0, cho phép client xác minh danh tính end-user dựa trên authentication của Authorization Server và lấy thông tin hồ sơ cơ bản.⁷

Dùng OIDC cho login/SSO.

JWT

JWT là format token compact, URL-safe để truyền claims giữa hai bên. RFC 7519 mô tả JWT là cách biểu diễn claims bằng JSON object, có thể được ký hoặc mã hóa qua JWS/JWE.⁸

JWT có thể dùng làm access token hoặc ID token, nhưng không phải mọi access token đều phải là JWT.

JWT Security: checklist bắt buộc

Các lỗi JWT phổ biến:

• không verify signature;
• chấp nhận alg=none;
• không kiểm tra iss;
• không kiểm tra aud;
• không kiểm tra exp;
• dùng secret yếu cho HS256;
• dùng cùng key quá lâu;
• nhầm ID token với access token;
• lưu token trong localStorage dễ bị XSS lấy;
• token sống quá lâu;
• không có key rotation;
• không xử lý JWKS cache đúng;
• log token ra hệ thống logging.

Checklist:

Verify signature
Validate issuer (iss)
Validate audience (aud)
Validate expiry (exp)
Validate not-before (nbf) nếu dùng
Validate token type/purpose
Use short-lived access tokens
Rotate signing keys
Do not log tokens
Do not put secrets/PII nhạy cảm vào JWT claims
Use RFC 8725 JWT BCP guidance

RFC 8725 là Best Current Practices cho JSON Web Token và cập nhật RFC 7519.⁹

OAuth 2.0 Security BCP: điểm cần nhớ

RFC 9700 khuyến nghị bảo mật OAuth 2.0 hiện đại và cập nhật các RFC cũ.⁶ Với API hiện đại, nên ưu tiên:

• Authorization Code Flow + PKCE cho web/mobile/public clients;
• không dùng Implicit Flow cho ứng dụng mới;
• redirect URI validation chặt;
• short-lived access token;
• refresh token rotation nếu dùng refresh token;
• scope hạn chế;
• audience-bound access token;
• sender-constrained token nếu rủi ro cao;
• mTLS hoặc DPoP nếu cần chống token replay;
• không dùng Resource Owner Password Credentials Grant cho ứng dụng mới;
• bảo vệ authorization server metadata;
• log và phát hiện token abuse.

API Keys dùng khi nào?

API key đơn giản và phổ biến cho server-to-server hoặc developer platform. Nhưng API key thường chỉ xác định “app/client”, không xác định user.

Dùng API key cho:

• public developer API;
• service integration đơn giản;
• usage tracking;
• rate limiting theo client;
• automation nội bộ ít rủi ro.

Không nên chỉ dùng API key cho:

• quyền user nhạy cảm;
• dữ liệu cá nhân;
• admin API;
• transaction tài chính;
• flow cần consent/user identity.

API key checklist:

• key đủ dài và random;
• hash key khi lưu nếu có thể;
• prefix để identify key;
• scope key theo quyền;
• expiry/rotation;
• rate limit theo key;
• revoke nhanh;
• không gửi key trong URL query;
• không log key;
• hiển thị key một lần khi tạo.

mTLS dùng khi nào?

mTLS là mutual TLS: client và server đều xác thực certificate của nhau. RFC 8705 định nghĩa OAuth 2.0 Mutual-TLS Client Authentication và Certificate-Bound Access Tokens.¹⁰

Dùng mTLS khi:

• service-to-service API nội bộ;
• B2B API nhạy cảm;
• tài chính/ngân hàng;
• workload identity;
• muốn chống token replay tốt hơn;
• cần xác thực machine-to-machine mạnh.

mTLS không thay thế authorization. Nó xác thực client/service, nhưng service vẫn phải kiểm tra client đó được gọi tài nguyên nào.

Rate limiting và quota

Rate limiting giúp chặn spam, brute force, scraping, bot abuse và resource exhaustion.

Các kiểu limit:

RFC 9333 định nghĩa các HTTP RateLimit fields để server truyền thông tin rate limit như limit, remaining và reset cho client.¹¹

Gợi ý:

/login: strict per account + per IP + bot detection
/search: per user + per IP + cache
/export: strict quota + async job
/graphql: query complexity + depth limit + timeout
/payment: idempotency key + anti-replay + business limit

Input validation và schema validation

API nên validate dữ liệu ở nhiều lớp:

• gateway validate size/content-type/schema cơ bản;
• service validate business rules;
• database enforce constraints;
• output filter theo quyền.

Ví dụ OpenAPI schema giúp định nghĩa:

• endpoint;
• method;
• path params;
• query params;
• request body;
• response shape;
• auth scheme;
• status code;
• version.

OpenAPI Initiative là tổ chức quản lý OpenAPI Specification, một chuẩn mô tả HTTP APIs.¹²

Schema validation nên chặn:

• field không mong muốn;
• type sai;
• string quá dài;
• array quá lớn;
• nested object quá sâu;
• file upload sai content-type;
• request body vượt kích thước;
• enum ngoài danh sách;
• date/time sai format.

REST API Security checklist

• Dùng HTTPS bắt buộc.
• Không gửi token trong query string.
• Authorization theo object ownership.
• Authorization theo function/role.
• Validate input bằng schema.
• Limit request size.
• Rate limit endpoint nhạy cảm.
• Dùng idempotency key cho payment/order.
• Không expose stack trace.
• Không trả field nhạy cảm nếu user không có quyền.
• Log request_id/user_id_hash/trace_id.
• Có API versioning.
• Deprecate API cũ có kế hoạch.
• Test BOLA/BFLA.
• Security headers và CORS đúng.

GraphQL Security checklist

GraphQL có rủi ro riêng vì client có thể tự chọn query shape. GraphQL.org có tài liệu riêng về security, gồm validation, authorization, query depth, breadth, batch limiting và rate limiting.¹³

Checklist:

• depth limit;
• complexity/cost limit;
• timeout;
• disable introspection ở production nếu không cần;
• persisted queries cho client chính thức;
• field-level authorization;
• object-level authorization;
• rate limit theo cost;
• pagination bắt buộc;
• giới hạn batch query;
• không expose resolver error chi tiết;
• log operation name/hash;
• schema review khi thêm field nhạy cảm.

Ví dụ lỗi:

query {
  users {
    id
    email
    orders {
      id
      paymentInfo {
        cardLast4
      }
    }
  }
}

Nếu thiếu field-level authorization, user có thể lấy dữ liệu nhạy cảm ngoài quyền.

CORS: cấu hình sai dễ lộ dữ liệu

CORS không phải cơ chế auth. CORS chỉ cho browser biết origin nào được đọc response.

Sai lầm phổ biến:

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

Khuyến nghị:

• allowlist origin cụ thể;
• không dùng wildcard cho credentialed request;
• tách origin dev/staging/prod;
• không reflect Origin bừa bãi;
• kiểm soát method/header;
• preflight cache hợp lý;
• không xem CORS là lớp bảo mật duy nhất.

SSRF trong API

SSRF xảy ra khi API nhận URL từ user rồi server fetch URL đó mà không validate kỹ. OWASP API7:2023 nói SSRF có thể xảy ra khi API fetch remote resource mà không validate URI do user cung cấp, khiến attacker ép app gửi request tới đích không mong muốn.⁵

Ví dụ nguy hiểm:

POST /fetch-url
{
  "url": "http://169.254.169.254/latest/meta-data/"
}

Phòng tránh:

• allowlist domain;
• block private IP ranges;
• resolve DNS và re-check IP;
• disable redirect hoặc kiểm soát redirect;
• timeout ngắn;
• block non-http schemes;
• không gửi credential khi fetch;
• egress firewall;
• metadata service protection;
• proxy outbound chuyên dụng.

API Inventory và lifecycle

OWASP API9:2023 nhấn mạnh improper inventory management vì API thường expose nhiều endpoint hơn web app truyền thống, nên documentation và inventory cập nhật là quan trọng.⁵

Cần biết:

• API nào đang public/internal/partner;
• owner là ai;
• version nào đang chạy;
• endpoint nào deprecated;
• auth scheme nào dùng;
• data classification;
• rate limit;
• logs/monitoring;
• dependency downstream;
• environment dev/staging/prod.

Không có inventory, bạn không thể bảo vệ API cũ.

Logging và Monitoring cho API Security

Nên log:

• request_id/trace_id;
• user_id hash;
• client_id/API key id;
• endpoint/method/status;
• latency;
• auth failure reason dạng an toàn;
• rate limit event;
• policy deny;
• suspicious input;
• token issuer/audience mismatch;
• unusual geographic/device pattern;
• admin action;
• export/download;
• third-party API failure.

Không log:

• access token;
• refresh token;
• API key;
• password;
• OTP;
• full credit card;
• private data không cần thiết;
• raw sensitive payload.

Alert nên có:

Login failure spike
Token validation failure spike
403 spike trên endpoint nhạy cảm
Rate limit exceeded spike
SSRF pattern
High 5xx sau deploy
GraphQL query cost spike
Mass export/download
Deprecated API traffic
Third-party API abnormal response

API Security testing

Nên test cả tự động và thủ công.

Tự động

• OpenAPI schema lint;
• SAST;
• dependency scan;
• DAST;
• fuzzing;
• contract testing;
• secrets scanning;
• container scanning;
• IaC scanning;
• API endpoint discovery.

Thủ công

• BOLA test: đổi object ID;
• BFLA test: gọi chức năng admin;
• property-level auth test: thêm field không được phép;
• mass assignment test;
• rate limit bypass;
• token tampering;
• CORS test;
• SSRF test;
• GraphQL depth/cost abuse;
• business logic abuse.

OWASP ZAP là một công cụ proxy/security testing phổ biến có thể hỗ trợ kiểm thử web/API ở nhiều mức độ.¹⁴

Roadmap triển khai 30/60/90 ngày

Ngày 1–30: nền tảng

• Lập API inventory.
• Bắt buộc HTTPS.
• Chuẩn hóa auth: OAuth/OIDC/JWT/API key.
• Kiểm tra JWT validation: iss, aud, exp, signature.
• Thêm rate limiting cho login, OTP, search, export.
• Log request_id/trace_id/client_id.
• Tắt debug endpoint và stack trace.
• Thiết lập CORS allowlist.
• Chặn request body quá lớn.
• Review endpoint nhạy cảm theo OWASP API Top 10.

Ngày 31–60: gateway và policy

• Đưa API quan trọng sau API Gateway.
• Thêm schema validation từ OpenAPI.
• Tách public/internal/admin API.
• Thêm RBAC/ABAC policy.
• Kiểm tra BOLA/BFLA trong test suite.
• Thêm GraphQL depth/cost limit nếu dùng GraphQL.
• Thêm mTLS cho service-to-service hoặc partner API nhạy cảm.
• Tạo dashboard API: rate, error, latency, auth failures.
• Alert cho abuse pattern.

Ngày 61–90: nâng cao

• Token rotation và JWKS cache policy.
• Sender-constrained token bằng mTLS/DPoP nếu cần.
• Bot detection cho flow nhạy cảm.
• API discovery/shadow API detection.
• DAST/fuzzing định kỳ.
• Threat modeling cho API quan trọng.
• Security review third-party API consumption.
• Deprecated API retirement plan.
• Fine-grained authorization service nếu hệ thống lớn.
• Incident playbook: leaked token/API key, BOLA, mass scraping.

Checklist triển khai nhanh

Auth

• OIDC cho user login.
• OAuth access token cho API.
• API key cho developer/server integration nếu phù hợp.
• mTLS cho machine-to-machine nhạy cảm.
• Không tự chế token nếu không cần.
• Không dùng long-lived token cho public client.

JWT

• Verify signature.
• Validate iss, aud, exp, nbf.
• Kiểm tra algorithm allowlist.
• Key rotation.
• Không log token.
• Không chứa PII nhạy cảm.
• Access token ngắn hạn.
• Refresh token bảo vệ riêng.

Authorization

• Object-level authorization.
• Property-level authorization.
• Function-level authorization.
• RBAC/ABAC rõ ràng.
• Deny by default.
• Policy test trong CI.
• Audit admin action.

Gateway

• TLS.
• Routing.
• Rate limit.
• Request size limit.
• Schema validation.
• JWT verification.
• CORS policy.
• Logging/tracing.
• WAF/bot protection nếu cần.

Data

• Không trả field nhạy cảm mặc định.
• Output filtering theo quyền.
• Pagination bắt buộc.
• Export cần quyền riêng.
• Data classification.
• Masking/tokenization nếu cần.

Runtime

• Dashboard API.
• Alert auth/rate/security events.
• Detect deprecated API traffic.
• Monitor third-party API.
• Incident runbook.
• Log retention và privacy policy.

Tooling tham khảo

Sai lầm phổ biến

• Tin rằng API Gateway thay thế được authorization trong service.
• Dùng JWT nhưng không validate aud hoặc iss.
• ID token bị dùng nhầm như access token.
• Token sống quá lâu.
• API key gửi trong URL.
• CORS wildcard với credentials.
• Không có rate limit cho login/OTP/export.
• GraphQL không giới hạn depth/cost.
• Không có API inventory.
• API cũ vẫn chạy không ai biết.
• Log access token vào log platform.
• Tin dữ liệu từ third-party API quá mức.
• Chỉ test happy path, không test authorization bypass.
• Không có owner cho API.

FAQ

API Security là gì?

API Security là thực hành bảo vệ API khỏi truy cập trái phép, lạm dụng, rò rỉ dữ liệu, lỗi authorization, injection, SSRF, resource exhaustion và cấu hình sai.

API Gateway có đủ để bảo mật API không?

Không. API Gateway giúp áp chính sách chung như TLS, JWT verification, rate limit, logging và routing. Nhưng object-level authorization, property-level authorization và business rules vẫn phải nằm trong backend service hoặc authorization layer gần business logic.

OAuth khác OIDC thế nào?

OAuth 2.0 là framework ủy quyền. OpenID Connect là identity layer trên OAuth 2.0, dùng cho authentication/login và truyền thông tin user qua ID token.⁷

JWT có an toàn không?

JWT là format token. An toàn hay không phụ thuộc cách phát hành, ký, validate, lưu trữ, rotation và lifetime. RFC 7519 định nghĩa JWT; RFC 8725 đưa ra best current practices cho JWT.⁸⁹

Rate limiting nên đặt ở đâu?

Nên đặt ở gateway/WAF để chặn sớm, nhưng một số business limit phải đặt trong service, ví dụ số lần đặt vé, số lần gửi OTP, số lần export dữ liệu hoặc quota theo tenant.

GraphQL có nguy hiểm hơn REST không?

Không nhất thiết, nhưng GraphQL có rủi ro riêng như query depth, query complexity, batch abuse, introspection exposure và field-level authorization. Cần policy riêng cho GraphQL.¹³

Kết luận

API Security là một phần cốt lõi của hệ thống IT hiện đại. API thường là nơi dữ liệu và logic nghiệp vụ được truy cập trực tiếp, nên lỗi authorization, token validation, rate limiting hoặc inventory có thể gây thiệt hại lớn. Cách làm đúng là kết hợp nhiều lớp: gateway policy, OAuth/OIDC/JWT chuẩn, authorization trong service, schema validation, rate limiting, mTLS, logging, monitoring và kiểm thử bảo mật liên tục.

Hãy bắt đầu từ API inventory, HTTPS, token validation, rate limit cho endpoint nhạy cảm, CORS đúng, logging an toàn và kiểm tra OWASP API Security Top 10. Sau đó mở rộng sang schema validation, GraphQL protection, mTLS, API discovery, DAST/fuzzing, fine-grained authorization và incident response.

Nguồn tham khảo

Footnotes

1. GitHub Open Graph preview image for OWASP/API-Security. https://opengraph.githubassets.com/api-security-guide/OWASP/API-Security ↩

2. GitHub Open Graph preview image for Kong/kong. https://opengraph.githubassets.com/api-security-kong-guide/Kong/kong ↩

3. GitHub Open Graph preview image for envoyproxy/envoy. https://opengraph.githubassets.com/api-security-envoy-guide/envoyproxy/envoy ↩

4. GitHub Open Graph preview image for apache/apisix. https://opengraph.githubassets.com/api-security-apisix-guide/apache/apisix ↩

5. OWASP API Security Top 10 2023. https://owasp.org/API-Security/editions/2023/en/0x11-t10/ ↩ ↩² ↩³

6. RFC 9700, Best Current Practice for OAuth 2.0 Security. https://datatracker.ietf.org/doc/html/rfc9700 ↩ ↩²

7. OpenID Connect Core 1.0. https://openid.net/specs/openid-connect-core-1_0.html ↩ ↩²

8. RFC 7519, JSON Web Token. https://datatracker.ietf.org/doc/html/rfc7519 ↩ ↩²

9. RFC 8725, JSON Web Token Best Current Practices. https://datatracker.ietf.org/doc/html/rfc8725 ↩ ↩²

10. RFC 8705, OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens. https://datatracker.ietf.org/doc/html/rfc8705 ↩

11. RFC 9333, RateLimit Fields for HTTP. https://datatracker.ietf.org/doc/html/rfc9333 ↩

12. OpenAPI Initiative. https://www.openapis.org/ ↩

13. GraphQL.org Security. https://graphql.org/learn/security/ ↩ ↩²

14. OWASP ZAP. https://www.zaproxy.org/ ↩