Carola Schulte, App-Entwicklerin

App-Sicherheit & DSGVO: Was wirklich nötig ist

Sie wollen eine sichere App entwickeln und DSGVO-konform launchen - aber ohne Angstmacherei und ohne Security-Theater? Dieser Guide zeigt Ihnen, was wirklich nötig ist: Security-by-Design, praktische DSGVO-Compliance und eine Go-Live-Gate-Checkliste, die funktioniert.

Als Network Security Engineer mit 25+ Jahren Erfahrung zeige ich Ihnen, was MUSS und was NICE-TO-HAVE ist - ohne Buzzwords, mit konkreten Beispielen aus realen Projekten.

🔔 WICHTIG: Alle Preise verstehen sich netto (zzgl. 19% USt.). DE-Sätze; Offshore/NE-EU abweichend.

Die gute Nachricht vorweg

Security ist nicht teuer - wenn Sie von Anfang an richtig planen.

✅ Security-by-Design kostet 5-10% mehr als unsichere App
✅ DSGVO-Compliance kostet 3-5 Entwicklertage extra
✅ Penetration Test kostet 2.500-8.000 € (einmalig vor Launch)

Die schlechte Nachricht: Nachträgliche Security kostet 3-5x mehr (weil Sie Architektur umbauen müssen).

Fazit: Planen Sie Security von Tag 1 ein - es spart Zeit und Geld.

Security-by-Design: Von Anfang an richtig

Was ist Security-by-Design?

Security-by-Design bedeutet: Sie planen Sicherheit vor dem ersten Code, nicht nachträglich.

Beispiel aus der Praxis (Wächterkontrollsystem):

Ansatz	Wann implementiert	Aufwand	Kosten
Security-by-Design	Tag 1 (Discovery-Phase)	+8% Dev-Zeit	+6.500 €
Nachträglich	Nach 6 Monaten Dev	+150% Refactoring	+35.000 €

Unterschied: Bei Security-by-Design entscheiden Sie in der Discovery-Phase:

Welche Daten werden verschlüsselt? (AES-256-GCM)
Wie funktioniert Auth? (JWT mit Refresh-Token)
Wo werden Daten gespeichert? (verschlüsselte DB: SQLCipher)
Wie sieht Backup & Recovery aus?

Bei nachträglicher Security müssen Sie:

❌ Datenbank-Schema umbauen (von plain text zu encrypted)
❌ API-Endpunkte umschreiben (von HTTP zu HTTPS + Pinning)
❌ Alle User-Daten migrieren (mit Downtime)
❌ App-Updates forcieren (alte Versionen funktionieren nicht mehr)

OWASP Top 10 Mobile: Was bedeutet das praktisch?

Die OWASP Top 10 Mobile sind die häufigsten Sicherheitsrisiken in mobilen Apps. Hier sind die Top 5 - mit konkreten Lösungen:

1. Unsichere Datenspeicherung (Improper Platform Usage)

Problem: Sensible Daten (Passwörter, Tokens, Kreditkarten) im Klartext auf dem Gerät gespeichert.

Beispiel: App speichert JWT-Token in SharedPreferences (Android) oder UserDefaults (iOS) - ohne Verschlüsselung.

Lösung:

Android: EncryptedSharedPreferences (Jetpack Security)
iOS: Keychain (systemseitig verschlüsselt)
Flutter: flutter_secure_storage (nutzt Keychain/Keystore)

Kosten: 1-2 Entwicklertage (inkludiert in Security-by-Design)

2. Unsichere Kommunikation (Insecure Communication)

Problem: API-Kommunikation über HTTP statt HTTPS, oder HTTPS ohne Certificate Pinning.

Beispiel: App sendet Login-Daten über HTTP → Man-in-the-Middle-Attacke möglich.

Lösung:

HTTPS Pflicht (Let’s Encrypt ist kostenlos)
Public-Key (SPKI) Pinning mit Backup-Pins (verhindert Man-in-the-Middle, robust bei Zertifikatwechsel)
TLS 1.3 (statt TLS 1.2 oder älter)

