Security & Trust

Overview

Baby Recall Tracker ("we") handles two categories of sensitive data: the account profile information you provide directly, and email-receipt data you authorize us to read so we can identify products to monitor for recalls. This page describes the controls we operate to protect that data, the sub-processors we rely on, and how to report security issues. For the full legal terms of how we collect and use data, see our Privacy Policy, especially Section 19 (Google API Services User Data Policy & Limited Use).

Encryption

• In transit: all traffic to BabyRecallTracker.com and its API routes is served over HTTPS (TLS 1.2 or higher). Plain-HTTP requests are automatically upgraded via theStrict-Transport-Securityheader issued by our hosting provider, and the application Content Security Policy emits anupgrade-insecure-requestsdirective.
• At rest: all OAuth refresh and access tokens for connected email accounts (Google Gmail, Microsoft Outlook) are stored encrypted with AES-256-GCM using a 32-byte server-side key that is held outside the application database. The ciphertext is bound to a per-token initialization vector and an authentication tag, so tampering is detectable on read. The underlying database storage on our managed Postgres provider is additionally encrypted at rest by the provider.
• Backups: automated point-in-time backups operated by our Postgres provider are encrypted at rest and replicated within the United States.

Authentication & Authorization

• User authentication is handled via NextAuth with Google OAuth as the primary identity provider. We do not store or process raw user passwords for the Google sign-in flow.
• Session tokens are signed with NEXTAUTH_SECRET and validated on every authenticated request by our HTTP middleware before the request reaches application code.
• Authenticated dashboard, account, recall-feed, review, and admin routes are gated at the network edge: unauthenticated requests are redirected to the sign-in page before any user-scoped data is read.
• Privileged admin endpoints additionally require the user to be on an explicit allowlist; admin bypass behavior in development is gated behind the ALLOW_LOCAL_ADMIN_ACCESS environment variable and is not enabled in production builds.

Application Security Controls

• Content Security Policy: a strict CSP is set at the framework level for every response, includingdefault-src 'self',frame-ancestors 'none', andobject-src 'none'. Outbound connections are restricted to the providers we explicitly integrate with (Supabase, Stripe, Google APIs, Microsoft Graph, Vercel observability).
• Other security headers:X-Frame-Options: DENY,X-Content-Type-Options: nosniff,Referrer-Policy: strict-origin-when-cross-origin, and aPermissions-Policythat disables camera, microphone, and geolocation by default.
• Rate limiting: sensitive write endpoints (auth, contact form, barcode-lookup, account mutations) enforce per-IP and per-user rate limits to blunt brute-force and abuse traffic.
• Input handling: route handlers validate request bodies, normalize external inputs, and use parameterized Postgres queries via the Supabase client. We do not construct SQL by string concatenation.
• Idempotency: background jobs and webhook handlers enforce idempotency keys so a replayed request cannot duplicate billing or scan side effects.

Hosting & Infrastructure

• Application hosting: Vercel (us-east region by default). Production deployments are atomic and immutable; rollbacks are instant.
• Database: Supabase managed Postgres, hosted in the United States. Database access is restricted to the application service role; the anonymous public role has no read or write access to any user-scoped table.
• Background workers: Inngest for durable scheduled jobs (daily recall ingestion, per-user scans, security purges). Inngest connects to the application via signed webhook events.
• USDA daily refresh: a small GitHub Actions workflow performs the FSIS USDA fetch daily, then signals our application via a signed Inngest event. This isolates the one upstream source whose WAF blocks our cloud egress IP range so a single source outage does not affect the rest of the recall pipeline.
• Secrets: environment-scoped secrets (API keys, OAuth client secrets, the AES token-encryption key, webhook signing keys) are stored in the Vercel environment variable store and are not committed to source control. CI runs gitleaks and detect-secrets on every pull request to prevent accidental check-in.

Sub-processors

The following third parties process data on our behalf to operate the Service:

