Security & Privacy Fundamentals

Protect your projects — understand the security concepts that matter for AI-assisted development.

INFO

• Time: ~45 minutes
• Difficulty: Beginner
• What you'll learn: API keys, OAuth, JWT tokens, common security mistakes

---

This Page Covers

• API keys: what they are and why they matter
• OAuth and social login explained
• JWT tokens and authentication
• Common security mistakes to avoid

---

API Keys

What They Are

Think of API keys as passwords for programs. When your application needs to talk to a service (like OpenAI, Stripe, or a weather API), it uses an API key to identify itself. The key tells the service "this request is coming from Florian's app" rather than some random stranger.

Unlike your personal passwords, API keys are long strings of random characters that look something like this: sk-proj-abc123xyz789...

Why They Matter

API keys serve three critical purposes:

1. Access Control — They determine what your app can and cannot do. Without the right key, services will reject your requests.

2. Billing and Quotas — Services track your usage through your API key. If you're using OpenAI's API, every request tied to your key counts toward your bill.

3. Abuse Prevention — Keys allow services to shut down bad actors. If someone abuses a service, their key gets revoked without affecting everyone else.

How to Keep Them Secret

Where to store API keys:

• Local development: Use .env files (environment files). These are special files that store configuration outside your code.
• Production: Use your hosting provider's environment variables (Vercel, Netlify, and others all have secure ways to store secrets).

Where NOT to store API keys:

• Never in your code — Not even "just for testing"
• Never in Git — Not even in private repositories
• Never in frontend code — Browsers can see everything!

What happens if leaked: This is not hypothetical. Bots constantly scan GitHub for exposed API keys. Within minutes of accidentally pushing a key, someone could be using it. People have woken up to bills of thousands of dollars because their AWS or OpenAI keys were exposed overnight.

---

OAuth and "Login with"

The Problem It Solves

Imagine you're building an app. You could create your own login system, store passwords in a database, handle password resets, deal with security breaches... or you could let Google handle all of that.

OAuth lets users log in to your app using accounts they already have (Google, GitHub, Apple, etc.). You never see or store their password.

How OAuth Works

The flow is simpler than it sounds:

1. User clicks "Login with Google" on your site
2. Redirect to Google — User is taken to Google's login page (not yours)
3. User approves — Google asks "Do you want to let this app access your basic info?"
4. Redirect back — Google sends the user back to your site with a special token
5. Verify identity — Your app uses that token to confirm who the user is

The key insight: your app never touches the user's Google password. Google handles all the sensitive authentication.

Social Login Explained

Those "Login with Google" or "Continue with GitHub" buttons you see everywhere are OAuth in action.

Benefits

For users:

• No new password to create and remember
• Trust established companies with security
• One-click login experience

For developers:

• No passwords to store (and potentially leak)
• No password reset emails to build
• Less security burden on your shoulders
• Users are more likely to sign up (lower friction)

Trade-off: You're depending on third-party services. If Google's login is down, your users can't log in. Many apps offer multiple login options for this reason.

---

JWT Tokens

What JWTs Are

JWT (pronounced "jot") stands for JSON Web Token. Think of it as a digital identity card that your app issues after you log in.

Unlike a traditional session where the server has to remember who you are, a JWT contains all the information needed to verify your identity. It's self-contained.

Structure

JWTs have three parts separated by dots: Header.Payload.Signature

