Cybersecurity
Updated 26 days ago | GitHub

Prefer whitelisting over blacklisting

Terminology note: This page is filed under its original name (Prefer-whitelisting-over-blacklisting) for backwards-compatibility with existing wiki links. The text below uses allowlist and denylist, which NIST, the IETF, the UK NCSC, and major vendor style guides have adopted as the modern terms. The older words whitelist and blacklist are shown in parentheses on first mention so they remain searchable.

What are denylisting and allowlisting?

  • Denylist (formerly blacklist): a list of what or who is forbidden. Anything not on the list is allowed by default.
  • Allowlist (formerly whitelist): a list of what or who is permitted. Anything not on the list is denied by default.

Denylisting and allowlisting are opposites, but not exact opposites — and the choice between them is not just a matter of programming style. It has important security implications, because each one treats future, unknown cases differently.

Why the default matters

Example
Imagine a set of options: A, B, C, D, E, F. We want to allow A, B, and C, but disallow D, E, and F. There are two ways to do this:

  • Denylist items D, E, and F.

  • Allowlist items A, B, and C.

Both would have the same result today.

At a later date, unknown to us, a new item Z becomes a possible value, and Z is a dangerous security threat. The two policies diverge:

  • In the denylist version, Z is not on the deny list, so it would be allowed by default — a silent regression that exposes the new threat until someone notices and updates the list.
  • In the allowlist version, Z is not on the allow list, so it would be denied by default — failing closed.

Allowlisting — sometimes called “secure by default” or default-deny — is the more secure approach. Prefer it whenever you can enumerate the legitimate values; fall back to denylisting only when the set of known-good values is genuinely open-ended (e.g., free-form text fields where allowlisting is impractical).

Why the terminology changed

Industry and standards bodies have largely moved away from whitelist/blacklist because the metaphor is both potentially offensive and technically imprecise — allow and deny describe the action directly and remove ambiguity. The page title is preserved here only to avoid breaking existing inbound links; new pages and code should use the newer terms (or, better still, a specific verb naming the action, such as “approved publishers” or “blocked IPs”). See: