When it comes to python, and other programming languages, we see two common culprits for exposing secrets: secrets that are hardcoded directly within the python script and secrets hardcoded in configuration files. An example of hardcoding secrets directly into a python script is below. The problem is that anyone with access to the script has access to the secrets within it.

Because the secrets aren’t stored centrally it also increases the likelihood that they will become sprawled in multiple files and generally makes it hard to control their movement and who has access to them. Another common way to store secrets to avoid having them directly into the script is to store them in a configuration file and then importing them.



Handling secrets this way means that the config file becomes very sensitive and cannot be shared within a git repository or you risk exposing the secrets. Best Practices
Where appropriate, use environment variables to load secrets, this imports them into the localized memory at the operating system level so they do not become exposed to the public. Storing them in a .env file means they can be kept separate from the other relevant code you want to share.

Resources

• GitHubs Python .gitignore file template.
• Python dotenv is a great package for storing and managing secrets as environment variables in python.

With the addition of Node, javascript became both a frontend and backend language. While hardcoding secrets in source code can happen at both the front and backend of projects, with javascript we can also often see exposed secrets inside an embedded javascript script embedded within other extensions such as HTML. These segments don’t appear within our results as they would fall in the html extension.
Example of a inline javascript API key exposed in a .html file

In addition to being exposed within your git repository, it is important to remember that anything passed in plain text to the client or browser is visible to the public. So regardless if you are embedding the secret in a html file or hardcoding the secrets in a .js file and calling them, if not handled correctly they will be exposed to the client.
Turning away from frontend javascript we can look into Node.js. Just like what was discussed in python, there are two core culpurates for exposing these secrets. Hardcoding them directly into the application script and hardcoding them into configuration files.
Example node.js script with hardcoded API key


The best practice is to use environment variables that are operating system level variables whose value can be used by one or more applications. As the value remains in the system, there's no risk of exposing credentials through your code. The most popular package for storing environment variables is the javascript dotenv package. Again, make sure the .env file is included in the .gitignore file.
Resources
GitHub Node .gitignore templates
Javascript dotenv package for storing variables and environment variables

Strictly speaking, not a file extension, but still a dominant contributor to leaks so important to mention. Having just spoken about .env files as a best practice for storing secrets it may seem counterintuitive having these on the list, but the key distinction here is that .env should never enter a git repository. This is the first example of our forbidden files.

Using packages like py-dotenv allows you to store secrets as variables within a .env file and load them into local memory, they can then be used throughout the project. This does however mean that the .env file is extremely sensitive. Like all things, individual requirements of the project need to be considered when deciding how and where to store secrets. In any case your .env file should never appear in your .git repository and be tightly protected. Getting into the habit of making sure this is included in your .gitignore file even if there is no sensitivity is a good habit. You should also consider implementing protections on your git repository like adding a GitHub action to prevent .env files into your repo (see GitGuardians solution for this).

Example .env file

Many API and SaaS providers offer quick setup files to allow you to quickly download your credentials to plug into your application including Google and Salesforce to name a few. These often come in the form of a JSON file, common names for these downloadable files can include credentials.json or config.json. While these files should definitely not be included in a git repository, secrets should be centralized in a single location, such as an environment file, that is easier to track and protect. Often these files are imported into the project and then accidentally included into the git repository.

Another common contributor, which will be sounding very familiar now, is including secrets inside application configuration files. JSON is widely used and most languages have built in JSON libraries, this means developers will often be familiar with JSON regardless of the specific technology stack. JSON carries the same issues as all configuration files. Store secrets centrally and pass them to your application at the operating system level (such as using environment variables).

