Does ASOApp store my data on a server?

Your tracked apps, keyword lists and workspace settings are stored in your browser's local storage. If you have an account, a copy is also synced to it so it survives a cleared cache. The server keeps a shared cache of public App Store data (keyword scores, app metadata, observed rankings) that is not tied to any person.

Does ASOApp need my Apple or App Store Connect credentials?

No, and it never asks for them. There is no App Store Connect integration, so there is nothing to authorize and nothing to revoke.

What happens if I clear my browser data?

Without an account, your tracked apps and keyword lists are gone — that is the direct consequence of local-first storage, and there is no server-side copy to restore from. With a (free, optional) account your workspace is also stored server-side, and signing in restores it.

How do I report a security issue?

Email hello@jungspree.com with steps to reproduce. It is a one-person project, so expect a human reply rather than a triage system, and please give reasonable time before public disclosure.

Security at ASOApp

Most of ASOApp works without an account, and the account it does offer is free. Card data never reaches our servers — the paid PRO plan is billed entirely by Stripe, on Stripe's own pages — and nothing here has access to your Apple developer account. That removes most of the categories of risk a SaaS tool normally carries. This page documents what is actually stored, what protects it, and where the residual risk sits.

What is stored, and where

Data	Where it lives	Tied to you?
Your tracked apps and keyword lists	Your browser's local storage, plus a synced copy in your account if you have one	Your device; your account if signed in
Workspace and theme preferences	Your browser's local storage	Only on your device
Keyword scores, app metadata, observed rankings	Server-side cache	No — shared public App Store data
Account email address, if you create one	Server	Yes — deletable at any time from account settings
Star rating you submit	Server, with a hashed IP	Pseudonymous, one vote per visitor
Server request logs	Server, short-lived	Standard web-server logs

The account holds an email address and a synced copy of your workspace — no payment details, no personal profile, no Apple credentials. Passwords are hashed by Django's default hasher, sessions are cookie-based and CSRF-protected, and signing in with Google means we never see a password at all. If you use the tool signed out, none of that exists for you. The full legal detail is in the privacy policy.

Data flow

Where the App Store allows it, your browser calls Apple's public endpoints directly — the request does not pass through our server at all. When a cross-origin restriction prevents that, the request is proxied server-side and the result is cached for everyone.

This means Apple sees requests from your browser, as it would from any client. It also means much of what you research is never visible to us.

Hardening in place

Concrete, verifiable measures rather than adjectives:

Content Security Policy — default-src 'self', script-src 'self' (no inline scripts, no third-party JS), frame-ancestors 'none', base-uri 'self', form-action 'self'. Outbound connections are restricted to our own origin and itunes.apple.com.
Almost no third-party JavaScript. No analytics, no tag managers, no ad pixels, no CDN-hosted libraries; fonts are self-hosted. The single exception is Google's sign-in client, and it loads only if you allow it in the cookie dialog or click a "Sign in with Google" button — never on a plain page view. The content pages here load no third-party code at all.
No tracking or advertising cookies. What we set is listed by name, purpose and lifetime in the privacy policy: a login session cookie, a CSRF security cookie, and one cookie remembering your choice in the consent dialog.
HSTS with a one-year max-age, includeSubDomains and preload, in production.
X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin.
Secure, HttpOnly, SameSite=Lax cookies in production; CSRF protection enabled.
Rate limiting on API endpoints, with stricter limits on the admin login.
Canonical host redirect so the site is served from one origin.
Output escaping on every server-rendered page, including the user-generated keyword pages, which are additionally filtered through a profanity blocklist, a link/domain guard and a quality gate before they can be indexed.
X-Robots-Tag: noindex on all API paths and the admin route.

Residual risks we are not going to pretend away

Local storage is not encrypted. Anyone with access to your unlocked device or browser profile can read your tracked keyword list. It is competitive research, not credentials, but it is not secret.
Clearing site data destroys your history if you have no account — there is no backup, and that is the cost of local-first storage. A free account exists precisely to remove this risk: it keeps a server-side copy you can sign back in to.
The server cache is shared. Keyword scores you generate become part of a common cache and may appear in the public keyword reports if they pass the safety and quality gates. Do not research a keyword you consider confidential.
One maintainer. Patch response depends on one person's availability. That is a real operational risk and you should weigh it.

Reporting a vulnerability

Email hello@jungspree.com with reproduction steps and, if you have one, a proof of concept. There is no bug bounty — this is an unfunded side project — but reports are taken seriously and credited if you would like.

Please allow reasonable time to fix an issue before disclosing it publicly.

Track your own app — free to start

See where your app ranks for keywords like this, across countries and over time. A new account starts a 7-day PRO trial — cancel before it ends and you pay nothing.

Add a single app — or paste a developer link to track all of their apps at once.