Phần lớn sự cố production không đến từ lỗi hiếm gặp, mà từ những thứ không có điểm kết thúc, không có giới hạn và không có đường lui.Most production incidents do not come from rare bugs. They come from things with no end, no limit and no way back.

Nó là gìWhat it is. Component đăng ký listener lên một đối tượng sống lâu hơn nó — window, document, một store hay socket — nhưng không gỡ ra khi unmount. Listener là một closure, nên nó giữ lại component cùng mọi thứ component đang tham chiếu.A component registers a listener on something that lives longer than it does — window, document, a store, a socket — and never removes it on unmount. The listener is a closure, so it keeps the component and everything the component references.

// Leaks: nothing removes the listener
useEffect(() => {
  window.addEventListener('resize', onResize);
}, []);

// Fixed: one abort() removes every listener tied to the signal
useEffect(() => {
  const ctrl = new AbortController();
  window.addEventListener('resize', onResize, { signal: ctrl.signal });
  return () => ctrl.abort();
}, []);

Hoạt động thế nàoHow it works. GC chỉ thu hồi những gì không còn đường tham chiếu từ root, và window chính là một root. Chuỗi giữ chặt trông thế này: window → danh sách listener → closure → state, props, DOM của component đã unmount. Chừng nào listener còn đó, cả chuỗi còn sống.The GC only frees what is unreachable from a root, and window is a root. The retaining chain is: window → listener list → closure → state, props and DOM of the unmounted component. As long as the listener stays, so does the whole chain.

Mẹo triển khaiImplementation tips

• Ưu tiên option { signal } của AbortController: không phải giữ tham chiếu hàm, một lệnh abort() gỡ hết.
• Trong console của Chrome, getEventListeners(window) cho biết đang có bao nhiêu listener trên window.
• Test leak nhanh nhất: mở rồi đóng màn hình 20 lần, chụp heap, so với snapshot đầu tiên.
• Prefer the { signal } option: no function reference to keep, one abort() removes everything.
• In the Chrome console, getEventListeners(window) shows how many listeners window currently holds.
• Fastest leak test: open and close the screen 20 times, take a heap snapshot, compare with the first one.

Nó là gìWhat it is. Code đăng ký handler vào một EventEmitter, bus pub/sub hay observable dùng chung, nhưng không bao giờ huỷ. Khác với M1 ở chỗ nguồn phát nằm trong code của bạn chứ không phải DOM.Code subscribes a handler to a shared EventEmitter, pub/sub bus or observable and never unsubscribes. Unlike M1, the source is an object in your own code, not the DOM.

// Leaks: every request adds a listener to a process-wide bus
bus.on('config', (c) => apply(c, req));

// Fixed: remove it when the request ends
const handler = (c) => apply(c, req);
bus.on('config', handler);
res.on('close', () => bus.off('config', handler));

Hoạt động thế nàoHow it works. Emitter giữ một mảng handler cho mỗi tên sự kiện. Không ai gỡ thì mảng chỉ dài ra, và mỗi handler giữ closure của lần đăng ký — trong ví dụ trên là cả đối tượng request. Triệu chứng đi kèm: một sự kiện phát ra một lần nhưng handler chạy N lần.The emitter keeps an array of handlers per event name. If nobody removes them, the array only grows, and each handler holds the closure from its registration — in the example, the whole request. The side symptom: an event fires once, handlers run N times.

Mẹo triển khaiImplementation tips

• Đừng bao giờ gọi setMaxListeners(0) để dập cảnh báo; chạy node --trace-warnings để thấy stack của chỗ đăng ký.
• Đưa listenerCount lên metrics; đồ thị phải nằm phẳng.
• Với RxJS, gom mọi subscription qua takeUntil(destroy$) hoặc một Subscription cha.
• Never call setMaxListeners(0) to silence the warning; run node --trace-warnings to get the stack of the registering call.
• Export listenerCount to metrics; the line should be flat.
• In RxJS, route every subscription through takeUntil(destroy$) or a parent Subscription.

Nó là gìWhat it is. setInterval hoặc setTimeout tạo trong component hay module nhưng không có lệnh clear tương ứng. Timer đang hoạt động được runtime giữ như một root.A setInterval or setTimeout created in a component or module with no matching clear. An active timer is held by the runtime like a root.

useEffect(() => {
  const id = setInterval(poll, 5000);
  return () => clearInterval(id);
}, []);

Hoạt động thế nàoHow it works. Event loop giữ timer cho đến khi nó bị clear. Interval không tự dừng, nên callback cùng closure của nó sống mãi. Trong Node, timer đang chạy còn giữ process không thoát được, trừ khi bạn gọi unref().The event loop holds a timer until it is cleared. An interval never stops on its own, so its callback and closure live forever. In Node, an active timer also keeps the process from exiting unless you call unref().

Mẹo triển khaiImplementation tips

• Với polling, setTimeout đệ quy sau khi request xong tốt hơn setInterval: không chồng request khi mạng chậm.
• Tạm dừng polling khi tab bị ẩn (document.visibilityState === 'hidden').
• Trong Node, timer.unref() cho những timer không nên chặn việc tắt process.
• For polling, a recursive setTimeout scheduled after the request finishes beats setInterval: requests never pile up on a slow network.
• Pause polling while the tab is hidden (document.visibilityState === 'hidden').
• In Node, timer.unref() for timers that should not block shutdown.

Nó là gìWhat it is. Gọi mạng hoặc chạy tác vụ async mà không đặt timeout, và không huỷ khi người gọi không còn cần kết quả. Callback trong .then giữ closure, thường là state của component hoặc cả context của request.Network calls or async work with no timeout and no cancellation once the caller stops caring. The .then callback holds a closure, typically component state or a whole request context.

