In the context of web applications, "secrets" refer to sensitive data used to secure communication, authenticate users, or access restricted resources. These are critical pieces of information that must be protected to maintain the security and integrity of the application.

First and foremost, it's important to acknowledge that the secure storage of secrets in applications is still an unresolved challenge. Many developers find this aspect unclear or challenging. This article aims to spark discussion and present current methods, along with their advantages and disadvantages, in the context of web applications. It is not intended to provide a definitive solution to the problem but rather to stimulate curiosity and encourage thoughtful discussion.
Basic Principles Let's begin by outlining the basic principles for handling secrets in an application. While these may seem obvious, experience shows that many applications, as revealed during penetration testing, often violate these fundamental rules.

1. Avoid Including Secrets in Application Logs or External Services – Ensure that sensitive information, such as API keys, passwords, or tokens, is not logged in application logs or sent to external services required for the application's operation. Application logs are often monitored and may be accessible to multiple users or services, increasing the risk of unintended exposure. Properly sanitize logs and other outputs to prevent sensitive data leakage.

2. Do Not Share Secrets with Any User via the API – Under no circumstances should secrets, such as credentials or sensitive tokens, be shared or exposed to users through the API. This includes avoiding the exposure of secrets in API responses, query parameters, headers, or any other part of the request/response cycle. Secure APIs must protect all sensitive data and ensure that only authorized and authenticated users can access specific functionalities or data.

3. Use Unique Secrets for Each Service – Each service or component within an application ecosystem should have its own unique set of secrets, such as API keys or authentication tokens. Avoid reusing the same secrets across multiple services, as this can increase the risk of a security breach affecting multiple systems. By isolating secrets, you limit the potential impact of any single secret being compromised.

4. Limit Application Access to Necessary Credentials – An application should only have access to the credentials and secrets essential for its specific functions. Avoid providing unnecessary access to additional credentials or resources. This principle helps minimize the attack surface and reduces the risk of misuse or unauthorized access to sensitive information.

5. Adhere to the Principle of Least Privilege – Users, services, and applications should be granted the minimum level of access required to perform their respective tasks. Known as the principle of least privilege, this approach helps reduce the potential damage caused by compromised accounts or services. Implement fine–grained access controls and regularly review and adjust permissions to ensure they remain appropriate for current roles and responsibilities.
THE MOST POPULAR WAYS OF KEEPING SECRETS Environment Variables Environment variables are one of the most common ways to store secrets in web applications, particularly in cloud environments. They allow secrets to be separated from the source code by defining variables at the operating system level, which the application can access at runtime. In container environments, such as Docker, environment variables are especially popular and easy to manage. Docker containers are isolated environments that often run in different contexts (e.g., development, staging, production). Setting environment variables in Docker is a simple way to provide different configurations and secrets to containers without having to modify the container image.
Potential risk: 1. Local File Inclusion (LFI) Attacks – web applications, a Local File Inclusion vulnerability can allow an attacker to load and read files on the server, including files that may contain environment variable data. For example, accessing /proc/self/environ on Linux systems can reveal all environment variables of the active process.

2. Remote Code Execution (RCE) – If an application has a vulnerability that allows remote code execution, an attacker can exploit this to access environment variables. By executing malicious code that displays or transmits the values of these variables, sensitive information can be exposed. Advantages: • Ease of Implementation and Configuration: Setting environment variables is straightforward and doesn't require additional software or complicated processes.

• Security During Application Delivery: Environment variables can be defined and changed without modifying the application code or recompiling it, reducing the risk of accidentally revealing secrets during versioning.

• Versatility: They can be used across a variety of operating systems and runtime environments, including locally, on servers, and in cloud and container environments.

• Isolation of Environments: Each environment (e.g., development, staging, production) can have its own unique environment variables, facilitating easy management of different settings and secrets. Disadvantages: • Exposure by Debugging and Logging: During debugging or if logging is misconfigured, environment variables can be accidentally logged, revealing sensitive information.

• Visibility Across Processes: Environment variables may be accessible to all processes running in the same environment, creating the risk of unauthorized access.

• Permission Management: The lack of clear mechanisms for managing permissions to environment variables can lead to a situation where too many people or processes have access to sensitive data. Configuration Files Storing secrets in configuration files is a common approach in web applications, where sensitive data like API keys, database credentials, and other crucial information are placed in files that the application reads at runtime. These files can be written in various formats such as JSON, YAML, XML, or plain text, depending on the specific requirements and preferences of the application. This method is often used because it centralizes configuration management and simplifies deployment, especially when different environments require different settings.

This approach is quite similar to using environment variables, with both methods involving the separation of secrets from the application's source code. However, there are notable differences. Unlike `/proc/self/environ`, which is used to access environment variables in a system and often contains non–printable characters that can obscure the reading of secrets, configuration files are typically more human–readable. This readability can be both an advantage and a disadvantage; while it makes management easier, it also increases the risk of accidental exposure.