Each part is encoded (not encrypted — anyone can read it, but they can't fake it). The signature proves the token hasn't been tampered with.

You don't need to understand JWTs deeply. As a beginner, here's what matters:

• They expire for security (usually after hours or days)
• They're used after login to prove who you are on subsequent requests
• You'll see them in request headers like this: Authorization: Bearer eyJhbGci...

Token Expiration

Tokens expire intentionally. If someone steals your token, they can only use it until it expires. This limits the damage from security breaches.

When a token expires, users typically need to log in again (or your app silently uses a "refresh token" to get a new one).

---

Common Security Mistakes

Here are the mistakes beginners make most often — and how to avoid them:

1. Committing .env Files

Your .env file contains secrets. It should never be committed to Git.

Fix: Add .env to your .gitignore file immediately when starting any project. Most project templates do this automatically, but always double-check.

# .gitignore
.env
.env.local
.env*.local

2. API Keys in Frontend Code

Everything in your frontend (browser) code is visible to users. Open DevTools, look at the source code, and you can see everything.

Fix: API keys belong on the server. If you need to call an API from the browser, create a server endpoint that makes the call for you (hiding the key on the server side).

3. Using HTTP Instead of HTTPS

HTTP sends data in plain text — anyone on the network can read it. HTTPS encrypts everything.

Fix: Always use HTTPS (look for the padlock icon in your browser). Modern hosting platforms like Vercel and Netlify provide HTTPS automatically.

4. Trusting User Input

Never assume users will send valid, safe data. Attackers will send malicious input to try to break your app.

Fix: Validate everything. If you expect an email address, verify it looks like an email. If you expect a number, confirm it's actually a number. Server-side validation is essential — client-side validation can be bypassed.

---

Data Privacy Considerations

What You're Sharing with AI

Every time you paste code into ChatGPT or Claude, that text goes to their servers. For most personal projects, this is fine. But be careful about:

• Customer data — Don't paste real user information into AI tools
• Passwords and secrets — Never paste API keys or credentials
• Company confidential information — Check your employer's policies

Read the terms of service. Different AI tools have different data retention policies. Some may use your inputs for training; others explicitly don't. Know what you're agreeing to.

User Data Responsibilities

If your app collects user data, you have responsibilities:

• Be transparent about what you collect and why
• Store data securely — encryption at rest and in transit
• GDPR and privacy laws — If you have users in Europe, GDPR applies. When in doubt, consult a legal expert.

For hobby projects, keep it simple: collect only what you need, be honest about it, and delete data when users ask.

---

Self-Hosting vs Cloud vs Private Cloud

Cloud Hosting

What it is: Services like Vercel, Netlify, AWS, and Google Cloud run your application on their infrastructure.

Pros:

• Easy setup — deploy in minutes
• Managed infrastructure — they handle security updates, scaling, backups
• Automatic scaling — handle traffic spikes without manual intervention

Cons:

• Data on someone else's servers
• Ongoing costs that can be unpredictable
• Less control over the underlying system

Self-Hosting

What it is: Running your application on servers you own and control.

Pros:

• Full control over everything
• Complete data ownership
• Maximum privacy

Cons:

• Full responsibility for security, updates, and maintenance
• You're the one waking up at 3am when something breaks
• Requires significant technical knowledge

Private Cloud

What it is: Managed infrastructure that's isolated just for you — like having your own section of AWS.

Pros:

• Best of both worlds: managed convenience with more control
• Meets enterprise compliance requirements
• Dedicated resources

Cons:

• Usually expensive (enterprise pricing)
• Still some dependency on the provider
• Overkill for most projects

For Beginners

Start with cloud hosting. It's the easiest path forward. Services like Vercel and Netlify have generous free tiers and handle the hard parts of deployment for you.

Consider self-hosting later when:

• You understand the trade-offs deeply
• You have specific privacy requirements (not just vague concerns)
• You have the technical skills to maintain it

Don't self-host for "privacy theater." If you're worried about privacy but don't understand what threats you're actually protecting against, self-hosting might give you a false sense of security while creating real security holes through misconfiguration.

---

Key Takeaways

• API keys are like passwords for your applications — protect them accordingly
• Never commit secrets to version control (add .env to .gitignore immediately)
• OAuth lets users login with existing accounts, reducing your security burden
• JWTs are self-contained authentication tokens that expire for safety
• Client-side code is visible to everyone — never put secrets in frontend code
• Be mindful of what data you share with AI tools
• Start with cloud hosting; consider self-hosting only when you understand the trade-offs