const ctrl = new AbortController();          // abort on unmount / client disconnect
const res = await fetch(url, {
  signal: AbortSignal.any([ctrl.signal, AbortSignal.timeout(5000)]),
});

Hoạt động thế nàoHow it works. Chừng nào socket còn mở chờ phản hồi, runtime còn giữ callback hoàn tất, và callback giữ closure. Upstream treo mà không có timeout thì hàng nghìn tác vụ treo cộng dồn. Một Map “pending requests” dùng để gộp request trùng mà quên xoá khi xong cũng là leak kiểu M2.While a socket waits for a response, the runtime keeps the completion callback, and the callback keeps its closure. A hung upstream with no timeout piles up thousands of pending operations. A “pending requests” Map used for deduplication that never deletes finished keys is an M2-style leak as well.

Mẹo triển khaiImplementation tips

• Mọi lời gọi mạng ra ngoài đều phải có timeout, không ngoại lệ.
• Đăng ký process.on('unhandledRejection') để log có ngữ cảnh thay vì crash câm.
• Map gộp request: luôn .finally(() => pending.delete(key)).
• Every outbound network call gets a timeout. No exceptions.
• Register process.on('unhandledRejection') to log with context instead of crashing silently.
• Dedupe maps: always .finally(() => pending.delete(key)).

Nó là gìWhat it is. Dùng Map hoặc object làm cache trong bộ nhớ mà không giới hạn kích thước và không có thời hạn. Mỗi key mới là một mục ở lại vĩnh viễn.A Map or plain object used as an in-memory cache with no size bound and no expiry. Every new key is an entry that stays forever.

// Leaks: one entry per distinct id, forever
const cache = new Map();

// Fixed: bounded and expiring (npm: lru-cache)
import { LRUCache } from 'lru-cache';
const cache = new LRUCache({ max: 5000, ttl: 60_000 });

Hoạt động thế nàoHow it works. Khi key không có tập giới hạn (userId, URL, query string), kích thước cache bằng số key khác nhau từng xuất hiện. Traffic thật có đuôi dài nên cache không bao giờ bão hoà. LRU loại mục ít dùng nhất khi đầy; TTL loại mục quá cũ.When keys come from an unbounded set (user IDs, URLs, query strings), cache size equals the number of distinct keys ever seen. Real traffic has a long tail, so the cache never saturates. LRU evicts the least recently used entry when full; TTL evicts stale ones.

Mẹo triển khaiImplementation tips

• Đo hit rate trước khi tăng max; dưới khoảng 50% nghĩa là key quá phân tán, nên hỏi lại có đáng cache không.
• Nhiều instance cần dùng chung thì chuyển sang Redis với maxmemory-policy allkeys-lru.
• Đừng lấy WeakMap làm cache: nó không có kích thước, không loại bỏ theo thời gian, và chỉ nhận object làm key.
• Measure hit rate before raising max; below roughly 50% means keys are too scattered to be worth caching.
• If instances must share, move to Redis with maxmemory-policy allkeys-lru.
• Do not use WeakMap as a cache: no size, no time-based eviction, object keys only.

Nó là gìWhat it is. Mảng hoặc collection ở cấp module chỉ được thêm vào: log buffer, lịch sử sự kiện, hàng đợi retry, danh sách gần đây.A module-level array or collection that only ever gets appended to: log buffers, event history, retry queues, “recent items” lists.

const MAX = 1000;
recent.push(item);
if (recent.length > MAX) recent.splice(0, recent.length - MAX);

Hoạt động thế nàoHow it works. Biến module sống suốt đời process. Tốc độ thêm lớn hơn tốc độ xoá, mà tốc độ xoá bằng 0, thì OOM chỉ là chuyện thời gian — thường vài ngày, đủ lâu để qua mọi bài test ngắn.Module variables live as long as the process. If entries arrive faster than they leave, and they never leave, OOM is a matter of time — usually days, long enough to pass every short test.

Mẹo triển khaiImplementation tips

• Trong code review, mọi collection toàn cục phải trả lời được: ai xoá, khi nào?
• Hàng đợi retry phải có số lần thử tối đa và dead-letter queue.
• Đưa length của các buffer lên metrics để thấy chúng trước khi OOM thấy.
• In code review, every global collection must answer: who removes entries, and when?
• Retry queues need a max attempt count and a dead-letter queue.
• Export buffer lengths as metrics so you see them before the OOM killer does.

Nó là gìWhat it is. Hai dạng khác nhau. Trong ngôn ngữ đếm tham chiếu: A giữ B, B giữ A, bộ đếm không bao giờ về 0. Trong JS: một Map toàn cục lấy DOM node hay object làm key để gắn dữ liệu, nên object không bao giờ được giải phóng.Two distinct forms. Under reference counting: A holds B, B holds A, and neither count reaches zero. In JS: a global Map keyed by DOM nodes or objects to attach data, so those objects are never freed.

// Leaks: the Map keeps every node alive
const meta = new Map();
meta.set(node, { clicks: 0 });

// Fixed: WeakMap does not keep its keys alive
const meta = new WeakMap();
meta.set(node, { clicks: 0 });

// ARC: break the cycle with a weak back-reference
class Child { weak var parent: Parent? }

Hoạt động thế nàoHow it works. WeakMap chỉ giữ giá trị chừng nào key còn được tham chiếu ở nơi khác; key biến mất thì cả cặp bị thu hồi. Trong ARC, weak và unowned không tăng bộ đếm, nên vòng bị phá.A WeakMap keeps a value only while its key is referenced elsewhere; once the key is gone, the pair is collected. Under ARC, weak and unowned do not bump the count, so the cycle breaks.

Mẹo triển khaiImplementation tips