Kosten: 2-3 Entwicklertage (Pinning Setup)

Hinweis: Public-Key Pinning mit 2+ Backup-Pins vermeidet “Brick-Risk” bei Zertifikatwechsel - Standard für Banking/Health Apps.

3. Unsichere Authentifizierung (Insecure Authentication)

Problem: Schwache Passwörter erlaubt, kein Rate-Limiting, keine 2FA-Option.

Beispiel: App erlaubt “12345” als Passwort, keine Account-Sperre nach 10 Fehlversuchen.

Lösung:

Passwort-Policy: Mind. 8 Zeichen, 1 Zahl, 1 Sonderzeichen
Rate-Limiting: Max. 5 Login-Versuche pro Minute
2FA optional (SMS oder TOTP)
JWT mit Refresh-Token (Access: 15 Min, Refresh: 7 Tage) + Refresh-Token Rotation + Reuse-Detection
WebViews: Secure + HttpOnly + SameSite=strict Cookies
Mobile: Tokens nur in Keychain (iOS) / Keystore (Android)

Kosten: 3-4 Entwicklertage

4. Unsichere Autorisierung (Insecure Authorization)

Problem: User A kann Daten von User B sehen/ändern (IDOR: Insecure Direct Object Reference).

Beispiel: API-Endpoint /api/users/123/profile → User A kann /api/users/456/profile aufrufen und Daten von User B sehen.

Lösung:

Backend-Validierung: Jeder API-Call prüft: “Gehört diese Ressource zu diesem User?”
Nie auf Client-Side Checks verlassen (Frontend ist nicht vertrauenswürdig)

Kosten: 2-3 Entwicklertage (Backend-Middlewares)

5. Code-Qualität (Insufficient Cryptography)

Problem: Selbst-gebaute Verschlüsselung, veraltete Algorithmen (MD5, SHA1), Hardcoded Keys.

Beispiel: App nutzt MD5 zum Hashen von Passwörtern (MD5 ist seit 2004 gebrochen).

Lösung:

AES-256-GCM für Verschlüsselung (symmetrisch)
RSA-2048+ für asymmetrische Verschlüsselung
Argon2id (empfohlen) oder bcrypt $2b (cost 10–12) mit per-User Salt
Keine Hardcoded Keys (nutze Keychain/Keystore)

Kosten: 1-2 Entwicklertage (wenn von Anfang an geplant)

DSGVO: Was ist PFLICHT, was OPTIONAL?

Die DSGVO (Datenschutz-Grundverordnung) gilt für alle Apps, die personenbezogene Daten von EU-Bürgern verarbeiten.

Was sind personenbezogene Daten?

✅ Name, E-Mail, Telefonnummer
✅ IP-Adresse, Geräte-ID, Standort
✅ Gesundheitsdaten, biometrische Daten
❌ Anonymisierte Statistiken (z.B. “5 User aus Berlin”)

Wichtig: Auch rein technische Daten (IP, Geräte-ID) sind personenbezogen!

DSGVO-Pflichten: Was MUSS sein

Pflicht	Was bedeutet das?	Wann umsetzen?
Rechtsgrundlage	Einwilligung oder berechtigtes Interesse	Discovery-Phase
Datenschutzerklärung	Was speichern Sie? Warum? Wie lange?	Vor Launch
AVV (falls Drittanbieter)	Vertrag mit Firebase, AWS, Stripe, etc.	Vor Launch
Zweckbindung	Daten nur für definierten Zweck nutzen	Architektur-Phase
Löschkonzept	Wie lange speichern? Automatische Löschung?	Architektur-Phase
Betroffenenrechte	Auskunft, Löschung, Datenportabilität	Backend-Dev
Technische Maßnahmen	Verschlüsselung, Zugriffskontrolle, Backup	Dev-Phase

DSGVO-Checkliste (praktisch)

1. Rechtsgrundlage klären

Frage: Warum verarbeiten Sie Daten?

