What you'll learn

Last lesson you learned how to think about threats. This lesson is where you start taking action.

A lot of production apps don't get hacked because of bad code. They get hacked because someone hijacks the domain, leaks an API key, or has weak 2FA on an important account.

---

Part 1: DNS and Domain Security

What is DNS, in plain English

When someone types yourapp.com into their browser, how does the browser know where your app actually lives? It uses something called DNS.

DNS works like a phone book for the internet. Your domain name (yourapp.com) is the contact name. The address of your actual server is the phone number. DNS looks up the name and returns the number, so the browser knows where to go.

You set this up through a domain registrar. That's the company you bought your domain from (GoDaddy, Namecheap, Cloudflare, etc.). The registrar holds the master controls for your domain.

Here's the problem: if an attacker takes over your registrar account, they can change where your domain points. Your users still type yourapp.com, but now the browser sends them to the attacker's server instead of yours. The fake site can look identical to your real one. Users have no way to tell.

This is called DNS hijacking, and it's one of the most damaging attacks possible. The attacker doesn't need to break into your code or your servers. They just need to take over one account: your registrar.

Real attacks

In 2013, attackers phished a single reseller account at Melbourne IT and used it to repoint the domains for the New York Times, Twitter, and Huffington Post UK. The Times site was unreachable for hours, and since whoever controls DNS also controls where email routes, the paper told staff to stop sending anything sensitive.

The New York Times was not hacked. Its registrar was.

How to lock down your domain

Not all registrars offer the same level of protection. Registrar accounts have been compromised through phished customer support and social engineering of employees. When choosing where to hold a domain with real users, look for a registrar that offers registry lock, hardware MFA support, and strong internal access controls.

Examples of registrars with these features: Cloudflare Registrar, MarkMonitor, and AWS Route53.

Turn on registrar lock. This stops another registrar from starting a transfer of your domain without your say-so. It's usually a toggle in your registrar's dashboard, and it's often on by default. Check it the day you buy the domain.

Large companies use a stronger version, where any change to the domain requires a phone call and manual approval before it goes through. Cloudflare sells this as Custom Domain Protection on enterprise plans.

Require hardware MFA on the registrar account. We'll cover hardware MFA in Part 3. The short version: a physical key is much harder to phish than an SMS code or an authenticator app.

Set up DNS monitoring. Cantina offers free DNS monitoring at cantina.xyz/solutions/dns-monitoring. It alerts you the moment your DNS records change. If an attacker ever does get in, you'll know in minutes instead of hours.

---

Part 2: Secrets Management for Real Apps

What is a secret

A secret is anything that, if someone else got hold of it, would let them do things they shouldn't be able to do.

Examples:

• Your database password (lets someone read or delete all your data)
• An API key for a service like Stripe or OpenAI (lets someone spend your money)
• A private key for a crypto wallet (lets someone steal funds)
• A login token for your email (lets someone reset your other accounts)

If it grants access, it's a secret. And the most common way secrets get leaked is the dumbest one: developers paste them into the wrong place and forget about it.

What not to do

Do not put secrets in your code. Ever. Not even as a placeholder you'll remember to remove.

Do not put real secrets in .env files committed to a repo. Even if you have .env in your .gitignore, you might have committed it before adding the rule. GitHub has an entire history. Tools like truffleHog scan public repos for leaked secrets and find thousands per day.

Do not share secrets in Slack, Discord, email, or text messages. These all log message history somewhere you don't control. If your Slack workspace gets compromised six months from now, every secret ever shared in DMs is exposed.

Do not reuse secrets across services. If your database password is also your AWS root password, one breach is all of them.

What to do instead

Use a dedicated secrets manager. Popular options include:

• 1Password for personal and team passwords. Has shared vaults for team secrets.
• AWS Secrets Manager if you're already on AWS. Plugs directly into your code.
• HashiCorp Vault for larger setups. More setup work, but very powerful.
• Doppler if you're switching from .env files and want the easiest migration.

These tools encrypt your secrets, log who accessed what, and let you change a secret without breaking everything else.

Make secrets sufficiently complex. A 12-character random string. Not your dog's name. Most password managers will generate strong ones for you.

Check your existing accounts at haveibeenpwned.com. This site tracks billions of leaked credentials from breaches. If your email shows up, every password you used at the time is considered compromised. Change them immediately and never reuse.

A practical workflow

1. Sign up for 1Password (or your preferred manager) for your team
2. Create a shared vault for production secrets
3. When you need a new secret, generate it in 1Password and put it directly there
4. In code, read the secret from environment variables at runtime, never hardcode
5. For deploys, use your hosting platform's secrets feature (Vercel, Railway, Cloudflare Workers all have this) instead of .env files

If you've already committed secrets to a repo: rotate them immediately. The old values are considered compromised even if you remove them from the latest commit, because git history keeps everything.

---

Part 3: Account Security and Hardware MFA

Why passwords aren't enough