• Đừng đi “phá vòng” bằng tay trong JS bằng cách gán null khắp nơi; GC đã lo việc đó, bạn chỉ làm code rối.
• Swift: [weak self] là mặc định an toàn cho mọi callback được lưu lại.
• Rust: parent giữ con bằng Rc, con trỏ ngược về parent bằng Weak.
• Do not “break cycles” by hand in JS with nulls everywhere; the GC already handles it and you only add noise.
• Swift: [weak self] is the safe default for any stored callback.
• Rust: parents own children with Rc, children point back with Weak.

Nó là gìWhat it is. Node đã bị gỡ khỏi document nhưng vẫn còn biến JS trỏ tới. Cây con của nó, kèm listener và dữ liệu gắn trên đó, ở lại trong heap.A node removed from the document that a JS variable still references. Its subtree, plus listeners and data attached to it, stays in the heap.

let rows = [...table.querySelectorAll('tr')];
table.remove();
rows = null; // or let `rows` go out of scope

Hoạt động thế nàoHow it works. Node con giữ parentNode, nên một tham chiếu tới bất kỳ node nào trong cây cũng giữ cả cây. Một biến trỏ vào một ô td có thể níu lại cả bảng 10.000 dòng.Child nodes hold parentNode, so a reference to any node in a tree retains the whole tree. One variable pointing at a single td can keep a 10,000-row table alive.

Mẹo triển khaiImplementation tips

• Gọi destroy() hoặc dispose() của thư viện bên thứ ba khi unmount; đây là nguồn leak DOM phổ biến nhất.
• Cần dùng lâu thì lưu ID hoặc selector, đừng lưu node.
• Buộc phải gắn dữ liệu vào node thì dùng WeakMap (xem M5).
• Call the third-party library's destroy() or dispose() on unmount; it is the most common source of DOM leaks.
• For long-lived lookups, store an ID or selector, not the node.
• If you must attach data to a node, use a WeakMap (see M5).

Nó là gìWhat it is. Một callback sống lâu (listener, timer, giá trị trong cache) vô tình giữ dữ liệu lớn vì được tạo trong cùng scope với đoạn code dùng dữ liệu đó.A long-lived callback (listener, timer, cached value) accidentally keeps large data because it was created in the same scope as code that uses that data.

// Leaks: the returned closure shares a context with `log`, which uses `big`
function setup() {
  const big = loadHugeArray();
  const log = () => console.log(big[0]);
  log();
  const n = big.length;
  return () => n;          // still retains `big`
}

// Fixed: do the heavy work in its own function, return only the small result
const count = () => loadHugeArray().length;
function setup() {
  const n = count();
  return () => n;
}

Hoạt động thế nàoHow it works. Mỗi scope có một context object, và mọi closure trong scope đều trỏ tới đúng context đó. Context chứa hợp của các biến được bất kỳ closure nào dùng. Closure nào sống lâu nhất sẽ quyết định context sống bao lâu.Each scope gets one context object, and every closure in that scope points to it. The context holds the union of variables used by any of those closures. The longest-lived closure decides how long the context lives.

Mẹo triển khaiImplementation tips

• Đưa phần xử lý dữ liệu lớn vào hàm riêng và chỉ trả ra kết quả nhỏ.
• Tránh eval và with; chúng buộc engine giữ toàn bộ scope.
• Trong snapshot, mở retainer đến (closure) rồi context để thấy chính xác biến nào đang bị giữ.
• Move heavy data processing into its own function and return only the small result.
• Avoid eval and with; they force the engine to keep the whole scope.
• In the snapshot, expand the retainer to (closure) then context to see exactly which variable is held.

Nó là gìWhat it is. Mở kết nối DB cho mỗi request, hoặc mượn kết nối từ pool, rồi có một nhánh code — thường là nhánh lỗi — không đóng hay trả lại.Opening a DB connection per request, or borrowing one from a pool, with some code path — usually the error path — that never closes or returns it.

const client = await pool.connect();
try {
  await client.query('BEGIN');
  // ...
  await client.query('COMMIT');
} catch (e) {
  await client.query('ROLLBACK');
  throw e;
} finally {
  client.release();
}

Hoạt động thế nàoHow it works. DB có giới hạn số kết nối (PostgreSQL mặc định max_connections = 100). Mở mới mỗi request tốn bắt tay TCP, TLS và xác thực, và nhanh chóng chạm trần. Pool giữ sẵn N kết nối; request mượn rồi trả. Mỗi kết nối không được trả làm pool nhỏ đi một, lặng lẽ, cho tới 0.Databases cap connections (PostgreSQL defaults to max_connections = 100). Opening one per request pays for TCP, TLS and auth handshakes and hits the cap quickly. A pool keeps N connections open; requests borrow and return. Every unreturned connection shrinks the pool by one, silently, down to zero.

Mẹo triển khaiImplementation tips

• Tính trước: pool_size × số instance phải nhỏ hơn max_connections, chừa chỗ cho admin và migration.
• Cảnh báo khi thời gian chờ lấy kết nối lớn hơn 0 kéo dài; đó là dấu hiệu sớm nhất.
• Câu lệnh đơn thì dùng pool.query(), nó tự trả kết nối; chỉ connect() thủ công khi cần transaction.
• Do the math: pool_size × instances must stay below max_connections, with headroom for admin and migrations.
• Alert when connection acquire wait stays above zero; it is the earliest signal.
• Use pool.query() for single statements since it releases for you; only connect() manually for transactions.

Nó là gìWhat it is. Lưu mật khẩu nguyên văn, mã hoá hai chiều, hoặc băm bằng hàm nhanh không salt.Storing passwords as-is, with reversible encryption, or with a fast unsalted hash.

import argon2 from 'argon2';
const hash = await argon2.hash(password);     // argon2id + random salt by default
const ok = await argon2.verify(hash, input);

