Security

Passwords are hashed with scrypt, using a fresh 16-byte random salt per account and a 64-byte derived key. What the database holds is scrypt$salt$hash — never the password, and never anything that can be turned back into it. Verification recomputes the hash and compares it in constant time, so a wrong password cannot be narrowed down by timing it.

Passwords must be at least 8 characters. There is no upper-case-digit-symbol rule, because those rules push people towards shorter, more predictable passwords than a length floor does.

One cookie — aw_session — after you sign in. It holds a signed body (HMAC-SHA256 over the payload with a server-side secret) and expires after 30 days. It is HttpOnly, so page scripts cannot read it, and SameSite=Lax, so another site cannot make your browser act on your behalf.

Changing SESSION_SECRET invalidates every session at once. That is the emergency lever if a server is ever compromised.

An API key is 32 bytes from a cryptographic random source, prefixed with aw_. It is shown to you exactly once, in the response that creates it. What we store is a SHA-256 hash; the plaintext is never written to the database, never logged, and never included in an analytics event — events record only the first ten characters, which is enough to tell two keys apart in an audit and useless for authenticating.

We store a plain hash rather than scrypt here on purpose. The key is already 32 random bytes, so there is no dictionary to attack, and the check runs on every API request, where scrypt would be a denial-of-service lever pointed at ourselves.

Keys are accepted only as Authorization: Bearer …. The bare key is refused, because every system that logs request headers would then be logging a credential. You can revoke a key at any time from the API page, and revocation works even if your plan has since lapsed — a downgraded account holding a key that still authenticates should be able to kill it.

Every project, scan and report is read through its owner, not by primary key alone. Ask for a scan id that belongs to somebody else and you get 404, not 403. The difference matters: a 403 confirms the id exists, which turns the endpoint into a tool for enumerating other people's scans.

Card details never reach this server. Paddle is the merchant of record: they take the payment, handle tax, and hold the billing details under their own security programme. We keep only the customer and subscription identifiers we need to know which plan to grant. Not even the card's last four digits are stored here.

Paddle calls us back when a payment succeeds. Those callbacks are verified by signature and timestamp before anything is stored — a request with a bad signature, or one replayed after its timestamp has gone stale, is rejected. An unverified handler that grants a plan is a way to hand out the product for free.

Measuring AI answers means asking an AI. When a scan runs, the questions in it are sent to the model providers being measured — currently DeepSeek and Moonshot (Kimi) — so that they can answer. The domain and brand name you are researching are part of those questions by nature; there is no way to run this measurement without that.

That is the full list of places your project data goes, and it is the same list on our privacy page: the model providers, Paddle for billing, and the host the database runs on. We do not use your projects to train anything.

There is no third-party analytics script on this site — no Google Analytics, no pixel, no session recorder. Usage events (a scan started, a checkout opened) are written to our own database, which means they are covered by the same deletion rules as everything else and are not sent to a network of other companies.

The only cookie we set is the session cookie described above. It is not used for advertising, and it does not follow you to other sites.

The site is HTTPS only. Plain HTTP and the www hostname both redirect permanently to the canonical address, so credentials cannot be typed into an unencrypted copy of the page. HSTS is enabled with a one-year lifetime, which tells browsers to refuse the plain-HTTP version from now on.

A Content-Security-Policy is served that only permits scripts, styles and frames from this origin plus Paddle's checkout domains, with object-src 'none' and frame-ancestors restricting who may embed us. Responses also carry X-Frame-Options: DENY, X-Content-Type-Options: nosniff and a restrictive Referrer-Policy.

Stated plainly because you would otherwise have to guess: Moss Agents is run by one developer, and that person can read the production database. That means your projects, reports and the questions you have asked are visible to the operator, in the same way they are visible to you.

There is no separate "support access" mode, because there is no team to grant it to. What we will not do is read your projects out of curiosity, sell them, or publish them — and if that level of assurance is not enough for the data you are about to enter, this is the moment to decide that, not after you have typed it in.

Questions about this page, or about your data? Write to mossgame@163.com. We answer from a monitored inbox, and billing questions are answered by Shiliang.

Tell us what you found and how to reproduce it. There is no bug bounty — this is a one-person product with no revenue yet, and pretending otherwise would be worse than saying no — but we will confirm what you send, fix it, and tell you when it is fixed.

This list is shorter than it should be, and it is the honest half of the page. Everything here is a real gap, not a hedge.

• No two-factor authentication. A password protects your account and nothing else does. If you need 2FA today, this is not the right product yet.
• No off-site backups. The database lives on one server. That is a single point of failure we have not yet paid to remove.
• One API key per account, with no scopes. A key can read every scan your account owns. Per-key permissions are not implemented.
• No audit log. You cannot see a history of sign-ins or key usage from the dashboard today.
• No independent certification. No SOC 2, no ISO 27001, no penetration test report. What you can do instead is read the code-level claims on this page and hold us to them.
• Our Content-Security-Policy still allows inline and eval scripts. That is a genuine weakening of the policy's value, and tightening it to nonce-based script loading is on the roadmap.