Teachers

Under construction

<aside> 🚧

This page is currently under construction. Please check back later.

</aside>

Introduction

In the last chapter, we learned to think like an attacker. Now, let's apply that mindset to one of the most critical responsibilities a backend developer has: protecting sensitive data.

When users trust our application with their information, we have a duty to keep it safe. A data breach can destroy user trust, ruin a company's reputation, and have severe real-world consequences for individuals. For an attacker, sensitive data is the ultimate prize. For a builder, protecting it is a non-negotiable requirement. This chapter will cover the "what," the "why," and the "how" of protecting two main types of sensitive data: user passwords and application secrets.

Storing Secrets and Keys

Applications need to talk to databases, external APIs, and other services. These connections are often secured with passwords, API keys, and secret tokens.

Can’t we just put the database password and my AWS API key in the application.properties file? It's easy, and all what the application needs it to run.

As most projects use Git for version control. If that application.properties file is accidentally committed and pushed to a public GitHub repository, everyone can find it. Automated bots are constantly scanning GitHub for exactly this mistake. Once I have your keys, I have access to your database and your cloud account."

Hard-coding Secrets is a Ticking Time Bomb

Hard-coding secrets in your source code or configuration files is one of the most common and dangerous security mistakes. It violates the principle of separating code from configuration. The core principle is to never commit secrets to version control. Secrets should be provided to the application from the outside environment.

Let’s see some more secure options to store Secrets and Keys.

Environment Variables

This is the most fundamental way to externalize secrets. Instead of writing the secret in a file, you store it in an environment variable on the server where the application runs.

In ****application.properties ****you reference the environment variable instead of the actual value.

# GOOD: Reference an environment variable
spring.datasource.password=${DB_PASSWORD}
api.weather-service.key=${WEATHER_API_KEY}

# BAD: Hard-coded secret! NEVER DO THIS!
# spring.datasource.password=MySuperSecretPassword123!

How to provide it:

For local development: You can set these variables in your IDE's run configuration or in a shell script.
In production (e.g., Docker/Cloud): You pass these variables into the container or application environment when you deploy it.

A Dedicated Secrets Manager(More secure)

For production systems, using a dedicated secrets management tool is the industry best practice.

What it is: A secure, centralized service designed to store, manage, and rotate secrets (like API keys and passwords).
Examples: AWS Secrets Manager, HashiCorp Vault, Google Secret Manager, Doppler.
How it works (simplified):
1. You store your DB_PASSWORD in the secrets manager, not in an environment variable.
2. Your application is given a specific, limited permission (an IAM role in AWS, for example) to read that secret.
3. When the application starts, it authenticates with the secrets manager using its role and fetches the secret securely.

This approach provides audit trails, automatic rotation, and a central place to manage all your secrets, which is far more secure than scattering environment variables across servers.

The HackYourFuture curriculum is licensed under CC BY-NC-SA 4.0 *https://hackyourfuture.net/*

CC BY-NC-SA 4.0 Icons

Built with ❤️ by the HackYourFuture community · Thank you, contributors

Found a mistake or have a suggestion? Let us know in the feedback form.

Week 10