Hoạt động thế nàoHow it works. Hàm băm mật khẩu cố tình chậm, có tham số chi phí về thời gian và bộ nhớ. Salt ngẫu nhiên cho từng user khiến bảng tra sẵn vô dụng, và hai người cùng mật khẩu vẫn có hash khác nhau. Argon2id đòi nhiều bộ nhớ nên GPU và ASIC khó chạy song song hàng loạt.Password hashes are deliberately slow, with time and memory cost parameters. A random per-user salt makes precomputed tables useless, and two users with the same password get different hashes. Argon2id is memory-hard, so GPUs and ASICs cannot parallelize it cheaply.

Mẹo triển khaiImplementation tips

• Tham số tối thiểu OWASP cho Argon2id: m = 19 MiB, t = 2, p = 1; bcrypt thì cost từ 10 trở lên.
• Hash cũ yếu: bọc nó trong Argon2id ngay (argon2(md5)), rồi băm lại bằng mật khẩu thật khi user đăng nhập.
• Không tự viết crypto; hàm verify của thư viện đã so sánh thời gian hằng.
• OWASP minimum for Argon2id: m = 19 MiB, t = 2, p = 1; for bcrypt, cost 10 or higher.
• For weak legacy hashes, wrap them in Argon2id now (argon2(md5)), then rehash with the real password at next login.
• Never roll your own crypto; library verify functions already compare in constant time.

Nó là gìWhat it is. Chấp nhận mật khẩu ngắn hoặc phổ biến; hoặc ngược lại, dựng quy tắc rắc rối khiến người dùng dồn vào vài mẫu quen thuộc.Accepting short or common passwords; or the opposite, piling on rules that funnel users into a handful of familiar patterns.

SHA1("password") = 5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8
GET https://api.pwnedpasswords.com/range/5BAA6
→ look for the remaining 35 characters in the response

Hoạt động thế nàoHow it works. Kẻ tấn công không đoán ngẫu nhiên. Họ thử danh sách mật khẩu đã lộ và biến thể của chúng. Chặn đúng những mật khẩu đó hiệu quả hơn mọi quy tắc thành phần, còn mỗi ký tự độ dài thêm vào nhân không gian tìm kiếm lên nhiều lần.Attackers do not guess randomly. They replay breached lists and their variants. Blocking exactly those passwords beats any composition rule, and every extra character of length multiplies the search space.

Mẹo triển khaiImplementation tips

• Dùng API k-anonymity của Have I Been Pwned: chỉ 5 ký tự đầu của SHA-1 rời khỏi server bạn.
• Hiển thị đồng hồ độ mạnh (zxcvbn) thay cho danh sách quy tắc.
• Cho phép dán mật khẩu để password manager hoạt động bình thường.
• Use Have I Been Pwned's k-anonymity API: only the first 5 SHA-1 characters leave your server.
• Show a strength meter (zxcvbn) instead of a list of rules.
• Allow pasting so password managers work.

Nó là gìWhat it is. Dùng chung JWT secret, API key, mật khẩu DB giữa dev, staging và production. Staging thường được bảo vệ lỏng hơn, nên nó thành cửa sau vào production.Sharing the JWT signing secret, API keys and DB passwords across dev, staging and production. Staging is usually guarded more loosely, so it becomes a back door into production.

Hoạt động thế nàoHow it works. Một secret chỉ an toàn bằng nơi yếu nhất đang giữ nó: laptop của dev, log CI, file .env trong repo staging. Tách secret theo môi trường khoanh vùng thiệt hại trong đúng một môi trường.A secret is only as safe as the weakest place holding it: a developer laptop, CI logs, a .env file in the staging repo. Separate secrets per environment confine the damage to one environment.

Mẹo triển khaiImplementation tips

• Chạy gitleaks hoặc trufflehog trong CI và quét cả lịch sử git; xoá commit là chưa đủ, secret đã lộ phải được xoay vòng.
• Đặt iss và aud khác nhau cho từng môi trường để JWT không dùng chéo được.
• Viết sẵn quy trình xoay vòng và diễn tập một lần trước khi thật sự cần.
• Run gitleaks or trufflehog in CI and over the full git history; deleting the commit is not enough, a leaked secret must be rotated.
• Use a different iss and aud per environment so JWTs cannot cross over.
• Write the rotation runbook and rehearse it once before you need it.

Nó là gìWhat it is. Endpoint đăng nhập, quên mật khẩu hay xác minh OTP cho phép thử bao nhiêu lần cũng được.Login, password reset or OTP verification endpoints that accept unlimited attempts.

Hoạt động thế nàoHow it works. Không có giới hạn thì brute-force và credential stuffing chỉ bị chặn bởi băng thông. Giới hạn nên theo nhiều chiều: theo tài khoản để chống dò một người, theo IP để chống một nguồn, và toàn cục để phát hiện chiến dịch phân tán.Without limits, brute force and credential stuffing are bounded only by bandwidth. Limit along several axes: per account against targeted guessing, per IP against a single source, and globally to spot distributed campaigns.

Mẹo triển khaiImplementation tips

• Dùng độ trễ tăng dần hoặc CAPTCHA thay cho khoá cứng tài khoản.
• Trả cùng thông báo và cùng thời gian phản hồi cho “sai email” và “sai mật khẩu” để không lộ tài khoản nào tồn tại.
• Lưu bộ đếm trong Redis để giới hạn vẫn đúng khi chạy nhiều instance.
• Use increasing delays or CAPTCHA instead of hard lockouts.
• Return the same message and the same response time for “wrong email” and “wrong password” so account existence does not leak.
• Keep counters in Redis so limits hold across instances.

Nó là gìWhat it is. Chỉ cần email và mật khẩu là vào được. Mật khẩu lộ qua phishing, qua rò rỉ ở dịch vụ khác hay qua malware đều đủ để chiếm tài khoản.Email and password are all it takes. A password leaked through phishing, another site's breach or malware is enough to take over the account.

