Effective date: 14 September 2026
You are connecting your Amazon seller account — your livelihood — to software written by someone else. This document says what protects it. Everything here describes what the system does today, not what we intend to build.
NASST does not read your order data.
Amazon's API can return buyer names, delivery addresses and order contents. NASST does not ask for them. The feature that could was removed before launch.
This was a deliberate trade: some useful functionality given up in exchange for never holding data whose loss would harm your customers. It also keeps us outside the heaviest tier of Amazon's Data Protection Policy, which applies to applications handling Personally Identifiable Information.
If we ever add order features, this document will change first.
Your Amazon refresh token is the key to your seller account. It is:
serialises your connection for display cannot include it
AES-256-GCM is authenticated encryption: a token that has been altered fails to decrypt rather than being used. Tampering produces an error, not a silent compromise.
You can revoke our access from Amazon Seller Central at any time, independently of us. We think you should know that without having to ask.
Added 28 August 2026. If you connect your own SerpApi account for live price comparison, that key is treated exactly like your Amazon token:
not for you, not for us. Once saved it can be replaced or removed, never read. The only part ever shown is its last four characters, so you can tell which key is stored
redacted before anything reaches disk, and the key is sent to SerpApi in a query string that the error paths deliberately never carry
Amazon's Data Protection Policy requires programmatic credentials "including API keys" to be encrypted at rest. That obligation is not limited to Amazon's own credentials, which is why this key is held to the same standard.
Never stored. We keep a scrypt hash with a random per-account salt and deliberately expensive parameters.
Scrypt is memory-hard, which is the property that matters: it resists the graphics hardware that makes brute-forcing cheap. Every account has its own salt, so cracking one tells an attacker nothing about any other.
We enforce password rules at sign-up and prevent re-use of a previous password.
Available on every account, using an authenticator app (TOTP).
We deliberately do not offer SMS codes. SMS can be intercepted by SIM-swap — persuading a mobile network to move a number to an attacker's SIM — which is a routine attack against accounts holding money.
Recovery codes are issued so that losing a phone does not lock you out permanently. Each works once.
Sessions are held on our server, not as a self-contained token in your browser. That choice has one purpose: a session can be destroyed the instant an account is suspected of being compromised. A self-contained token cannot be withdrawn before it expires — which is exactly the moment you need it withdrawn.
HttpOnly, SameSite=Lax, and Secure over HTTPSdestroys the old one, so a token observed during sign-in cannot become a working session
Multi-tenant systems fail in one characteristic way: a request that loses track of who it belongs to falls back to a default, and one customer sees another's data.
NASST is built so that a request which cannot be attributed to a specific signed-in customer fails. There is no default account to fall back to. Every data store is keyed by owner, and the identity travels with the request rather than being passed by hand at each layer — so a new feature cannot accidentally omit it.
We test this. It is checked by an automated suite that runs on every change.
Every Amazon API call is limited per connected seller, at 80% of the rate Amazon publishes, with a ceiling on the highest rate we will believe even if Amazon reports a higher one.
Two reasons. It keeps us inside Amazon's limits, which protects our access and therefore the service. And it is per seller, so one customer's bulk job cannot slow another customer's dashboard.
Logs record failures, not activity. Before any line is written, anything matching a credential — tokens, keys, passwords, authorisation headers — is replaced with a redaction marker. The rules are deliberately broad: over-redacting a debug log is much cheaper than writing a live token into a file.
No credential is hardcoded. All are supplied by configuration, and credential files are written with owner-only permissions.
The web server serves an explicit list of directories. Nothing above them is reachable — source code, configuration and data files are not served at all.
This is stricter than the usual arrangement, and deliberately so: exposing a new directory has to be a deliberate act rather than something that happens by default.
We maintain an incident response plan. If a breach affects your data we will tell you without undue delay and within 24 hours of becoming aware of it, with what we know, what we are doing, and what you should do.
24 hours is faster than the 72 hours the UK GDPR gives us for notifying the regulator. Amazon requires 24 hours, and we saw no reason to give customers less than we give Amazon.
The application ships with an automated test suite covering authentication, customer separation, rate limiting and data handling, which runs on every change.
We also run an internal security self-check that inspects the running system — not the documentation — and reports where it falls short. It is designed to fail loudly rather than reassure.
Honesty is worth more here than marketing:
What we do claim is that the controls above are real, implemented, and tested.
Email info@nasst.co.uk.
We will acknowledge within 2 business days and keep you updated. We will not pursue legal action over a good-faith report where you did not access another customer's data, did not degrade the service, and gave us reasonable time to fix it before disclosure.
Please do not test against Amazon's endpoints. That is our API access at risk, and losing it would end the service for every customer.