Passwords get stolen. People reuse them, type them into fake sites, or pick weak ones. Even a strong password is one phishing email away from being in an attacker's hands.

That's why MFA (multi-factor authentication, sometimes called 2FA) exists. The idea: to log in, you need two things instead of one.

• Something you know (your password)
• Something you have (your phone, a hardware key, etc.)

Even if an attacker steals your password, they can't get in without that second thing.

The catch: not all "second things" are equally safe.

The three types of MFA, from worst to best

SMS codes (avoid). This is when a service texts you a 6-digit code. It feels secure, but it's actually the weakest option. Attackers can call your phone carrier, pretend to be you, and convince them to transfer your phone number to a SIM card the attacker controls. This is called a SIM swap. Once it happens, every text message goes to the attacker, including your login codes. Do not use SMS for anything important.

Authenticator apps (decent). Apps like Google Authenticator, Authy, or 1Password show a 6-digit code on your phone that changes every 30 seconds. Since the code is generated on your device (not sent over the internet), an attacker can't intercept it like they can with SMS. The downside: if you type the code into a fake login page, the attacker can still use it. This type of code is called TOTP (Time-based One-Time Password).

Hardware keys (best). A hardware key is a small physical device, usually shaped like a USB stick, that you plug into your computer or tap on your phone. The most popular brand is YubiKey. To log in, you tap the key. It's the safest option because the key actually checks the website's address before approving the login. Even if you click a phishing link that looks identical to the real site, the key will refuse to authenticate because the address is wrong.

What to actually do

Turn on MFA everywhere. No exceptions. Email, GitHub, hosting, registrar, banking, social media, anything you'd be upset to lose.

Never use SMS-based MFA for anything important. Use TOTP at minimum. Switch to hardware MFA for critical accounts.

Buy two YubiKeys. Around $50-70 each. One you carry, one you store somewhere safe as a backup. If you only have one and lose it, you can be locked out forever.

Use hardware MFA for your most critical accounts:

• Domain registrar
• Email (especially the one used for password resets)
• GitHub/GitLab
• Hosting platform (Vercel, AWS, etc.)
• Crypto wallets and exchange accounts
• 1Password or whatever secrets manager you use

Separate critical accounts from daily-use accounts. Don't use your everyday Google account as the recovery email for your domain registrar. Create a dedicated email used only for critical infrastructure, with hardware MFA, and never log into it from your regular browser.

Cold accounts and cold devices

Once you start dealing with high-stakes operations (managing a treasury, signing transactions, accessing production databases), you'll hear people talk about going "cold."

Here's what that means:

A cold account is an account that exists for one purpose and one purpose only. For example, you might have an email address used only to log in to your domain registrar. You never check it on your phone. You never sign up for newsletters with it. Nobody outside your team even knows it exists. Because it isn't tied to your daily life, it's much harder for an attacker to find or target.

A cold device is the same idea, but for a whole computer. It's a laptop (or even just a separate user account on your existing laptop) used only for sensitive work. You don't browse the web on it, don't install random extensions, don't read email on it. The fewer things touch the device, the smaller the attack surface.

You don't need this on day one. But the moment you have an account or a key that could cause real damage if compromised, set one up. We go deeper on this in the Senior track.

---

Activity: Lock down one of your projects

Pick one app you've built. Could be live, half-finished, or just a personal site. We're going to walk through five quick checks on that one project.

Step 1: Check your domain

Log in to the place you bought your domain (GoDaddy, Namecheap, etc.).

Look for a setting called registry lock. If it's there, turn it on. If your registrar doesn't offer it, consider transferring your domain to one that does.

While you're there, turn on MFA for the account if you haven't already.

Step 2: Hunt for leaked secrets

Open your project in your code editor. Use the search bar to look for these words:

• API_KEY
• SECRET
• TOKEN
• PASSWORD

Did anything show up with a real value next to it (not just a placeholder)? If yes, those are secrets sitting in your code. They need to move.

Step 3: Move them somewhere safe

Sign up for a password manager with shared vaults (1Password's free trial works fine for this activity).

Take every real secret you found in Step 2 and paste it into your password manager. Then:

• Delete the secret from your code
• Add it to your hosting platform's environment variables (Vercel, Railway, Cloudflare, etc. all have a settings page for this)
• Your code reads the secret from the environment instead of having it hardcoded

Step 4: Check your email for breaches

Go to haveibeenpwned.com and type in your email.

If it shows up in any breach, change the password for any account that used that email. Don't reuse the same password anywhere.

Step 5: Upgrade your MFA

For these three accounts:

• Your email
• GitHub
• Your hosting platform

Check what kind of MFA you have. If it's SMS, upgrade to an authenticator app (Google Authenticator, Authy, or 1Password). If you can swing it, buy a YubiKey and use that instead.

---

That's it. If you got through all five steps, your project is in better shape than most indie apps. Once it feels easy, do it again for your other projects.