Hoạt động thế nàoHow it works. MFA đòi thêm một yếu tố khác loại, thường là thứ bạn có: điện thoại, khoá bảo mật. Passkey dùng cặp khoá công khai gắn với origin; trang giả ở tên miền khác không thể lấy được chữ ký hợp lệ, kể cả khi người dùng bị lừa.MFA adds a factor of a different kind, usually something you have: a phone, a security key. Passkeys use a public-key pair bound to the origin; a fake site on another domain cannot obtain a valid signature even if the user is fooled.

Mẹo triển khaiImplementation tips

• Bắt buộc cho admin, khuyến khích cho người dùng thường.
• Mã khôi phục dùng một lần và lưu dạng hash như mật khẩu.
• Yêu cầu xác thực lại trước hành động nhạy cảm: đổi email, tắt MFA, rút tiền.
• Mandatory for admins, encouraged for everyone else.
• Recovery codes are single-use and stored hashed, like passwords.
• Require step-up re-authentication before sensitive actions: changing email, disabling MFA, withdrawals.

Nó là gìWhat it is. Access token (thường là JWT) có hạn vài tháng hoặc không có hạn. Ai lấy được token là có quyền cho tới khi nó hết hạn.Access tokens, usually JWTs, valid for months or with no expiry at all. Whoever gets one keeps access until it expires.

Hoạt động thế nàoHow it works. Access token ngắn hạn (5–15 phút) dùng cho mọi request. Refresh token dài hạn hơn, cất kỹ và chỉ gửi tới endpoint cấp token. Với rotation, mỗi lần refresh cấp một refresh token mới và vô hiệu cái cũ; nếu cái cũ bị dùng lại, đó là dấu hiệu bị đánh cắp và cả chuỗi token bị thu hồi.Short-lived access tokens (5–15 minutes) go with every request. A longer-lived refresh token is stored carefully and only sent to the token endpoint. With rotation, each refresh issues a new refresh token and invalidates the old one; if an old one is replayed, that signals theft and the whole token family is revoked.

Mẹo triển khaiImplementation tips

• Khi verify JWT, kiểm tra exp, iss, aud và cố định thuật toán được phép để chặn alg: none.
• Đặt refresh token trong cookie HttpOnly với Path giới hạn ở endpoint refresh.
• Web app thông thường: session cookie phía server thường đơn giản và an toàn hơn JWT.
• When verifying JWTs, check exp, iss and aud and pin the allowed algorithm to block alg: none.
• Put the refresh token in an HttpOnly cookie with Path scoped to the refresh endpoint.
• For a plain web app, server-side session cookies are usually simpler and safer than JWTs.

Nó là gìWhat it is. Lưu access token hoặc session token trong localStorage để JavaScript tự đọc và gắn vào header.Keeping the access or session token in localStorage so JavaScript can read it and attach it to headers.

Set-Cookie: __Host-session=abc123; Secure; HttpOnly; SameSite=Lax; Path=/

Hoạt động thế nàoHow it works. Mọi script chạy trên origin — kể cả script chèn qua XSS hay một package npm bị nhiễm — đều đọc được localStorage và gửi token về máy chủ kẻ tấn công. Cookie HttpOnly nằm ngoài tầm với của JS; trình duyệt tự gắn nó vào request. Tiền tố __Host- buộc cookie phải Secure, Path=/ và không có Domain, nên subdomain không ghi đè được.Any script on the origin — including one injected via XSS or a compromised npm package — can read localStorage and ship the token to an attacker. An HttpOnly cookie is out of JS's reach; the browser attaches it to requests itself. The __Host- prefix forces Secure, Path=/ and no Domain, so subdomains cannot overwrite it.

Mẹo triển khaiImplementation tips

• Thêm Content-Security-Policy; đó mới là lớp chặn XSS chính.
• SPA gọi API riêng: cân nhắc mô hình BFF (backend-for-frontend) để token nằm hẳn phía server.
• SameSite=Lax là mặc định hợp lý; Strict làm hỏng trải nghiệm khi người dùng đến từ link bên ngoài.
• Add a Content-Security-Policy; that is the primary XSS defense.
• For SPAs calling a separate API, consider a backend-for-frontend so tokens never reach the browser.
• SameSite=Lax is a sensible default; Strict breaks arrivals from external links.

Nó là gìWhat it is. Không có cách chấm dứt một phiên đang hoạt động. Người dùng mất máy, đổi mật khẩu, bị khoá tài khoản, nhưng phiên cũ vẫn chạy bình thường.No way to end an active session. The user loses a device, changes their password or gets suspended, and the old session keeps working.

Hoạt động thế nàoHow it works. Với session phía server, xoá bản ghi là thu hồi ngay. Với JWT stateless, cần một trong ba: hạn ngắn kết hợp thu hồi refresh token; denylist theo jti; hoặc một token_version trên user, tăng lên khi cần đăng xuất khỏi mọi nơi.With server-side sessions, deleting the record revokes instantly. With stateless JWTs you need one of three: short expiry plus refresh-token revocation; a denylist keyed by jti; or a token_version on the user that you bump to sign out everywhere.

Mẹo triển khaiImplementation tips

• Đổi mật khẩu thì thu hồi mọi phiên khác, chỉ giữ phiên hiện tại.
• Cho người dùng xem danh sách phiên: thiết bị, vị trí gần đúng, lần hoạt động cuối.
• Denylist chỉ cần giữ tới lúc token hết hạn, nên đặt TTL bằng exp.
• On password change, revoke every other session and keep only the current one.
• Show users their sessions: device, approximate location, last active.
• A denylist entry only needs to live until the token expires, so set its TTL to exp.