Even if configuration files are encrypted, vulnerabilities such as Local File Inclusion (LFI) or Remote Code Execution (RCE) can still compromise the security of the secrets stored within them. This is because the application code must contain the decryption key or algorithm needed to access the secrets, which can itself be a point of vulnerability. If an attacker gains access to the application code, they could potentially extract these keys or algorithms, rendering the encryption ineffective. Potential risk: 1. Unintended Exposure through Version Control – Configuration files containing secrets can inadvertently be included in version control systems like Git. Without proper .gitignore rules or other precautions, these files may be exposed to anyone with access to the repository, increasing the risk of unauthorized access.

2. Insufficient File Permissions – If configuration files are not secured with appropriate file permissions, unauthorized users or processes could gain access to the sensitive information they contain. This risk is particularly pronounced in shared server environments or when files are left unprotected.

3. Plaintext Storage – Storing secrets in plaintext within configuration files makes them easily accessible to anyone with access to these files. This is a significant risk if the files are exposed through any of the aforementioned vulnerabilities. Advantages: • Ease of Use: Configuration files are straightforward to set up and manage. They allow for organized, structured storage of configuration data, making it easy to locate and modify secrets.

• Centralized Configuration: This method provides a single location for managing application settings, simplifying the process of maintaining consistent configurations across different environments.

• Consistency Across Environments: Configuration files can be customized for different environments, facilitating the deployment of consistent settings and secrets in development, staging, and production. Disadvantages: • Risk of Accidental Exposure: Configuration files can be unintentionally exposed, especially if mishandled in version control systems or left unsecured on servers.

• Limited Security Controls: Unlike more specialized secret management systems, configuration files do not inherently support access controls or audit logging, making it challenging to monitor and restrict access.

• Difficulty in Secret Rotation: Manually updating secrets in configuration files can be error–prone and inefficient, particularly in large–scale deployments where multiple instances and environments need to be synchronized. EXTERNAL SECRET MANAGEMENT SERVICES (E.G., VAULT) External secret management services, such as HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and Google Cloud Secret Manager, provide a specialized solution for securely storing and managing sensitive information like API keys, credentials, certificates, and encryption keys. These services centralize secret management, offering a range of features to enhance security and streamline the handling of secrets across an organization.
These services work by storing secrets in a secure, centralized repository. They provide an API or command–line interface that applications and users can use to access these secrets, typically based on strict access control policies. This centralization helps prevent the scattering of secrets across various configuration files, environment variables, or code repositories, which can be hard to manage and secure.
External secret management services typically include features such as:

• Encryption: All secrets are encrypted at rest and in transit, ensuring that sensitive information is protected against unauthorized access.

• Audit Logging: Comprehensive logging capabilities allow organizations to track who accessed which secrets and when, providing valuable data for compliance and security audits.

• Automated Secret Rotation: Some services offer the ability to automatically rotate secrets, reducing the risk associated with long–lived credentials.

It is important to note that the credentials used to access the Vault or any external secret management service itself become a critical secret. This access data must be protected with the same level of security as other secrets managed by the service. However, unlike other secrets, these credentials cannot be stored within the Vault itself, as they are necessary to initiate access to the system. This introduces an additional layer of complexity in securely managing these access credentials.
In the event of vulnerabilities such as Local File Inclusion (LFI) or Remote Code Execution (RCE), especially when the Vault is accessible over the network to an attacker, there is a risk of complete system compromise. If an attacker gains access to the secret management system, they could potentially access all stored secrets, leading to a full compromise of the security infrastructure. This highlights the importance of robust security measures, such as network segmentation, strong authentication mechanisms, and regular security assessments, to protect these critical systems. Advantages: • Centralized Management and Control: By consolidating secret management into a single platform, organizations can enforce consistent security policies and streamline administrative tasks. This centralization simplifies the management of access controls, secret rotation, and audit logging.

• Enhanced Security Features: These services provide advanced security mechanisms, including encryption, access controls, and automated secret rotation, that can be difficult to implement and maintain in–house. This helps to protect sensitive data from unauthorized access and potential breaches.

• Audit and Monitoring: The built–in logging and audit trail capabilities enable organizations to monitor access to secrets, helping to detect and respond to suspicious activities. This is particularly useful for meeting regulatory compliance requirements.

• Scalability and Flexibility: External secret management services can scale to accommodate growing organizations and adapt to various deployment environments, including on–premises, cloud, and hybrid setups. Disadvantages: • Dependency on Third–Party Services: Relying on external providers for secret management introduces a dependency on their availability, security practices, and service continuity. Any disruption or change in service could impact access to critical secrets, potentially affecting business operations.

• Complexity and Cost: Implementing and maintaining these services can be complex and may require significant financial investment, especially for organizations with extensive secret management needs. Costs can include licensing fees, infrastructure costs, and the need for specialized personnel to manage the system.

• Management Overhead: Systems like HashiCorp Vault require ongoing management, including regular updates, monitoring, and configuration adjustments. This adds administrative overhead and necessitates skilled personnel to ensure the system is properly maintained and secure.

• Potential for Software Vulnerabilities: Like any software, secret management services can have vulnerabilities. If these systems are not regularly updated or properly configured, they could become a target for attackers. Vulnerabilities in the secret management software could be exploited to gain unauthorized access to the stored secrets.