Sicherheit bei ASOApp

Der größte Teil von ASOApp funktioniert ohne Konto, und das angebotene Konto ist kostenlos. Kartendaten erreichen unsere Server nie — das bezahlte PRO-Abo rechnet vollständig Stripe auf Stripes eigenen Seiten ab — und auf deinen Apple-Entwickleraccount hat hier nichts Zugriff. Das entfernt die meisten Risikokategorien, die ein SaaS-Tool sonst mitbringt. Diese Seite dokumentiert, was tatsächlich gespeichert wird, was es schützt und wo das Restrisiko liegt.

Was gespeichert wird und wo

Das Konto enthält eine E-Mail-Adresse und eine synchronisierte Kopie deines Arbeitsbereichs — keine Zahlungsdaten, kein persönliches Profil, keine Apple-Zugangsdaten. Passwörter werden mit Djangos Standard-Hasher gehasht, Sitzungen laufen über Cookies mit CSRF-Schutz, und wer sich mit Google anmeldet, gibt uns überhaupt kein Passwort. Nutzt du das Tool abgemeldet, existiert nichts davon für dich. Die vollständigen rechtlichen Angaben stehen in der Datenschutzerklärung.

Datenfluss

Wo der App Store es erlaubt, ruft dein Browser Apples öffentliche Endpunkte direkt auf — die Anfrage läuft gar nicht über unseren Server. Verhindert eine Cross-Origin-Beschränkung das, wird die Anfrage serverseitig vermittelt und das Ergebnis für alle zwischengespeichert.

Das heißt: Apple sieht Anfragen aus deinem Browser wie von jedem anderen Client. Und es heißt, dass wir vieles von dem, was du recherchierst, nie zu sehen bekommen.

Aktive Härtung

Konkrete, überprüfbare Maßnahmen statt Adjektive:

• Content Security Policy — default-src 'self', script-src 'self' (keine Inline-Skripte, kein Fremd-JavaScript), frame-ancestors 'none', base-uri 'self', form-action 'self'. Ausgehende Verbindungen sind auf die eigene Origin und itunes.apple.com beschränkt.
• Fast kein Fremd-JavaScript. Keine Analytics, keine Tag-Manager, keine Werbe-Pixel, keine CDN-Bibliotheken; Schriften sind selbst gehostet. Die einzige Ausnahme ist Googles Anmelde-Client, und der lädt nur, wenn du es im Cookie-Dialog erlaubst oder auf „Mit Google anmelden" klickst — nie bei einem bloßen Seitenaufruf. Die Inhaltsseiten hier laden gar keinen Fremdcode.
• Keine Tracking- oder Werbe-Cookies. Was wir setzen, steht mit Name, Zweck und Laufzeit in der Datenschutzerklärung: ein Session-Cookie für die Anmeldung, ein CSRF-Sicherheits-Cookie und ein Cookie, das deine Auswahl im Einwilligungsdialog merkt.
• HSTS mit einem Jahr max-age, includeSubDomains und Preload, in der Produktion.
• X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin.
• Secure-, HttpOnly- und SameSite=Lax-Cookies in der Produktion; CSRF-Schutz aktiv.
• Rate-Limiting auf API-Endpunkten, mit strengeren Limits beim Admin-Login.
• Canonical-Host-Weiterleitung, damit die Seite von genau einer Origin ausgeliefert wird.
• Ausgabe-Escaping auf jeder serverseitig gerenderten Seite, auch auf den nutzergenerierten Keyword-Seiten, die zusätzlich durch eine Schimpfwort-Blockliste, einen Link-/Domain-Filter und eine Qualitätsprüfung müssen, bevor sie indexierbar werden.
• X-Robots-Tag: noindex auf allen API-Pfaden und der Admin-Route.

Restrisiken, die wir nicht wegreden

• Local Storage ist nicht verschlüsselt. Wer Zugriff auf dein entsperrtes Gerät oder Browserprofil hat, kann deine Keyword-Liste lesen. Das sind Wettbewerbsrecherchen, keine Zugangsdaten — geheim sind sie trotzdem nicht.
• Websitedaten löschen zerstört deine Historie, wenn du kein Konto hast — es gibt kein Backup, das ist der Preis der Local-First-Speicherung. Genau dafür gibt es das kostenlose Konto: Es hält eine serverseitige Kopie, zu der du dich zurückmelden kannst.
• Der Server-Cache ist gemeinsam. Von dir erzeugte Keyword-Bewertungen werden Teil eines gemeinsamen Caches und können in den öffentlichen Keyword-Reports erscheinen, wenn sie Sicherheits- und Qualitätsprüfung bestehen. Recherchiere kein Keyword, das du für vertraulich hältst.
• Ein Maintainer. Die Reaktionszeit auf Patches hängt an der Verfügbarkeit einer Person. Das ist ein echtes Betriebsrisiko, das du einkalkulieren solltest.

Sicherheitslücken melden

Schreib an hello@jungspree.com mit Reproduktionsschritten und, falls vorhanden, einem Proof of Concept. Es gibt kein Bug-Bounty — das ist ein unfinanziertes Nebenprojekt — aber Meldungen werden ernst genommen und auf Wunsch genannt.

Bitte lass angemessene Zeit zur Behebung, bevor du ein Problem öffentlich machst.

Weiterlesen

• Datenschutzerklärung
• Datenmethodik
• Über ASOApp
• Drittanbieter-Lizenzen