Nó là gìWhat it is. Ẩn nút, chặn route, kiểm tra quyền hay validate dữ liệu chỉ ở frontend, trong khi API phía sau tin mọi request.Hiding buttons, guarding routes, checking permissions or validating data only in the frontend, while the API behind it trusts every request.

-- Filter by owner inside the query, not after fetching
SELECT * FROM orders WHERE id = $1 AND owner_id = $2;

Hoạt động thế nàoHow it works. Client nằm trong tay người dùng: DevTools, curl, Postman gọi thẳng vào API. Mọi quyết định về quyền phải diễn ra ở server, trên từng request, dựa trên danh tính đã xác thực, chứ không dựa trên tham số client gửi lên như role=admin hay userId của người khác.The client belongs to the user: DevTools, curl and Postman call the API directly. Every authorization decision must happen on the server, per request, based on the authenticated identity — never on client-supplied parameters like role=admin or someone else's userId.

Mẹo triển khaiImplementation tips

• Lọc theo chủ sở hữu ngay trong truy vấn thay vì lấy ra rồi mới kiểm.
• Mặc định từ chối: endpoint mới phải khai báo quyền thì mới chạy được.
• Viết test gọi API bằng user A trên tài nguyên của user B.
• Filter by owner inside the query instead of fetching first and checking later.
• Deny by default: new endpoints must declare their permission to run at all.
• Write tests that call the API as user A against user B's resources.

Nó là gìWhat it is. Không ghi lại ai đăng nhập, khi nào, từ đâu, thành công hay thất bại, cũng như các hành động nhạy cảm sau đó.Not recording who signed in, when, from where, whether it succeeded, or which sensitive actions followed.

{"ts":"2026-09-29T08:12:03Z","event":"login.failed","user":"u_812",
 "ip":"203.0.113.7","ua":"Mozilla/5.0 …","reason":"bad_password"}

Hoạt động thế nàoHow it works. Log bảo mật là sự kiện có cấu trúc: thời điểm, user, IP, user agent, loại sự kiện, kết quả. Ghi vào nơi mà chính ứng dụng không sửa hay xoá được, và giữ đủ lâu để điều tra.Security logs are structured events: timestamp, user, IP, user agent, event type, outcome. Write them somewhere the application itself cannot edit or delete, and keep them long enough to investigate.

Mẹo triển khaiImplementation tips

• Không bao giờ ghi mật khẩu, token hay mã OTP, kể cả trong log lỗi.
• Gửi email “đăng nhập từ thiết bị mới” cho người dùng; họ là hệ thống phát hiện rẻ nhất bạn có.
• Đặt cảnh báo cho vài mẫu cụ thể thay vì dựng dashboard không ai xem.
• Never log passwords, tokens or OTP codes, not even in error logs.
• Email users on “sign-in from a new device”; they are the cheapest detection system you have.
• Alert on a few specific patterns instead of building a dashboard nobody opens.

Nó là gìWhat it is. Deploy bằng cách SSH vào server, git pull, cài dependency rồi restart, theo trí nhớ hoặc theo một file ghi chú.Deploying by SSHing into servers, running git pull, installing dependencies and restarting, from memory or a notes file.

commit → build artifact (once) → test → staging → production
                 └─ same image, same checksum at every stage

Hoạt động thế nàoHow it works. Pipeline CI/CD biến các bước thành code: build một artifact bất biến (container image, bundle) đúng một lần, chạy test, rồi đẩy chính artifact đó qua từng môi trường. Mọi lần deploy giống hệt nhau và đều để lại lịch sử.A CI/CD pipeline turns the steps into code: build one immutable artifact (container image, bundle) exactly once, run tests, then promote that same artifact through each environment. Every deploy is identical and leaves a history.

Mẹo triển khaiImplementation tips

• Build một lần, promote cùng một artifact; không build lại riêng cho production.
• Giữ pipeline dưới khoảng 10–15 phút, nếu không hotfix sẽ quay về đường SSH.
• Dùng OIDC từ CI tới cloud thay cho access key dài hạn lưu trong CI.
• Build once, promote the same artifact; never rebuild for production.
• Keep the pipeline under roughly 10–15 minutes or hotfixes drift back to SSH.
• Use OIDC from CI to your cloud instead of long-lived access keys stored in CI.

Nó là gìWhat it is. URL, credential, feature flag, giới hạn… viết thẳng trong mã nguồn. Đổi một con số phải sửa code, build và deploy lại.URLs, credentials, feature flags and limits written straight into source. Changing one number means editing code, building and redeploying.

import { z } from 'zod';
export const env = z.object({
  DATABASE_URL: z.string().url(),
  POOL_SIZE: z.coerce.number().int().positive().default(10),
}).parse(process.env);        // crash at boot, not at 3 a.m.

Hoạt động thế nàoHow it works. Theo 12-Factor, config là những gì thay đổi giữa các môi trường; nó phải tách khỏi code và được đọc từ môi trường lúc khởi động. Cùng một artifact chạy ở staging và production, chỉ khác config. Secret đi qua secret manager, không nằm trong repo.Per 12-Factor, config is whatever varies between environments; it lives outside the code and is read from the environment at startup. The same artifact runs in staging and production with different config. Secrets come from a secret manager, never the repo.

Mẹo triển khaiImplementation tips

• Validate toàn bộ config khi khởi động và dừng ngay nếu thiếu; lỗi sớm rẻ hơn lỗi lúc 3 giờ sáng.
• Frontend: biến build-time như VITE_* hay NEXT_PUBLIC_* bị nhúng thẳng vào bundle, không bao giờ để secret ở đó.
• Tách config (URL, con số) khỏi secret (credential); chúng có vòng đời khác nhau.
• Validate all config at startup and exit immediately if something is missing; early failure is cheaper than a 3 a.m. one.
• Frontend build-time vars like VITE_* or NEXT_PUBLIC_* are baked into the bundle; never put secrets there.
• Keep config (URLs, numbers) apart from secrets (credentials); they have different lifecycles.