✅ Einwilligung: User stimmt explizit zu (z.B. Newsletter)
✅ Vertragserfüllung: Daten sind nötig für Service (z.B. E-Mail für Login)
✅ Berechtigtes Interesse: Nur mit Interessenabwägung + dokumentiertem Opt-out

Beispiel Fitness-App:

E-Mail für Login → Vertragserfüllung ✅
Workout-Daten speichern → Vertragserfüllung ✅
Analytics → Vorzugsweise Einwilligung (Opt-in); berechtigtes Interesse nur mit Abwägung + Opt-out dokumentiert

2. Datenschutzerklärung schreiben

Must-Have-Inhalte:

Welche Daten werden gespeichert? (E-Mail, Name, Workout-Daten)
Warum? (Login, Feature X, Analytics)
Wie lange? (Account-Löschung: sofort, Backups: 30 Tage)
Wo? (Server in EU, Firebase Firestore Ireland)
Drittanbieter? (Google Analytics, Stripe, Firebase)
Rechte? (Auskunft, Löschung, Widerspruch)

Tool: Generator von e-recht24.de (kostenpflichtig, aber rechtssicher)

Kosten: 300-800 € für Anwalt (einmalig)

3. AVV mit Drittanbietern abschließen

AVV = Auftragsverarbeitungsvertrag (Art. 28 DSGVO)

Pflicht, wenn:

Sie nutzen Firebase, AWS, Stripe, SendGrid, etc.
Diese Anbieter verarbeiten personenbezogene Daten in Ihrem Auftrag

Beispiele:

Firebase: AVV hier abschließen (inkl. Sub-Processors-Liste)
AWS: AVV hier (ggf. Transfer Impact Assessment + SCCs für US)
Stripe: AVV hier

Wichtig: Bei US-Anbietern: Transfer Impact Assessment + Standard-Vertragsklauseln (SCCs) prüfen.

Kosten: Kostenlos (meist online abrufbar)

Aufwand: 2-4 Stunden (AVVs + Sub-Processors + SCCs durchlesen)

4. Löschkonzept implementieren

Frage: Wie lange speichern Sie Daten?

Best Practice:

Account-Daten: Solange Account aktiv ist
Logs: 30-90 Tage (für Debugging) + PII-Redaction (keine Passwörter/Tokens)
Backups: 30 Tage, dann automatisch löschen + Restore-Drill 1×/Quartal (RTO/RPO testen)
Analytics: 14 Monate (Google Analytics Standard)

Technische Umsetzung:

-- Auto-Delete nach 90 Tagen (PostgreSQL)
DELETE FROM logs WHERE created_at < NOW() - INTERVAL '90 days';

Kosten: 1 Entwicklertag (Cron-Job Setup) + 0,5 Tage/Quartal (Restore-Tests)

5. Betroffenenrechte implementieren

Pflicht-Features:

✅ Auskunft: User kann alle gespeicherten Daten exportieren
✅ Löschung: User kann Account + Daten löschen
✅ Widerspruch: User kann Analytics ablehnen

Technische Umsetzung:

Export: JSON-Datei mit allen User-Daten (Download-Button in Settings)
Löschung: “Account löschen”-Button → Backend löscht alle Daten
Widerspruch: Analytics Opt-out (Toggle in Settings)

Kosten: 2-3 Entwicklertage

Real Cases: Security & DSGVO in der Praxis

Case 1: Wächterkontrollsystem (GPS, NFC, Kamera)

Herausforderung:

GPS-Daten (= personenbezogen)
Fotos von Wachobjekten (ggf. Personen drauf)
NFC-Check-Ins (wer war wann wo)

Security-Implementierung:

AES-256-GCM für GPS-Daten (verschlüsselt in SQLCipher)
Fotos: Nur auf Gerät gespeichert, Upload nur bei WLAN
Backend: TLS 1.3 + Certificate Pinning
Zugriff: Nur authentifizierte Wachleute, keine Cross-User-Sicht

DSGVO-Implementierung:

Rechtsgrundlage: Vertragserfüllung (Wachdienst-Vertrag)
Löschkonzept: GPS-Logs nach 90 Tagen automatisch löschen
AVV: Mit Cloud-Provider (AWS)
Datenschutzerklärung: Klar dokumentiert, was gespeichert wird

Kosten Security + DSGVO: +8.500 € (bei 85k Gesamtbudget = +10%)

Case 2: Mensa-NFC-App (Check-in, Ampel-Status)

Herausforderung:

NFC-Check-Ins (Student-ID → personenbezogen)
Offline-First (Daten lokal gespeichert)
Master-Slave-Sync (mehrere Geräte)

Security-Implementierung:

SQLCipher für lokale Datenbank (verschlüsselt)
JWT-Tokens für Auth (7 Tage Gültigkeit)
Backend: HTTPS + Rate-Limiting (max. 100 Requests/Min)

DSGVO-Implementierung:

Rechtsgrundlage: Vertragserfüllung (Mensa-Nutzung)
Löschkonzept: Check-in-Logs nach 30 Tagen löschen
Betroffenenrechte: Export-Funktion (alle Check-ins als CSV)
Datenschutzerklärung: Kurz + verständlich (nicht Juristendeutsch)

Kosten Security + DSGVO: +4.500 € (bei 45k Gesamtbudget = +10%)

Was kostet Security wirklich?

Security-Kosten im Überblick

Maßnahme	Wann	Aufwand	Kosten
Security-by-Design (Discovery)	Discovery-Phase	+1-2 Tage	+1.500-3.000 €
Verschlüsselung (AES-256-GCM)	Dev-Phase	+2-3 Tage	+2.500-4.000 €
Certificate Pinning	Dev-Phase	+2-3 Tage	+2.500-4.000 €
DSGVO-Compliance	Dev + Legal	+3-5 Tage	+3.500-6.000 €
Penetration Test	Vor Launch	Extern	+2.500-8.000 €
Security-Audit (optional)	Vor Launch	Extern	+5.000-15.000 €

Gesamt (Standard-App): 12.500-25.000 € für vollständige Security + DSGVO

Aber: Bei Security-by-Design sind 70% dieser Kosten in normaler Dev-Zeit inkludiert (weil Sie von Anfang an richtig bauen).

Nur zusätzlich: Penetration Test (2.500-8.000 €) + Anwalt für Datenschutzerklärung (300-800 €)

Go-Live-Gate: Checkliste (Was MUSS vor Launch fertig sein)

Diese 20-Punkte-Checkliste ist Ihr Go-Live-Gate - wenn alle Punkte ✅ sind, können Sie launchen.

Technische Security (10 Punkte)

DSGVO-Compliance (10 Punkte)

Nice-to-Have (nicht Pflicht, aber empfohlen)

2FA: SMS oder TOTP (Google Authenticator)
Biometrische Auth: Face-ID/Touch-ID (iOS), Fingerprint (Android)
Session-Management: Logout nach 30 Min Inaktivität
Penetration Test: Vor Launch durchgeführt
Security-Audit: Von externem Auditor geprüft

Top 5 Security-Fehler (und wie Sie sie vermeiden)

Fehler 1: Passwörter im Klartext speichern

Problem: App speichert Passwörter in SharedPreferences oder Datenbank - ohne Hashing.

Lösung:

Nie Passwörter speichern - nur Hashes
Argon2id (empfohlen) oder bcrypt $2b (cost 10–12) für Hashing
Per-User Salt (verhindert Rainbow-Table-Attacks)

Kosten: 1 Entwicklertag (wenn von Anfang an geplant)

Fehler 2: HTTP statt HTTPS

Problem: API-Calls über HTTP → Man-in-the-Middle-Attacke möglich.

Lösung:

HTTPS Pflicht (Let’s Encrypt ist kostenlos)
Android: android:usesCleartextTraffic="false" in Manifest
iOS: NSAppTransportSecurity (HTTPS only)

Kosten: 0 € (Let’s Encrypt ist kostenlos)

Fehler 3: Hardcoded API-Keys

