Cloud services hosts should not be visible or hardcoded

Although not a literal secret, cloud hosts, host addresses, and service addresses that are specific to an organization should be kept confidential, stored safely and not hardcoded.

Even if a host is opaque, it still is a network surface of attack. For example, what can be seen as a secure host today, is a vulnerable host tomorrow, given that an exploit has been found (many times 0-day).

When a host is internal, within an organizational network, there still is risk. When known, once inside the network, a hacker is looking for elevation or side-stepping to new hosts, and this host would be a natural target.

Social engineering can be performed more effectively, if the hacker knows an internal detail about your organization, such as a host address.

Finally, what is held as private and secure today, can be exposed to the public with a simple configuration mistake in internal systems that are responsible of keeping systems within the organizational network (host can be added, removed and modified)


Cloud provider host addresses and services are hardcoded or exposed in configuration files, infrastructure code, or business services.



  1. Use a cloud-native secret store, such as AWS Secrets Manager
  2. Use a dedicated vault product, such as:
    1. CyberArk Vault
    2. Hashicorp Vault


  1. Prefer a 12-factor architecture
  2. Use secret-loading libraries like .env for your specific tech stack