Nó là gìWhat it is. Đổi schema và code trong cùng một bước. Trong lúc deploy luôn có một khoảng thời gian code cũ và code mới cùng chạy, và một bên sẽ gặp schema không hợp.Changing schema and code in one step. During any deploy there is a window where old and new code run side by side, and one of them meets a schema it does not understand.

Release 1           Release 2              Release 3
ADD new_col   →     code uses new_col  →   DROP old_col
(old code OK)       backfill in batches    (nobody reads it)

Hoạt động thế nàoHow it works. Mẫu expand/contract: (1) expand — thêm cột hoặc bảng mới, không xoá gì; (2) deploy code ghi cả hai, đọc cái mới; (3) backfill dữ liệu theo lô; (4) deploy code chỉ dùng cái mới; (5) contract — xoá cái cũ ở một release sau.The expand/contract pattern: (1) expand — add the new column or table, remove nothing; (2) deploy code that writes both and reads the new one; (3) backfill in batches; (4) deploy code that uses only the new one; (5) contract — drop the old one in a later release.

Mẹo triển khaiImplementation tips

• PostgreSQL: dùng CREATE INDEX CONCURRENTLY, và kiểm tra lệnh nào sẽ khoá bảng trước khi chạy.
• Đặt lock_timeout cho migration để nó bỏ cuộc thay vì treo cả hệ thống khi chờ khoá.
• Không bao giờ rename cột trực tiếp: thêm mới, chép dữ liệu, rồi mới xoá cũ.
• PostgreSQL: use CREATE INDEX CONCURRENTLY, and check which statements take heavy locks before running them.
• Set lock_timeout on migrations so they give up instead of stalling everything while waiting for a lock.
• Never rename a column in place: add, copy, then drop.

Nó là gìWhat it is. Đưa phiên bản mới tới toàn bộ người dùng cùng một lúc. Có lỗi thì tất cả cùng gặp.Shipping the new version to every user at once. If it is broken, everyone is affected.

1% ──5 min──▶ 5% ──15 min──▶ 25% ──▶ 100%
 │ error rate or p99 worse than baseline?
 └────────────▶ automatic rollback

Hoạt động thế nàoHow it works. Canary chuyển một phần nhỏ traffic (1%, 5%, 25%…) sang bản mới, so sánh chỉ số như tỉ lệ lỗi và độ trễ với bản cũ, tăng dần nếu ổn và tự lùi nếu xấu. Vùng ảnh hưởng tỉ lệ với phần trăm traffic.A canary sends a small slice of traffic (1%, 5%, 25%…) to the new version, compares metrics such as error rate and latency against the old one, ramps up if healthy and rolls back if not. The blast radius scales with the traffic percentage.

Mẹo triển khaiImplementation tips

• Canary không có so sánh chỉ số tự động là vô nghĩa; viết tiêu chí dừng trước khi bắt đầu.
• Gắn người dùng vào một phiên bản (sticky) để trải nghiệm nhất quán.
• Feature flag là canary ở tầng tính năng, rẻ hơn nhiều so với canary hạ tầng.
• A canary without automated metric comparison is theater; write the stop criteria before you start.
• Pin users to one version (sticky) so their experience is consistent.
• Feature flags are canaries at the feature level and far cheaper than infrastructure canaries.

Nó là gìWhat it is. Dừng bản cũ, deploy, rồi khởi động bản mới. Trong khoảng đó người dùng nhận lỗi.Stopping the old version, deploying, then starting the new one. Users get errors in between.

Hoạt động thế nàoHow it works. Blue/green dựng đầy đủ môi trường mới (green) bên cạnh môi trường đang chạy (blue), kiểm tra green, chuyển load balancer sang green, và giữ blue lại để lùi tức thì. Rolling update thì thay từng instance một, chỉ tiến khi instance mới báo sẵn sàng (D5).Blue/green builds a full new environment (green) next to the live one (blue), checks green, switches the load balancer to it, and keeps blue around for instant rollback. A rolling update replaces instances one by one and only advances when each new instance reports ready (D5).

Mẹo triển khaiImplementation tips

• Trên Kubernetes, rolling update với readiness probe và maxUnavailable: 0 thường là đủ.
• Xử lý SIGTERM đúng cách: ngừng nhận request mới, hoàn tất request đang chạy rồi mới thoát.
• Giữ môi trường cũ đủ lâu để bắt được cả những lỗi lộ ra chậm.
• On Kubernetes, a rolling update with a readiness probe and maxUnavailable: 0 is usually enough.
• Handle SIGTERM properly: stop accepting new requests, finish in-flight ones, then exit.
• Keep the old environment long enough to catch slow-burning bugs.

Nó là gìWhat it is. Gửi traffic vào instance ngay khi process khởi động, dù app chưa kết nối xong DB, chưa nạp cache, chưa thật sự sẵn sàng.Routing traffic to an instance as soon as the process starts, before it has connected to the database, warmed caches or become ready.

readinessProbe:            # ready for traffic? may check dependencies
  httpGet: { path: /ready, port: 8080 }
livenessProbe:             # process stuck? never check the DB here
  httpGet: { path: /live, port: 8080 }
startupProbe:              # slow boot: holds the other probes back
  httpGet: { path: /live, port: 8080 }
  failureThreshold: 30
  periodSeconds: 2

Hoạt động thế nàoHow it works. Kubernetes có ba loại probe. Startup: đã khởi động xong chưa. Readiness: nhận traffic được chưa; fail thì bị rút khỏi load balancer. Liveness: có bị treo không; fail thì bị restart. Chỉ readiness nên nhìn tới phụ thuộc bên ngoài.Kubernetes has three probes. Startup: has it finished booting? Readiness: can it take traffic? Failing removes it from the load balancer. Liveness: is it stuck? Failing restarts it. Only readiness should look at external dependencies.