Problem: API-Keys direkt im Code (z.B. String apiKey = "sk_live_123abc").

Lösung:

Environment-Variablen (z.B. .env-Datei, nicht in Git)
Backend: API-Keys nur auf Server, nie im Frontend
Secret-Management: AWS Secrets Manager, Google Secret Manager

Kosten: 1 Entwicklertag

Fehler 4: Keine Input-Validierung

Problem: User-Inputs nicht validiert → SQL-Injection, XSS möglich.

Beispiel: /api/users?id=123 OR 1=1 → gibt alle User zurück.

Lösung:

-- ❌ Unsicher (SQL-Injection möglich)
query = "SELECT * FROM users WHERE id = " + userId;

-- ✅ Sicher (Prepared Statement)
query = "SELECT * FROM users WHERE id = ?";
preparedStatement.setInt(1, userId);

Prepared Statements (SQL-Injection-sicher)
Whitelist statt Blacklist (nur erlaubte Zeichen zulassen)
Sanitize HTML (verhindert XSS)

Kosten: 2 Entwicklertage (Middlewares + Testing)

Fehler 5: Keine Rate-Limiting

Problem: Angreifer kann 1000 Login-Versuche pro Sekunde machen (Brute-Force).

Lösung:

Rate-Limiting: Max. 5 Login-Versuche pro Minute
Account-Sperre: Nach 10 Fehlversuchen → 1 Stunde gesperrt
CAPTCHA: Nach 3 Fehlversuchen (Google reCAPTCHA)

Kosten: 1 Entwicklertag

Penetration Tests: Wann sind sie nötig?

Ein Penetration Test (Pentest) ist ein simulierter Angriff auf Ihre App - durchgeführt von Security-Experten.

Wichtig: Pentest ist zusätzlich zu Entwicklungskosten (einmalig vor Launch).

Wann ist ein Pentest Pflicht?

✅ Banking/FinTech: Pflicht (PCI-DSS-Compliance)
✅ Health: Empfohlen (HIPAA/GDPR)
✅ E-Commerce: Empfohlen (ab 10k+ Transaktionen/Monat)
❌ Standard-App: Optional (aber sinnvoll vor Launch)

Was kostet ein Pentest?

App-Typ	Umfang	Kosten (zusätzlich)
Basic	Frontend + 5-10 API-Endpoints	2.500-4.000 €
Standard	Frontend + Backend + Datenbank	5.000-8.000 €
Komplex	Multi-Platform + IoT + Payment	10.000-20.000 €

Dauer: 3-7 Tage (inkl. Report mit Fixes) Zeitpunkt: Vor Launch (aber nach Entwicklung)

Was bekommen Sie?

✅ Pentest-Report (PDF, 20-50 Seiten)
✅ Vulnerability-Liste (Critical, High, Medium, Low)
✅ Fix-Empfehlungen (konkret, wie beheben)
✅ Re-Test (nach Fixes, meist kostenlos)

Zertifikat: Optional (für Kunden/Investoren)

FAQs: Security & DSGVO

1. Brauche ich einen Datenschutzbeauftragten?

Kurze Antwort: Meist nein (bei Startups/kleinen Teams).

Lange Antwort:

Pflicht, wenn:

✅ Mehr als 20 Mitarbeiter (die mit Daten arbeiten)
✅ Hochrisiko-Daten: Gesundheit, biometrische Daten, Standort-Tracking
✅ Profiling: Automatisierte Entscheidungen (z.B. Scoring)

Nicht Pflicht, wenn:

❌ Startup mit 3 Entwicklern
❌ Standard-App (E-Mail, Name, Workout-Daten)

Alternative: Externer Datenschutzbeauftragter (300-800 €/Monat)

2. Was passiert bei DSGVO-Verstoß?

Bußgelder:

Kleinere Verstöße: Bis 10 Mio. € oder 2% vom Jahresumsatz
Größere Verstöße: Bis 20 Mio. € oder 4% vom Jahresumsatz

Realität (Startups):

