Security: Black Box vs. Blacklist vs. Whitelist

If you have ever touched anything related to security, it's likely you used some third-party tools, such as firewalls, XSS filters, access control modules, etc.

There are three basic modes in which you can work with those tools, such as Black Box, Blacklist and Whitelist. And often developers are given the right and responsibility to make decisions on choosing one of them.

Even though this information may sound obvious for some developers, others can make mistakes which can potentially cost their companies money and their leadership nerves, so it’s a good idea to review your understanding of these three security practices.

Black Box

Briefly, it’s when you trust your tool defaults preset for you by the tool developers.

Examples:

1) You don’t have robots.txt file in your site root, which should tell search robots, e.g. Googlebot, what to index and what not.
2) You enable a firewall without configuring it hoping that its defaults cover everything.
3) You don’t verify or sanitize API responses trusting the API provider just because it has a good reputation and everyone uses it.

When choosing the Black Box security strategy, ask yourself, what are the defaults? Are people who set them security experts? Can they make mistakes as any human being? Can the defaults change in time without notice?

All people make mistakes, so it's not bad to be a little bit sceptical and don’t trust anyone when you’re working with security of your system or application. Therefore, you should choose the Black Box approach at your peril.

Blacklist

The Blacklist strategy basically means “allow all, deny some”. Unlike the Black Box approach, Blacklist normally requires configuration, which is better but not ideal.

Examples:

1) The robots.txt file of Drupal CMS which only disallows indexing of specific paths.

...
User-agent: *
Crawl-delay: 10
Disallow: /includes/
Disallow: /misc/
Disallow: /modules/
...

2) A popular linux firewall, called UFW, can be configured to allow all incoming and outgoing connections by default and deny 8080 port connections only. Please note, this approach is not recommended but possible.

ufw default allow
ufw deny 8080

3) A firewall that blocks IP addresses accessing a site too often (e.g. DOS attack)

The main disadvantage of the Blacklist strategy is that your system is vulnerable to every new thread. That’s why antivirus software doesn't only count on a blacklist of known virus signatures and it also uses other methods to proactively protect you from previously undiscovered threads.

Speaking of our examples above, If you once forget to add a necessary entry to your blacklist, you risk to make your app or system vulnerable to unsolicited access.

Whitelist

The Whitelist strategy means “deny all, allow some”. Unlike the Blacklist approach, Whitelist assumes that everything is denied by default unless you explicitly allow something.

Examples:

1) UFW firewall which is configured to deny all connections by default and allow connections on port 22 (SSH) only.

ufw default deny
ufw allow 22

2) An HTML sanitizer removing all tags by default except the ones you explicitly specified in the sanitize function arguments.

const data = DOMPurify.sanitize('<b>Bold text</b>', {ALLOWED_TAGS: ['b']});

With the Whitelist strategy you’re safe by default, because it gives you full control and it’s you who explicitly defines what to allow.

Feel free to choose between Blacklist and Whitelist based on your specific conditions, but I would not recommend dealing with Black Box because of its unpredictability.


Working with React? Check out my post on React app security.


I hope you enjoyed the post and learned something new. On this blog, I share my development experience and insights, and if it resonates with you, I invite you to subscribe to my updates.