Principle of Least Visibility

The first phase of a cyberattack is gathering information about the organization and the technical architecture of your product. A good tactic is to reduce the information available, so that potential attackers are slowed down and give up or generate enough suspect activity to be blocked.

Here are a few examples of information you can reduce or obfuscate:

• web server version and type
• database engine version
• the version of any library used on the server side

We can expand this idea to other types of obfuscation of information. For example:

• user ids: if they are incremental it’s easier for an attacker to guess existing user ids
• URLs: an attacker might try to guess URLs and attempt to send different payloads to check different responses. For most cases it’s difficult to hide URLs, particularly if you expose an API. It’s simpler to ensure that only the necessary URLs are visible, that they put limits to repeated calls, and that the inputs are filtered by a WAF and then sanitized. However, you might consider it for URLs that are meant to be outside the API
• HTTP responses: for example if the application responds differently to existing users that you don’t have access to versus non-existent users, then the user ids for existing users can be identified and used in other attacks
• Information shared on error: information in error responses is as valuable as that on the happy path. If for example you include the full exception string in the response, this will provide a lot of information to an attacker. Also, differences in error responses might give more information than you’d like