Allowlist vs Blocklist

Also Known As

TL;DR

Explanation

A blocklist (blacklist) attempts to enumerate known bad inputs and reject them. It will always be incomplete — attackers find encodings, bypasses, and new attack vectors that were not anticipated. An allowlist (whitelist) defines exactly what is acceptable and rejects everything else. Allowlists are inherently more secure because you control the entire space of valid input. When validating file extensions, redirect targets, HTML tags, or system commands — always use an allowlist.

Diagram

flowchart TD
    INPUT[User Input] --> APPROACH{Validation approach}
    APPROACH -->|Blocklist| BLOCK_LIST[Check against known bad<br/>reject blacklisted values]
    APPROACH -->|Allowlist| ALLOW_LIST[Check against known good<br/>reject anything not in list]
    BLOCK_LIST --> BYPASS[Attacker finds bypass<br/>new attack vector not in list]
    ALLOW_LIST --> SAFE2[Only known safe values pass<br/>unknown input rejected by default]
    subgraph Examples
        BL_EX[Blocklist: remove script tags<br/>attacker uses SVG onload]
        AL_EX[Allowlist: only accept a b p tags<br/>anything else rejected]
    end
style BLOCK_LIST fill:#f85149,color:#fff
style ALLOW_LIST fill:#238636,color:#fff
style BYPASS fill:#f85149,color:#fff
style SAFE2 fill:#238636,color:#fff

Common Misconception

Why It Matters

Common Mistakes

• Using a blocklist for file upload validation — attackers find file types not on the list.
• Allowlists that are too broad — 'any image type' vs 'jpeg, png, gif specifically'.
• Not normalising input before allowlist checking — %2e%2e%2f passes a check for '../'.
• Blocklisting user-agent or IP ranges for security — too easy to spoof or rotate.

Avoid When

• Blocklist-only input validation for security-critical paths — attackers find bypasses; allowlists are safer.
• Allowlists so strict they break legitimate input — test with real-world edge cases before deploying.
• Maintaining a blocklist of known-bad values for SQL injection or XSS — use parameterised queries and output encoding instead.

When To Use

• Always prefer allowlists for security validation — define what is allowed, reject everything else.
• Blocklists for UX filtering like profanity or spam signals — correctness matters less than security here.
• Allowlists for file upload MIME types and extensions — never trust user-supplied content type alone.
• Allowlists for redirect URLs — open redirect vulnerabilities arise from blocklist-only approaches.

Code Examples

// Blocklist — attacker uploads .php7, .phtml, .phar:
$blocked = ['php', 'exe', 'sh'];
$ext = strtolower(pathinfo($filename, PATHINFO_EXTENSION));
if (in_array($ext, $blocked)) die('Blocked');

// Allowlist — only explicitly permitted:
$allowed = ['jpg', 'jpeg', 'png', 'gif'];
if (!in_array($ext, $allowed)) die('Not allowed');

// Allowlist — permit known-good; deny everything else (safer)
\$allowed = ['jpeg', 'png', 'webp', 'gif'];
\$ext     = strtolower(pathinfo(\$_FILES['img']['name'], PATHINFO_EXTENSION));
if (!in_array(\$ext, \$allowed, true)) abort(415);

// Blocklist — deny known-bad; allow everything else (fragile)
\$blocked = ['php', 'php3', 'php4', 'phtml', 'phar'];
// Attackers find new extensions you forgot to block (.php5, .shtml)

// Always prefer allowlists for:
// - File extensions, MIME types
// - Redirect URLs (domain allowlist)
// - HTML attributes (HTMLPurifier allowlist)
// - User roles, permissions

// Blocklists for:
// - WAF rule augmentation (block known attack patterns)
// - IP reputation (block known-bad IPs)
// — but never as the only defence

References

• ↗ https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html#allowlisting-vs-denylisting

Tags

Related Terms