Security

If you think you have found a security vulnerability in TAPPI, tell us at hello@thetappi.com. Reports from security researchers, clients and anyone else are welcome. Write in English or Spanish.

Please include:

• what the issue is and where — URL, API endpoint, app screen or feature;
• how to reproduce it, with a proof of concept if you have one;
• what an attacker could do with it;
• your name or handle if you would like credit, and how to reach you.

What we will do:

• acknowledge your report within 3 business days;
• tell you whether we can reproduce it and how serious we think it is, within 10 business days;
• keep you updated while we fix it, and tell you when it is fixed;
• credit you publicly once it is fixed, if you want that.

We do not run a paid bug bounty.

If you act in good faith and follow the guidelines below, we will treat your research as authorised, we will not take legal action against you, and we will not report you to law enforcement for it. If someone else takes action against you over research that followed this policy, we will say publicly that your work was authorised by us.

• Use only your own accounts or test accounts. Do not access, change or delete anyone else's data. If you reach someone else's data by accident, stop, do not keep or share it, and tell us.
• Do the minimum needed to show the issue is real.
• No denial-of-service or load testing, no spam, and no automated scanners that generate heavy traffic.
• No social engineering or phishing against our team, our clients or their customers.
• Do not interfere with chips, QR codes or cards at a venue, and do not test top-ups, gift cards or balances with real money or a real customer's card.
• Give us time. Please do not disclose publicly until we have fixed it or agreed a date — we ask for up to 90 days.
• Follow the law.

• thetappi.com and its sub-domains;
• the TAPPI dashboard, the partner portal, and the public customer pages — loyalty sign-up, review, top-up, gift card and shared card;
• the TAPPI public API and outbound webhooks;
• the TAPPI Business mobile app;
• Apple and Google Wallet passes issued by TAPPI.

Out of scope: services run by our providers — Stripe, Supabase, Vercel, Google, Apple — which should go to them; reports from automated scanners with no demonstrated impact; and physical attacks on devices or premises.

Everything in this list is in production today.

• Encryption in transit (HTTPS/TLS) across the website, apps and APIs, with HSTS. Encryption at rest by our database host.
• Tenant isolation in the database. Row-level security on every multi-tenant table, with automated cross-tenant tests in CI. The tables that hold money — balances, ledgers, promotions, reward codes — are read-only to member sessions, and every write goes through a reviewed server-side path.
• Hashed API keys and passwords. We never store either in a form we could read back.
• Two-factor sign-in. Every login except a staff login can add an authenticator app in Settings › Security, and from then on the dashboard asks for its code at every sign-in. The owner can also require one of every owner, admin and location manager.
• Support sign-in is logged. To set an account up or fix a reported problem, a TAPPI operator (behind their own two-factor) can sign in as the account owner. Each sign-in is written to our admin log and to your activity log with the reason, and it is refused once the owner has two-factor switched on.
• Rate limiting on public endpoints, which fails closed, and SSRF protection on outbound requests such as webhook delivery.
• Signed webhooks. Inbound webhooks are signature-verified; outbound deliveries are signed, retried and idempotent.
• Least privilege on our side. Our internal support tooling requires multi-factor authentication with a step-up check on every page that shows data, is read-only, and never signs us in as you. Every view of a business account is written to an append-only audit ledger.
• Fraud monitoring on prepaid balance and gift cards, with automatic freezes and alerting.
• Security response headers — HSTS, frame protection against clickjacking, MIME-sniffing protection, a strict referrer policy, a permissions policy that switches off every browser capability except the camera used by the QR scanner, and a content security policy covering base-URI and plugin injection. The CSP does not yet restrict script sources; that needs nonce plumbing and is on the list below.
• Code review and automated tests before release, including a SQL test suite run against a branch database before any migration reaches production.

Publishing this is the point. If a vendor's security page has no such section, ask them for one.

• Two-factor does not cover staff logins. A shop-floor login shared at the till cannot hold one person's authenticator, so staff sign in with the login and password you set, and the switch applies to owners, admins and location managers only. Give each staff member only the permissions they need.
• Changes made in a support sign-in carry the owner's name. The activity log shows that TAPPI support signed in and when, but each change made in that session is recorded under the owner's login.
• The database does not check two-factor yet. The dashboard and our API ask for the code, but the database's own access rules do not yet, so a leaked password still needs changing straight away.
• The TAPPI Business phone app does not ask for the code yet. It is the app used to set up chips, and it signs in with a password alone.
• No independent penetration test. We have done our own threat modelling and fixed what it found; nobody external has tried to break in for money.
• No certification of our own. We hold no ISO 27001 and no SOC 2. Our infrastructure providers hold theirs; that is their certification, not ours, and we will not present it as though it were.
• Some third-party tokens are stored unencrypted at rest beyond the database's own encryption — the Google Business Profile connection in particular. Encrypting them at the application layer is on the list.
• Deployed NFC chips are not write-protected. The per-chip password mechanism is built but not switched on, so a chip in a venue can be rewritten by someone with an NFC phone and physical access to it. A rewritten chip points elsewhere; it cannot read your data or reach your account.
• The content security policy does not yet restrict script sources. It blocks base-URI and plugin injection and framing, which is worth having, but a nonce-based script-src is the part that stops an injected script and we have not built it.
• No contractual uptime guarantee. We publish a status page, but we do not yet offer an SLA.

If a breach affects personal data we process for a business, we tell that business within 48 hours of becoming aware — see clause 7 of the data processing agreement. Where we are the controller, we tell the ICO within 72 hours if required, and tell the people affected without undue delay where the law requires it.

We do not publish a "no breaches to date" claim. It is unverifiable, it ages badly, and it gives a reader nothing they can act on.

• Add an authenticator app to your login in Settings › Security, and switch on the requirement so every owner and manager needs one too.
• Use a unique password and a password manager.
• Give each staff member their own login. Remove access the day someone leaves.
• Grant the least permission that does the job. Balance adjustments and billing are separate permissions for a reason.
• Check your activity log. It is there to be read.
• We will never ask for your password, and never ask you to move money by email.