Bei erstem Verstoß: Meist Abmahnung + Frist zur Behebung
Bußgeld: Selten bei Startups (außer grobe Fahrlässigkeit)

Prävention ist günstiger: 5k € für DSGVO-Compliance vs. 50k+ € Anwalt + Bußgeld.

3. Reicht ein SSL-Zertifikat?

Kurze Antwort: Ja, für Standard-Apps.

Lange Antwort:

✅ SSL/TLS-Zertifikat (Let’s Encrypt) reicht für 90% der Apps
✅ Certificate Pinning nur nötig für Banking/Health/High-Security Apps
❌ Nicht nötig: Eigene PKI (Public Key Infrastructure)

Kosten:

SSL/TLS: 0 € (Let’s Encrypt)
Certificate Pinning: 2-3 Entwicklertage
Eigene PKI: 10.000+ € (nur für Enterprise)

4. Was ist Security-by-Design vs. nachträglich?

Aspekt	Security-by-Design	Nachträglich
Wann	Discovery-Phase (Tag 1)	Nach 6-12 Monaten Dev
Aufwand	+5-10% Dev-Zeit	+150-300% Refactoring
Kosten	+5-10k €	+30-60k €
Risiko	Niedrig (geplant)	Hoch (Breaking Changes)

Beispiel: Bei 60k App-Budget:

Security-by-Design: +6k € (10%)
Nachträglich: +45k € (75%)

5. Brauche ich eine Security-Audit vor Launch?

Kurze Antwort: Nice-to-Have, nicht Pflicht.

Lange Antwort:

Pflicht:

✅ Banking/FinTech (PCI-DSS)
✅ Health (HIPAA/GDPR)

Empfohlen:

✅ E-Commerce (ab 10k+ Transaktionen/Monat)
✅ SaaS (B2B-Kunden fragen oft danach)

Optional:

❌ Standard-App (B2C)

Alternative: Penetration Test (günstiger, fokussierter)

Zusätzliche Security-Maßnahmen (Optional)

Code Obfuscation (Reverse Engineering erschweren)

Was ist das: Code wird verschleiert, um Reverse Engineering zu erschweren.

Umsetzung:

Android: ProGuard/R8 (automatisch in Release-Build)
iOS: Bitcode (optional, erschwert Analyse)
Flutter: --obfuscate Flag beim Build

Wann nötig:

✅ Banking/FinTech Apps (PCI-DSS)
✅ Health Apps (Patientendaten)
✅ Apps mit proprietärem Algorithmus
❌ Standard-Apps (nicht kritisch)

Kosten: 0 € (bei ProGuard/R8), 1-2 Tage (manuelle Konfiguration)

Jailbreak/Root Detection (kompromittierte Geräte)

Was ist das: App prüft, ob Gerät kompromittiert ist (Jailbreak/Root).

Problem:

Jailbreak (iOS): User hat Root-Zugriff, kann App manipulieren
Root (Android): Systemzugriff = Sicherheitsrisiko

Umsetzung:

iOS: Jailbreak-Detection (prüft auf Cydia, etc.)
Android: Root-Detection (prüft auf SuperSU, Magisk)
Reaktion: App verweigert Start oder warnt User

Wann nötig:

✅ Banking/FinTech Apps (Pflicht)
✅ Health Apps (empfohlen)
✅ Payment-Apps (empfohlen)
❌ Standard-Apps (nicht nötig)

Kosten: 1-2 Entwicklertage

Achtung: Kann umgangen werden (fortgeschrittene Angreifer), aber verhindert 90% der Fälle.

Fazit: Security ist kein Luxus - es ist Standard

Die wichtigsten Learnings:

✅ Security-by-Design kostet +5-10% - nachträglich +150-300%
✅ DSGVO ist machbar - 3-5 Entwicklertage + Anwalt
✅ Go-Live-Gate: 20 Punkte-Checkliste (was MUSS sein)
✅ Penetration Test: 2.500-8.000 € (einmalig, vor Launch)
✅ OWASP Top 10 Mobile: Kennen + umsetzen = 90% der Risiken vermieden
✅ Keine Angstmacherei: Priorisieren Sie, was wirklich nötig ist