A very common cause of leaked secrets in .properties files is through native android development (java) and in java based spring applications. We will focus on these two areas.
Android: .properties files are used often with android development and tools like Android Studio make it very easy to store and visualize data inside .properties files, making it convenient for developers to store secrets within.
The best practices for hiding secrets in Android development is to use the android keystore system which uses “cryptographic keys in a container to make it more difficult to extract from the device”. But another common way to store secrets is to hide them in a BuildConfig object which uses the .properties extension. These keys can be then used anywhere within your source code with the BuildConfig object provided by Gradle. Not only do these files frequently get committed into a repository, these files can still be decoded via reverse engineering from a compiled APK. As a rule, any files containing secrets should be added to a .gitignore file but in this case, consider using androids built in keystore to store secrets more securely. (Read more here)

Spring: Spring applications also regularly use the .properties extension to store configuration settings which can include secrets, particularly when storing database properties. A common file to contain secrets often associated with Spring is the application.properties. This is a built-in mechanism for application configuration and is a basic key-value text file making it convenient to store secrets within. This is a poor practice to maintain and again, environment variables should be used and secrets saved in a .env that is added to the .gitignore file as a minimum. See external configuration for more information.
Example application.properties file with database credentials

.pem files can contain both private and public keys but in all cases, these are not appropriate files to store inside .git repositories.
.pem files should be included in your .gitignore file but you should also make sure that you are scanning your git repositories for such files so if any do get accidentally included you will be alerted.
Add rules to protect your repository now with GitGuardian.

Example of secrets hardcoded into .php script

Storing secrets in a .env file with PHP is a much better practice than hardcoding them into an application script. In addition to protecting the .env file in a git repository, you must also be careful that the .env file is not inside the root directory when it is being hosted. By default, anything that's inside of your document root is directly readable by the outside world. In this case, if the choice was made as to if the .env file was put inside of the document root. Someone could hit http://mycoolsite.com/.env and be able to access this file directly . If the root is /var/www/mycoolsite/public then you must move the file up one level at /var/www/mycoolsite/.env. This makes it so that PHP can still access the file but it can't be reached via the web.
Example of php file with secrets imported from environment variables


The other common file we see in PHP is a configuration file. Usually this is a database configuration and many different applications use this configuration file including wordpress (wp-config.PHP) and PHP-Nuke. If you are using a PHP configuration file make sure you still use environment variables stored in a .env file, do not hardcode the secrets directly into the configuration file and ensure the .env file is included in the .gitignore file.
Resources
Dotenv package for PHP applications
GitHub collection of .gitignore templates

A consistent contributor to secrets within xml files is again in android development. This is a file format regularly used to store data and can be easily edited from within Android Studio. The risk with XML files is much larger than just storing them in git. Keeping secrets inside strings.xml for example allows hackers to also extract them from a compiled APK (android application file).
The best practices for hiding secrets in Android development is to use the android keystore system which uses “cryptographic keys in a container to make it more difficult to extract from the device”. Don’t get tempted to store secrets inside .properties file. While this is more secure than storing it in XML files, your API key can still be decoded by someone via reverse engineering. Hence, this isn't a very secure way to store your secrets.

YAML can be used with nearly any application that needs to store or transmit data. Its flexibility is partially due to the fact that YAML is made up of bits and pieces of other languages. A few examples of these similarities include:

• Scalars, lists, and associative arrays are based on Perl.
• The document separator “---” is based on MIME.
• Escape sequences are based on C.
• Whitespace wrapping is based on HTML.

• if it does not contain sensitive information and should be available to forks – add it to your .travis.yml
• if it does contain sensitive information, and is the same for all branches – encrypt it and add it to your .travis.yml
• if it does contain sensitive information, and might be different for different branches – add it to your Repository Settings

TypeScript is compiled to JavaScript. Therefore, TS can be used anywhere JS could be used: both the frontend and the backend. Because TypeScript is a subset of javascript then it also is subject to many of the common situations the .js file extensions are affected from. One of the most popular frameworks based on typescript that contribute to data leaks is Angular which can be seen with the frequency environment.ts is a culprit for leaks. This is a default file created to store environment variables within an Angular application. It is common to see secrets included in the environment.ts file but this is a bad coding practice, just like within javascript all secrets should be stored in the .env file.