• Vercel, Inc. — application hosting, edge functions, build and deployment, analytics. Privacy: vercel.com/legal/privacy-policy.
• Supabase, Inc. — managed Postgres database, object storage for user-uploaded photos, authentication helpers. Privacy: supabase.com/privacy.
• Inngest, Inc. — durable background job scheduling and event-driven workflow execution.
• Google LLC — Gmail API access for purchase-receipt scanning (only for users who connect a Google account); Google OAuth for sign-in.
• Microsoft Corporation — Microsoft Graph / Outlook API access for purchase-receipt scanning (only for users who connect an Outlook account).
• Stripe, Inc. — subscription billing and payment processing. Card data is handled directly by Stripe; we never store card numbers.
• Brevo (Sendinblue) — transactional email delivery (recall digests, account notifications).
• OpenAI / Anthropic — large-language-model inference for purchase-receipt extraction, recall-match adjudication, and product-photo detail extraction. Inputs are sent only on a per-request basis and are not used by the providers to train their models when sent through the API tier we use.
• GitHub, Inc. — source code hosting, CI/CD, security scanning (gitleaks, detect-secrets, semgrep, optional CodeQL).

Continuous Security Testing

Every pull request to themainbranch is automatically scanned by the following gates before it can be merged:

• npm-audit — production dependency vulnerability scan; builds fail on any high or critical advisory.
• Semgrep SAST — static analysis using thep/security-auditandp/owasp-top-tenrule sets.
• gitleaks and detect-secrets — two independent secret scanners run on every commit diff to prevent accidental check-in of API keys, tokens, or credentials.
• workflow-action-guard — ensures every GitHub Actions workflow we ship pins its actions to immutable references and never exposes untrusted user input directly into shell scripts.
• CodeQL (optional) — deeper data-flow analysis when enabled at the repository level.
• Weekly scheduled scan — the security-gates workflow also runs on a weekly cron so vulnerabilities introduced after merge are surfaced quickly.

In addition, we plan to undergo an annual third-party security assessment under Google's Cloud Application Security Assessment (CASA) program for as long as we hold any restricted Google API scope.

ESOF Shield Verified

Baby Recall Tracker displays this TAC Security ESOF Shield badge after completing the applicable security validation process.

Data Deletion & Portability

• You can delete your entire account from the Account page. Deletion immediately removes your user record, all tracked items, all recall match history, all email-connection records (including stored OAuth tokens), all ingestion audit data, all uploaded product photos, and all notification preferences from our production database. Stripe billing is automatically cancelled if you have an active subscription.
• You can disconnect any individual email account from the Account page at any time without deleting your overall Baby Recall Tracker account. Disconnecting immediately deletes the stored OAuth tokens for that account and revokes them with the upstream provider where supported.
• Backup copies of deleted data are purged on the next backup-rotation cycle (typically within 30 days).
• For the full retention schedule, see Section 6 of the Privacy Policy.

Reporting a Vulnerability

If you believe you have found a security vulnerability in Baby Recall Tracker, please report it to contact@babyrecalltracker.com with the subject line "Security report". Please include:

• A description of the issue and its potential impact.
• Steps to reproduce, including any proof-of-concept material.
• Your contact information so we can follow up.

We aim to acknowledge reports within 5 business days and to provide a remediation timeline within 14 business days. Reports are triaged in order of severity. We are a small team and operate this disclosure program in good faith; please give us reasonable time to investigate before any public disclosure.

Safe Harbor

We will not pursue legal action or law-enforcement referral against researchers who:

• Make a good-faith effort to avoid privacy violations, destruction of data, and interruption or degradation of the Service while testing.
• Test only against accounts you own or have explicit written permission from the account holder to test.
• Do not attempt to extract data belonging to other users beyond what is strictly necessary to demonstrate the issue.
• Do not perform denial-of-service or resource-exhaustion testing against production.
• Comply with applicable law and these guidelines.

Contact

For security questions or to report a vulnerability: contact@babyrecalltracker.com.

For all other privacy or data-rights requests, see the contact information in Section 16 of the Privacy Policy.