Security ist kein Feature - es ist Foundation. Planen Sie es von Tag 1 ein, und Sie sparen Zeit, Geld und Nerven.

Lassen Sie uns über Ihr App-Projekt sprechen

Sie wollen eine sichere App entwickeln - ohne Security-Theater, mit klarem Go-Live-Gate? In einem kostenlosen Erstgespräch (30 Min):

✅ Analysieren wir Ihre Security-Anforderungen (was ist wirklich nötig)
✅ Klären wir DSGVO-Compliance (AVV, Löschkonzept, Rechtsgrundlage)
✅ Definieren wir Ihr Go-Live-Gate (20 Punkte-Checkliste)
✅ Schätzen wir Security-Kosten (transparent, keine Überraschungen)

Keine Buzzwords, keine Angstmacherei - nur ehrliche Einschätzung aus 25+ Jahren Security-Erfahrung.

Termin vereinbaren →

Weitere hilfreiche Artikel:

Ihr App-Projekt besprechen?

Lassen Sie uns in einem kostenlosen Erstgespräch über Ihre Anforderungen sprechen.

Jetzt Kontakt aufnehmen

App-Sicherheit & DSGVO 2025: Was wirklich nötig ist

Teilen

Inhaltsverzeichnis

Carola Schulte, App-Entwicklerin

App-Sicherheit & DSGVO: Was wirklich nötig ist

Die gute Nachricht vorweg

Security-by-Design: Von Anfang an richtig

Was ist Security-by-Design?

OWASP Top 10 Mobile: Was bedeutet das praktisch?

1. Unsichere Datenspeicherung (Improper Platform Usage)

2. Unsichere Kommunikation (Insecure Communication)

3. Unsichere Authentifizierung (Insecure Authentication)

4. Unsichere Autorisierung (Insecure Authorization)

5. Code-Qualität (Insufficient Cryptography)

DSGVO: Was ist PFLICHT, was OPTIONAL?

Was sind personenbezogene Daten?

DSGVO-Pflichten: Was MUSS sein

DSGVO-Checkliste (praktisch)

1. Rechtsgrundlage klären

2. Datenschutzerklärung schreiben

3. AVV mit Drittanbietern abschließen

4. Löschkonzept implementieren

5. Betroffenenrechte implementieren

Real Cases: Security & DSGVO in der Praxis

Case 1: Wächterkontrollsystem (GPS, NFC, Kamera)

Case 2: Mensa-NFC-App (Check-in, Ampel-Status)

Was kostet Security wirklich?

Security-Kosten im Überblick

Go-Live-Gate: Checkliste (Was MUSS vor Launch fertig sein)

Technische Security (10 Punkte)

DSGVO-Compliance (10 Punkte)

Nice-to-Have (nicht Pflicht, aber empfohlen)

Top 5 Security-Fehler (und wie Sie sie vermeiden)

Fehler 1: Passwörter im Klartext speichern

Fehler 2: HTTP statt HTTPS

Fehler 3: Hardcoded API-Keys

Fehler 4: Keine Input-Validierung

Fehler 5: Keine Rate-Limiting

Penetration Tests: Wann sind sie nötig?

Wann ist ein Pentest Pflicht?

Was kostet ein Pentest?

Was bekommen Sie?

FAQs: Security & DSGVO

1. Brauche ich einen Datenschutzbeauftragten?

2. Was passiert bei DSGVO-Verstoß?

3. Reicht ein SSL-Zertifikat?

4. Was ist Security-by-Design vs. nachträglich?

5. Brauche ich eine Security-Audit vor Launch?

Zusätzliche Security-Maßnahmen (Optional)

Code Obfuscation (Reverse Engineering erschweren)

Jailbreak/Root Detection (kompromittierte Geräte)

Fazit: Security ist kein Luxus - es ist Standard

Lassen Sie uns über Ihr App-Projekt sprechen

Verwandte Themen

Ihr App-Projekt besprechen?