← From Zero to Deployed Alle LektionenAll lessons Setup ModelleModels

Phase 1 · Grundlagen

09 · Sicherheit

Du kennst die wenigen Gewohnheiten, die eine kleine App und ihre Nutzer schützen.

Phase 1 · Foundations

09 · Security

You know the few habits that protect a small app and its users.

Sobald deine App im Internet steht, finden Fremde sie — auch automatische Bots. Ein paar einfache Gewohnheiten verhindern die meisten echten Probleme. (Hier geht es um Verteidigung, nicht um Angriffsanleitungen.)

Die Idee

Zwei Bilder: Ein Schlüssel gehört in einen Safe, nicht auf einen Zettel an der Tür. Und eine Tür sollte nur die reinlassen, die auch rein dürfen — und zwar nur in die Räume, die sie brauchen.

Bei Instagram heißt das konkret: Nur du kannst dich als du einloggen (der Schlüssel), und nur du darfst deine eigenen Beiträge löschen (die richtige Tür). Fremde dürfen deinen Feed sehen, aber nicht in deinem Namen posten.

So funktioniert es

Die wichtigsten Gewohnheiten:

So hält man Geheimnisse aus dem Code: eine .env-Datei lokal, in Git ignoriert.

# .env  (NICHT committen)
DATABASE_URL=postgres://app:supergeheim@localhost/appdb
SESSION_SECRET=langer-zufallswert

# .gitignore
.env

AuthN und AuthZ am Beispiel „Beitrag löschen“: Erst prüft der Server, ob überhaupt jemand eingeloggt ist (sonst 401). Dann prüft er, ob dieser Jemand der Autor ist (sonst 403).

So steuerst du es

AuthN und AuthZ sind getrennt und gehören beide auf den Server: erst Identität feststellen, dann Rechte prüfen. Niemals der Eingabe vertrauen — alles Ankommende validieren und bereinigen, bevor du es speicherst oder verwendest. Das verhindert ganze Fehlerklassen.

Weiter: Abhängigkeiten aktuell halten (alte Versionen haben bekannte Lücken), so wenig wie möglich öffentlich exponieren, und Least Privilege bei Cloud-Rechten, damit ein kompromittierter Teil wenig Schaden anrichtet.

So sagst du es dem Agenten:

„Lege keine Geheimnisse in den Code oder in Git. Nutze eine .env und trage sie in .gitignore ein.“

„Prüfe serverseitig: 401, wenn niemand eingeloggt ist, 403, wenn die Nutzerin nicht der Autor ist.“

„Erzwinge HTTPS und validiere jede Eingabe, bevor sie in die Datenbank geht.“

Typische Fehler: .env oder Schlüssel versehentlich committen; Regeln nur im Frontend prüfen; oder einem Dienst mehr Cloud-Rechte geben, als er braucht.

Kurz-Check

  1. Wo gehören Passwörter und API-Schlüssel hin — und wo nicht?
  2. Was ist der Unterschied zwischen Authentifizierung und Autorisierung?
  3. Welcher Statuscode passt, wenn eine Fremde einen Beitrag löschen will?
Antworten anzeigen
  1. In Umgebungsvariablen / einen Secret-Manager (z. B. .env, in .gitignore) — nie in den Code oder nach Git.
  2. AuthN klärt „wer bist du?“, AuthZ klärt „was darfst du?“.
  3. 403 (verboten) — sie ist eingeloggt, aber nicht der Autor. (Ist niemand eingeloggt: 401.)

The moment your app is on the internet, strangers find it — including automated bots. A few simple habits prevent most real problems. (This is about defense, not attack instructions.)

The idea

Two pictures: a key belongs in a safe, not on a note taped to the door. And a door should only let in those who are allowed — and only into the rooms they need.

On Instagram that means: only you can sign in as you (the key), and only you may delete your own posts (the right door). Strangers may see your feed, but not post in your name.

How it works

The key habits:

Here is how to keep secrets out of the code: a .env file locally, ignored by Git.

# .env  (do NOT commit)
DATABASE_URL=postgres://app:supersecret@localhost/appdb
SESSION_SECRET=long-random-value

# .gitignore
.env

AuthN and AuthZ using "delete a post": first the server checks whether anyone is signed in at all (otherwise 401). Then it checks whether that someone is the author (otherwise 403).

How you steer it

AuthN and AuthZ are separate and both belong on the server: establish identity first, then check permissions. Never trust input — validate and clean everything arriving before you store or use it. That prevents whole classes of bugs.

Further: keep dependencies current (old versions have known holes), expose as little publicly as possible, and use least privilege for cloud permissions so a compromised part does little damage.

How to tell the agent:

"Do not put secrets in the code or in Git. Use a .env and add it to .gitignore."

"Check on the server: 401 if nobody is signed in, 403 if the user is not the author."

"Enforce HTTPS and validate every input before it goes into the database."

Common mistakes: accidentally committing .env or keys; checking rules only in the frontend; or giving a service more cloud rights than it needs.

Quick check

  1. Where do passwords and API keys belong — and where not?
  2. What is the difference between authentication and authorization?
  3. Which status code fits when a stranger tries to delete a post?
Show answers
  1. In environment variables / a secret manager (e.g. .env, in .gitignore) — never in the code or in Git.
  2. AuthN answers "who are you?", AuthZ answers "what may you do?".
  3. 403 (forbidden) — they are signed in but not the author. (If nobody is signed in: 401.)