Allowlisting
A security approach where you explicitly list what is permitted and deny everything else, instead of trying to list everything that is forbidden.
Also known as: Allowlist, Denylist, Whitelisting, Allowlist vs. Denylist, Deny by Default, Allow List
Category: Software Development
Tags: security, cybersecurity, access-control, validation, defaults, principles, supply-chain
Explanation
There are two ways to control what gets through:
- **Allowlist**: You name what's allowed, and everything else gets rejected
- **Denylist**: You name what's forbidden, and everything else gets accepted
They sound symmetrical. They're not. A denylist only works if you can predict every bad thing in advance. Attackers spend their time finding exactly what you forgot: another encoding, a new file type, a command you didn't think of. An allowlist flips the burden. If you forget something, a legitimate use gets blocked, someone complains, and you add it. That failure is visible and cheap.
This is Saltzer and Schroeder's "fail-safe defaults" principle in practice: base decisions on permission, not exclusion.
**Where you'll find allowlists**:
- **Input validation**: The OWASP Input Validation Cheat Sheet recommends defining what the application accepts and rejecting everything outside those rules, instead of trying to recognize every malicious string
- **API payloads**: In NestJS, `whitelist: true` on the `ValidationPipe` strips any property that doesn't have a validation decorator, so you never receive unexpected fields. `forbidNonWhitelisted: true` throws an error instead. Stricter, but clearer for the client
- **Firewalls**: Deny all traffic by default, then open specific ports and sources
- **Software supply chain**: Allowlists of approved packages and tools protect against typosquatting and slopsquatting, where attackers publish malicious packages under names that look legitimate (or that an AI assistant might hallucinate)
- **AI agents**: Allowlists explicitly enumerate what an agent can do (which commands, which tools, which folders), instead of hoping to block every dangerous action
- **Web security**: Allowed CORS origins, allowed redirect URLs, Content Security Policy sources
- **Applications**: Endpoint protection that only runs approved executables
**The tradeoffs**:
- **Maintenance**: Someone has to keep the list up to date
- **Friction**: Legitimate new uses get blocked until they're added. Make adding entries easy, or people will look for workarounds
- **Denylists still have a role**: Blocking known-bad items (malware signatures, known malicious domains) is a useful extra layer, as long as it's not the only one (see defense in depth)
**A note on terminology**:
In 2020, the UK's National Cyber Security Centre switched to "allow list" and "deny list" instead of "whitelist" and "blacklist". The new terms say what they do, and many projects and vendors have followed. You'll still see the old terms in older tools (NestJS's `whitelist` option, for example).
Allowlisting is Secure by Default applied to access: the safe outcome is the default, and every exception is a deliberate, visible decision.
Related Concepts
← Back to all concepts