Mẹo triển khaiImplementation tips

• Liveness không bao giờ kiểm tra DB hay dịch vụ ngoài; DB chậm sẽ khiến Kubernetes restart cả đội pod.
• Endpoint health phải rẻ, không chạy truy vấn nặng.
• App khởi động chậm thì dùng startupProbe thay vì tăng initialDelaySeconds.
• Liveness must never check the DB or external services; a slow DB would make Kubernetes restart your whole fleet.
• Health endpoints must be cheap, with no heavy queries.
• For slow starters, use a startupProbe instead of inflating initialDelaySeconds.

Nó là gìWhat it is. Deploy xong là coi như xong, không kiểm tra bản vừa lên có chạy trên môi trường thật hay không.Treating “deployed” as “done” without checking the new version actually works in the real environment.

Hoạt động thế nàoHow it works. Smoke test là vài kiểm tra nhanh, chạy tự động ngay sau deploy trên production: trang chủ trả 200, đăng nhập được, luồng chính như tìm kiếm hay thanh toán thử vẫn chạy. Fail thì dừng rollout hoặc tự rollback.A smoke test is a handful of fast checks run automatically right after a production deploy: the homepage returns 200, login works, the main flows such as search or a test checkout still run. On failure, halt the rollout or roll back.

Mẹo triển khaiImplementation tips

• Giữ dưới 10 kiểm tra và dưới một phút.
• Dùng tài khoản test riêng, gắn cờ để loại khỏi số liệu analytics.
• Chạy lại chính bộ kiểm tra đó theo lịch để có synthetic monitoring miễn phí.
• Keep it under 10 checks and under a minute.
• Use dedicated test accounts, flagged so analytics ignores them.
• Rerun the same checks on a schedule to get synthetic monitoring for free.

Nó là gìWhat it is. Deploy thất bại, hoặc bản mới làm tăng lỗi, mà không ai được báo. Sự cố được phát hiện sau nhiều giờ, qua khiếu nại.A deploy fails, or the new version raises errors, and nobody is told. The incident surfaces hours later through complaints.

Hoạt động thế nàoHow it works. Pipeline gửi trạng thái (bắt đầu, thành công, thất bại, rollback) vào kênh của team, kèm commit và người deploy. Hệ thống giám sát đánh dấu thời điểm deploy trên dashboard và cảnh báo khi chỉ số lệch khỏi mức nền.The pipeline posts status (started, succeeded, failed, rolled back) to the team channel with the commit and the deployer. Monitoring marks each deploy on dashboards and alerts when metrics leave their baseline.

Mẹo triển khaiImplementation tips

• Tách kênh thông báo deploy khỏi kênh cảnh báo cần hành động.
• Mỗi cảnh báo phải có người trực và một runbook ngắn.
• Đẩy annotation deploy lên Grafana hoặc Datadog từ chính pipeline.
• Keep the deploy-notice channel separate from the actionable-alert channel.
• Every alert needs an on-call owner and a short runbook.
• Push deploy annotations to Grafana or Datadog from the pipeline itself.

Nó là gìWhat it is. Không có cách quay lại bản trước một cách nhanh chóng. Khi có lỗi, lựa chọn duy nhất là viết bản vá trong lúc hệ thống đang cháy.No fast way back to the previous version. When something breaks, the only option is writing a patch while the system is on fire.

kubectl rollout undo deployment/api      # back to the previous ReplicaSet
kubectl rollout status deployment/api

Hoạt động thế nàoHow it works. Nếu artifact bất biến và được lưu lại (D4), rollback chỉ là deploy lại artifact trước, mất vài phút, không cần build. Điều kiện đi kèm: schema DB và config phải tương thích với bản cũ (D7, D6).If artifacts are immutable and kept (D4), rollback is just redeploying the previous one, in minutes, with no build. The conditions: the database schema and config must still be compatible with the old version (D7, D6).

Mẹo triển khaiImplementation tips

• Diễn tập rollback trên production ít nhất mỗi quý một lần; rollback chưa từng chạy coi như không có.
• Rollback trước, điều tra sau.
• Feature flag cho phép tắt một tính năng mà không phải deploy gì cả.
• Rehearse rollback in production at least once a quarter; a rollback never exercised does not exist.
• Roll back first, investigate second.
• Feature flags let you switch a feature off without deploying anything.

Nó là gìWhat it is. Release một thay đổi có rủi ro ngay trước khi cả team rời đi.Shipping a risky change right before the whole team leaves.

Hoạt động thế nàoHow it works. Lỗi thường lộ ra sau vài giờ: lúc traffic lên đỉnh, lúc job đêm chạy, lúc cache hết hạn. Nếu khi đó không ai trực, hoặc người trực không biết có thay đổi, thời gian phát hiện và khôi phục kéo dài ra nhiều lần.Bugs often surface hours later: at traffic peak, when nightly jobs run, when caches expire. If nobody is on call then, or the on-call person does not know about the change, detection and recovery stretch out many times over.

Mẹo triển khaiImplementation tips

• Thay luật “cấm thứ Sáu” bằng “không deploy nếu không ở lại được 1–2 giờ sau đó”.
• Đóng băng thay đổi trước sự kiện lớn, với ngày bắt đầu và kết thúc cụ thể.
• Theo dõi change failure rate của DORA; khi nó thấp và ổn định, đó là lý do để nới quy định.
• Replace “no Fridays” with “no deploy unless you can stay 1–2 hours afterwards”.
• Freeze changes before major events, with explicit start and end dates.
• Track DORA's change failure rate; when it is low and stable, that is your case for relaxing the rule.