Architekturüberblick
MapSpoto verwendet Expo / React Native im Frontend und Supabase für Authentifizierung, Datenbank, Storage und Realtime-Funktionen im Backend.
Der Stack selbst ist keine Sicherheitsgarantie, aber er stellt ausgereifte Bausteine für Authentifizierung, Berechtigungen und Datenbankkontrollen bereit, die wir für strengere Zugriffsregeln nutzen können.
Datenbank-Zugriffskontrolle
MapSpoto nutzt PostgreSQL Row Level Security (RLS), um den Datenzugriff einzuschränken.
Das bedeutet, dass normale Clients nur Daten lesen können, für die sie berechtigt sind. Nicht öffentliche Daten anderer Nutzer sind über die normalen App-Schnittstellen nicht zugänglich.
Wir veröffentlichen keine langen SQL-Richtlinien direkt auf der Website, prüfen und verschärfen die Datenbankregeln aber laufend.
Konto- und Passwortsicherheit
Das Kontosystem basiert auf Supabase Auth.
Entwickler können Ihr Klartext-Passwort nicht sehen. Speicherung und Prüfung von Passwörtern übernimmt das Authentifizierungssystem.
Umgang mit Frontend-Schlüsseln
Das App-Frontend verwendet nur einen eingeschränkten anonymen Zugriffsschlüssel (Anon Key), um sich mit dem Backend zu verbinden.
Hochprivilegierte Service-Schlüssel werden nicht in den Frontend-Code eingebettet und nicht mit der App ausgeliefert.
Sicherheitsprüfungen
Wir nutzen Drittanbieter-Tools und Plattformfunktionen, um häufige Sicherheitsprobleme zu prüfen, zum Beispiel:
- Supabase Security Advisor zur Prüfung von Datenbank-, RLS- und Storage-Zugriffseinstellungen.
- Abhängigkeitsscans, um bekannte Probleme in Drittanbieter-Paketen zu erkennen.
- Code-Scanner, um typische Sicherheitsfehler und Fehlkonfigurationen zu finden.
- Secret-Scanning, um sicherzustellen, dass keine hochprivilegierten Schlüssel oder sensiblen Umgebungsvariablen versehentlich committet wurden.
Letzte Prüfung der Abhängigkeitssicherheit (5. Mai 2026, Version 1.3.0)
Wir haben eine Sicherheitsprüfung der Frontend-Abhängigkeiten abgeschlossen und die in dieser Runde gefundenen Hoch- und Mittelrisiko-Abhängigkeiten aktualisiert oder strenger versioniert.
Das aktuelle Ergebnis lautet: Critical 0 / High 0 / Moderate 0 / Low 0.
Der aktuelle Yarn-Audit-Bericht zeigt keine Abhängigkeits-Schwachstellen.
Nach den Abhängigkeitsanpassungen haben wir Installation, Linting, automatisierte Tests und Expo Doctor geprüft. Der verbleibende Hinweis von Expo Doctor ist eine Empfehlung zum Upgrade von Expo-SDK-Patch-Versionen und wurde nicht durch diese Sicherheitskorrektur eingeführt.
Prüfwerkzeug: Yarn Audit. Der Rohbericht kann heruntergeladen werden.
Letztes Ergebnis des Secret-Scannings (5. Mai 2026, Version 1.3.0)
Zusätzlich haben wir mit gitleaks die aktuell versionskontrollierten Quelldateien auf versehentlich committete Secrets geprüft.
Das aktuelle Ergebnis lautet: 0 findings.
Dieser Scan umfasste nur die aktuell von Git verfolgten Quelldateien. Git-Historie und lokal erzeugte Build-Dateien waren nicht enthalten.
Prüfwerkzeug: gitleaks. Der Rohbericht kann heruntergeladen werden.
Letzter Code-Sicherheitsscan (5. Mai 2026, Version 1.3.0)
Zusätzlich haben wir mit Semgrep einen statischen Sicherheitsscan auf den aktuell versionskontrollierten Frontend-Quelldateien durchgeführt.
Das aktuelle Ergebnis lautet: 0 findings.
Dieser Scan wurde nach einer Bereinigung einer reinen Typsyntax erneut ausgeführt. Im aktuellen Ergebnis gibt es weder Sicherheitsbefunde noch Parsing-Warnungen.
Prüfwerkzeug: Semgrep. Der Rohbericht kann heruntergeladen werden.
Letzte mobile Sicherheitsprüfung (5. Mai 2026, Version 1.3.0)
Wir haben mit MobSF eine statische Sicherheitsanalyse der iOS- und Android-Pakete von MapSpoto durchgeführt.
Das iOS-Ergebnis lautet: 64/100 (Low Risk), ohne High-Risk-Befunde. App Transport Security und Standortberechtigungen wurden erneut geprüft.
Das Android-Ergebnis lautet: 55/100 (Medium Risk). Die Android-Mindestversion wurde auf Android 10 (API 29) angehoben, und die Signaturprüfung war erfolgreich.
Zwei verbleibende statische Hinweise wurden geprüft und akzeptiert: Android WebView debugging wird in statischem Code der Drittanbieter-Bibliothek react-native-webview erkannt; der fachliche WebView der App setzt ausdrücklich webviewDebuggingEnabled={false}, und der Release-Build aktiviert kein android:debuggable. Daher wird dies als statischer Fehlalarm / akzeptiertes Risiko behandelt. iOS Debug Symbols werden weiterhin für das Haupt-Binary und das Hermes framework gemeldet; dies legt keine Nutzerdaten offen und erweitert keine Berechtigungen, kann Reverse Engineering aber erleichtern. Der Punkt ist als akzeptiertes Risiko dokumentiert, während wir die Build-Pipeline weiter verbessern.
Prüfwerkzeug: MobSF. Die Rohberichte können heruntergeladen werden.
Aktuelle Verbesserungsfelder
- Öffentliche Profilfelder weiter einschränken, um unnötige Offenlegung persönlicher Informationen zu reduzieren.
- Zu breite öffentliche Storage-Zugriffe entfernen, damit ganze Buckets nicht öffentlich aufgelistet werden können.
- Regeln zur Profilvollständigkeit vereinfachen, damit Kontaktdaten und ähnliche sensible Felder nicht als notwendige Profilsignale behandelt werden.
Umfang und Grenzen
Wir verbessern Sicherheitskonfigurationen und Produktlogik laufend, behaupten aber nicht, dass die App „absolut sicher“ ist.
Sicherheit ist ein fortlaufender Prozess. Wenn wir neue Probleme finden, werden wir sie weiter beheben und Regeln nachschärfen.
Zurück zur Datenschutzerklärung