Part 05 · Interview · 5.2
Câu hỏi API, mạng và bảo mật
43 câu hỏi được sắp theo từ protocol semantics tới identity, browser, threat model và production resilience. Hãy trả lời bằng invariant, trade-off và evidence thay vì chỉ gọi tên framework.
Answer pattern: định nghĩa → failure mode → control → trade-off → cách đo hoặc test. Các câu hỏi bên dưới giữ cả phần trả lời nền tảng, chuyên sâu và tình huống từ source.
English framing examples: “HTTP idempotency means repeating a request has the same intended effect as sending it once; it does not require identical response bytes.” · “I debug latency by decomposing DNS, connection, TLS, proxy queue, application, downstream and pool saturation under one end-to-end deadline.”
Core questions
1. Safe khác idempotent?
Safe không yêu cầu thay đổi state theo intent; idempotent nghĩa lặp request có intended effect như một lần. GET safe+idempotent; PUT/DELETE idempotent nhưng không safe.
2. Thiết kế idempotent payment POST?
Key scoped, fingerprint payload, atomic owner/result storage, concurrent duplicate wait/read result, same key khác payload conflict, TTL và audit rõ.
3. 401 khác 403?
401 yêu cầu authentication hợp lệ và thường có WWW-Authenticate; 403 là server hiểu identity/request nhưng từ chối quyền.
4. no-cache khác no-store?
no-cache cho lưu nhưng phải revalidate trước reuse; no-store yêu cầu không lưu.
5. ETag dùng làm gì?
Validator representation cho conditional GET/304 và có thể optimistic concurrency với If-Match.
6. Offset hay cursor pagination?
Cursor/keyset nhanh và ổn định cho dataset thay đổi; cần unique order và opaque cursor. Offset dễ nhảy trang nhưng sâu chậm/drift.
7. Request chậm qua proxy debug thế nào?
Dùng trace/correlation timeline: DNS, connect, TLS, queue proxy, app, DB/downstream; kiểm tra timeout/pool/saturation từng hop và percentile.
8. Connect timeout khác read timeout?
Connect giới hạn thiết lập connection; read giới hạn chờ dữ liệu sau khi kết nối. Cần overall deadline để nhiều phase/retry không vượt budget.
9. JWT có stateless hoàn toàn?
Resource server có thể validate local, nhưng key rotation, revocation, user disable, refresh token và authorization data vẫn có state/coordination.
10. Access token khác ID token?
Access token dành resource server/authorization; ID token chứng minh authentication cho OIDC client. Không gửi ID token như access token.
11. PKCE chống gì?
Ràng buộc authorization request với token exchange bằng verifier/challenge, giảm nguy cơ intercepted authorization code bị attacker đổi token.
12. CORS có bảo vệ API khỏi curl không?
Không. CORS là browser policy cho script đọc response. Server vẫn cần authentication/authorization/rate limit.
13. Khi nào cần CSRF?
Khi browser tự gửi credential như cookie. Bearer token thủ công không có cùng cơ chế nhưng XSS/token storage vẫn là rủi ro.
14. BOLA là gì?
Broken Object Level Authorization: user đổi object ID để truy cập object không thuộc quyền. Phải authorize từng object server-side.
15. SSRF phòng thế nào?
Không cho URL tùy ý; allow-list scheme/host/port, resolve và chặn private/link-local, kiểm soát redirect/DNS rebinding, egress policy và timeout/size.
16. Rate limit theo IP đủ không?
Không: NAT làm nhiều user chung IP, attacker phân tán IP. Kết hợp principal, token, tenant, operation/resource và global capacity.
17. Retry tầng nào?
Một tầng có ownership, bounded exponential backoff+jitter, deadline và idempotency. Retry nhiều tầng nhân attempts thành storm.
18. TLS termination tại proxy có nghĩa backend an toàn?
Không tự động. Proxy→backend là trust boundary khác; cần network policy/mTLS khi cần và chỉ tin forwarded headers từ trusted proxy.
19. Version API thế nào?
Ưu tiên additive backward compatibility, schema evolution và telemetry; breaking change dùng explicit version/deprecation/migration window.
20. Log gì khi security incident?
Actor, action, resource, decision/result, timestamp, request/trace ID và source context; redact token/secret/PII, bảo vệ integrity/retention.
Deep-dive questions
21. DNS TTL hết nhưng client vẫn gọi IP cũ vì sao?
OS/JVM resolver cache hoặc HTTP connection pool giữ connection/IP lâu hơn TTL; load balancer/NAT cũng có state.
22. If-Match chống lost update thế nào?
Client gửi ETag của version đã đọc; server chỉ update nếu current representation match, nếu không trả 412.
23. Cursor cần chứa gì?
Ordered values + unique tie-breaker, filter/version context; opaque/signed nếu chống sửa, và stable semantics khi data đổi.
24. Timeout sau payment charge xử lý ra sao?
Outcome unknown; query/reconcile bằng idempotency key, không retry charge với key mới. Workflow lưu state và provider dùng stable key.
25. JWT kid attack là gì?
Tin kid như path/URL/query có thể injection/SSRF/key confusion. Chỉ lookup trong trusted key set từ configured issuer.
26. state khác nonce trong OIDC?
state bind authorization response với client request/CSRF; nonce bind ID token với authentication request và chống replay.
27. SameSite=Lax có loại hết CSRF?
Không; có browser/flow exceptions, same-site subdomain threats và XSS. Kết hợp token/origin/method discipline.
28. BOLA khác function-level authorization?
BOLA là quyền trên object cụ thể; function-level là quyền gọi chức năng/route. Một user có quyền list nhưng không đọc mọi object.
29. Circuit breaker mở theo dependency hay toàn app?
Scope đủ hẹp theo downstream/operation/tenant nếu cần; breaker toàn app có blast radius lớn và trộn failure modes.
30. Rotate signing key không downtime thế nào?
Publish new public key, signer chuyển new kid, validators accept old+new trong overlap, chờ old tokens expire rồi retire và audit.
Foundation and scenario follow-ups
31. JWT là gì, hoạt động thế nào và cần validate những gì?
JWT thường gồm base64url header, payload và signature; signature bảo vệ integrity/authenticity nhưng payload không được mã hóa mặc định. Resource server phải cố định thuật toán cho phép, xác minh signature bằng trusted key và kiểm tra iss, aud, exp, nbf cùng quyền/scope. Token ngắn hạn giảm cửa sổ rủi ro nhưng logout/revocation, key rotation, replay và token storage vẫn cần thiết; không đặt secret/PII trong payload.
32. HTTPS/TLS handshake diễn ra theo flow nào?
Sau DNS và TCP, client gửi ClientHello gồm TLS versions, cipher suites, random và key share/SNI; server chọn tham số, gửi certificate và key share. Client kiểm tra chain tin cậy, hostname, thời hạn/chính sách certificate; hai bên dẫn xuất session keys và xác nhận Finished, rồi HTTP được mã hóa và kiểm tra integrity. TLS 1.3 hỗ trợ resumption để giảm round trip; nếu terminate TLS tại proxy thì proxy-to-backend là một trust boundary khác cần được bảo vệ.
33. Khi nào chọn JWT thay opaque token?
JWT phù hợp khi nhiều resource servers cần validate local và chấp nhận authorization snapshot đến lúc token hết hạn. Opaque token + introspection dễ thu hồi/kiểm soát state tập trung nhưng thêm network dependency và latency. Chọn theo revocation requirement, audience boundaries, token size/privacy và operational model, không vì JWT luôn “stateless”.
34. Nên lưu access token ở đâu trong browser?
Không có lựa chọn miễn nhiễm mọi rủi ro. Token trong localStorage dễ bị XSS đọc; HttpOnly Secure SameSite cookie giảm token theft từ JavaScript nhưng cần CSRF defense và cookie scope đúng. Thường giữ access token ngắn hạn trong memory/BFF session, refresh token được bảo vệ chặt, CSP/XSS prevention và rotation/reuse detection.
35. Logout hoặc user bị khóa thì thu hồi JWT chưa hết hạn thế nào?
Dùng access token TTL ngắn, revoke/rotate refresh token và kiểm tra trạng thái tại refresh. Với sự kiện rủi ro cao có thể dùng deny-list theo jti, token version/user session version hoặc introspection, đổi lại thêm state/cache consistency. Key rotation thu hồi diện rộng nhưng blast radius lớn và không thay session-level revocation.
36. HTTPS bảo vệ và không bảo vệ những gì?
HTTPS cung cấp confidentiality, integrity và server authentication trên đường truyền nếu certificate validation đúng. Nó không bảo vệ dữ liệu trước malware/XSS ở client, sau khi decrypt tại server/proxy, khỏi authorization lỗi, log rò secret hoặc endpoint hợp lệ bị compromise. Vẫn cần application security, encryption/storage controls và trusted internal hops.
37. Client kiểm tra certificate thế nào để chống MITM?
Client xây chain đến trust anchor, kiểm tra chữ ký, hostname/SAN, validity, key usage/policy và trạng thái theo platform. Attacker có certificate hợp lệ do CA/trust store bị lạm dụng vẫn là rủi ro; pinning chỉ phù hợp một số controlled clients vì rotation/recovery khó. Không tắt hostname/certificate verification để chữa lỗi môi trường.
38. mTLS khác HTTPS một chiều ở đâu?
HTTPS thông thường xác thực server; mTLS yêu cầu client cũng gửi certificate để server xác thực workload/device. mTLS hữu ích service-to-service zero-trust nhưng cần issuance, rotation, revocation và identity mapping. Nó xác thực transport peer, không tự thay user authentication hay business authorization.
Markdown-derived OWASP follow-ups
39. Why is endpoint-level role checking insufficient to prevent BOLA?
A role can authorize the function while the requested object belongs to another tenant or user. Enforce ownership and tenant scope at the data/use-case boundary for every object.
40. How can a harmless-looking export endpoint create unrestricted resource consumption?
A broad export can scan large data, consume CPU/memory/storage and call paid providers. Bound rows, fields, concurrency, time and cost; use quotas and asynchronous jobs.
41. What is the difference between an authorization bug and abuse of a sensitive business flow?
An authorization bug grants access that policy forbids; sensitive-flow abuse uses valid access to automate scalping, spam or checkout. The latter needs velocity/risk controls and business-specific detection, not only role checks.
42. Why must a trusted partner response still be validated and time-bounded?
A partner can be compromised, return malformed or oversized data, or become slow. Treat the response as untrusted input: validate schema/size, sanitize by context, set deadlines and isolate failure.
43. How would you inventory and retire deprecated API versions safely?
Register hosts, routes, owners and versions; measure usage and sensitive clients, publish a deprecation window/migration guide, alert remaining callers, then disable and verify no traffic before removal.