Skip to content

Trust · Security

Our controls, and the ones we do not have yet.

Security pages usually list only the wins. This one lists the gaps too, because a small product that pretends to have enterprise controls is a worse bet than one that tells you exactly where it stands.

Effective
Sep 1, 2026
Last updated
Sep 1, 2026
Status
Unreviewed draft

01Clause

The shape of the system

NicheScout is a Next.js application. Rendering, server actions, scheduled ingestion and the AI pipeline all run server-side on our hosting provider. Persistent data lives in a managed PostgreSQL database at Supabase. There is no second copy of your data anywhere else, and nothing is stored on developer machines.

Every third party that touches data is listed in clause 7 of the privacy policy. That list is the complete answer to “who else can see this”.

02Clause

Authentication

  • Email and password sign-in is handled by Supabase Auth. Passwords are salted and hashed by Supabase; our code never receives a plaintext password.
  • Google sign-in uses OAuth 2.0. We receive an email address, display name and avatar URL — never a Google password.
  • Sessions are carried in httpOnly, secure, SameSite cookies that JavaScript on the page cannot read.
  • Every gate on the server revalidates the session against the auth server rather than trusting the cookie's contents, because a decoded-only check can be forged by the client.
  • Password reset links are single-use and short-lived, and the reset routes are excluded from search indexing so a token can never leak through a crawler.

03Clause

Isolation between workspaces

Authorisation is enforced in the database, not in application code. Every table carrying customer data has PostgreSQL row-level security enabled, and every policy resolves through workspace membership. A query that forgets a filter returns nothing rather than someone else’s rows.

The browser only ever holds the anonymous Supabase key, which is subject to those same policies. The service-role key, which bypasses them, exists solely in server-side environment variables and is used only by scheduled jobs and the Stripe webhook. Environment access is validated at startup so a misconfigured deployment fails loudly instead of running with a missing key.

04Clause

Encryption

In transit
TLS 1.2 or better on every connection, with HTTP Strict Transport Security so a browser that has seen the site once will refuse to downgrade.
At rest
AES-256 volume encryption on the managed database and its backups, provided by Supabase on AWS.
Between services
All calls to Supabase, Stripe, Anthropic, SerpAPI and Resend go over TLS with server certificate verification.

05Clause

Secrets and scheduled jobs

API keys live in the hosting platform’s encrypted environment store. None of them are prefixed for client exposure, so the bundler cannot leak one into a browser bundle even by accident; server-only modules additionally throw if imported from the client.

The two scheduled endpoints — tracker polling and AI analysis — hold the service-role key and spend money on model calls, so both authenticate before doing anything:

  • A bearer token must match a 32-byte CRON_SECRET.
  • The comparison is constant-time over SHA-256 digests, so it leaks neither the secret nor its length through timing.
  • A missing or unset secret is a hard failure, not an open door — the job refuses to run.

06Clause

Payments

Card details are entered on Stripe’s own hosted checkout and never reach our servers, which keeps us within the narrowest PCI DSS scope (SAQ A). We store only a Stripe customer id and the resulting subscription state.

Incoming Stripe webhooks are verified against the endpoint signing secret before any plan change is written, so a forged webhook cannot upgrade an account.

07Clause

Browser hardening

Every response carries a security header set: a Content Security Policy that restricts scripts, styles, frames and network destinations to the origins we actually use; HSTS with a two-year max-age; X-Content-Type-Options: nosniff; a strict referrer policy; a Permissions-Policy that denies camera, microphone, geolocation and interest-based ad APIs outright; and frame-ancestors ‘none’, so the app cannot be framed for clickjacking.

Structured data and any other markup we generate from stored text is escaped before it is written into the page, so a review body cannot close a tag and inject script.

08Clause

Backups and availability

  • The database is backed up daily by Supabase, with point-in-time recovery on paid database tiers.
  • Backups inherit at-rest encryption and are retained for 7 days, then rotated out.
  • Deleted data is removed from backups as those backups expire — within 35 days of the live deletion.
  • The application layer is stateless and redeployable from source at any commit.

09Clause

What we have not done yet

Stated plainly, so nobody buys on an assumption we have not earned:

  • No SOC 2 or ISO 27001. No audit has been performed and none is in progress.
  • No third-party penetration test. Security so far is design review and code review by the team.
  • No two-factor authentication. Supabase supports it; we have not shipped the enrolment flow.
  • No customer-visible audit log. You cannot yet see who in your workspace looked at what.
  • No bug bounty. Disclosure is welcome and we will credit you, but we cannot pay yet.
  • No signed DPA available for self-service. If you need one, email us and we will handle it manually.

If you need those

Tell us which control is blocking you at security@nichescout.app. Knowing what real buyers are actually blocked on is how this list gets shorter.

10Clause

Reporting a vulnerability

How to report

Email security@nichescout.app with enough detail to reproduce. We acknowledge within 2 business days, give you an assessment within 10, and aim to fix critical issues within 30 days.

Safe harbour

If you research in good faith, stay within your own test account, stop at the first proof of a finding, do not access, modify or exfiltrate anyone else’s data, do not degrade the service, and give us reasonable time to fix before publishing, we will not pursue legal action and will treat your work as authorised.

Out of scope

Volumetric denial of service, social engineering of our staff or vendors, physical attacks, spam or rate-limit findings without demonstrated impact, and reports generated solely by an automated scanner with no verification.

11Clause

If something goes wrong

On confirming a breach of personal data we will notify the relevant supervisory authority within 72 hours of becoming aware, and notify affected customers without undue delay where the risk to them is high. Notifications will say what happened, what data was involved, what we have done, and what you should do — including the parts we do not yet know.

Status and incident history will be published as the service matures; until then, incident communication is by email to account holders.