Security & Responsible Disclosure

How we protect customer data

This section answers the questions a buyer's security team typically asks before a contract is signed: who can see what inside an account, how one customer's data is kept from another's, what account-security controls exist, what our recovery posture is, what our availability commitment is, how API access is scoped, and what compliance certifications we hold today. Where we do not yet have something, we say so plainly below rather than imply it.

Roles and permissions

Every user in an organization holds one of six roles, each a strict superset of the one below it. Role checks run on the backend on every request; a role that cannot see a page also cannot call the API behind it.

An organization's owner and any team member invited at a given role are held to exactly that role's ceiling on every request; there is no client-side-only gate that a lower-privileged user could bypass by calling the API directly.

Tenant isolation

Customer data is isolated at two independent layers. The application filters every query by organization. Underneath that, the database itself enforces the same boundary through PostgreSQL row-level security (RLS): request-serving database connections carry no privilege to read or write a row outside the caller's organization, regardless of what the application code does. A separate, privilege-elevated connection pool exists only for background jobs that have no logged-in user to scope to (nightly syncs, scheduled recalculations); those jobs enforce organization scope in their own code rather than through the database policy, and are not reachable from a customer request.

This two-layer design is defense in depth: a mistake in application code is not sufficient on its own to expose one customer's data to another, because the database enforces the boundary independently. We run quarterly penetration tests specifically targeting this boundary, and a confirmed cross-tenant data access finding is treated as our highest-severity vulnerability class, with a 7-day patch target (see Disclosure timeline below).

Account security

Sign-in is handled through Google's identity infrastructure (Firebase Authentication), by email and password or by signing in with a Google account.

Single sign-onis available today for customers using Microsoft Entra ID (Azure AD) or Okta as their identity provider. SSO sign-in is scoped to a customer's verified email domain, and new users are only provisioned into an organization on their first SSO sign-in if they already hold a pending invitation to that organization; SSO alone does not create account access.

Multi-factor authentication is not yet offered as a setting inside ReplenishRadar for email and password or Google sign-in. Customers signing in through Azure AD or Okta SSO get whatever multi-factor policy their own identity provider enforces, since we hand authentication to that provider entirely. We do not offer SCIM-based automated user provisioning or deprovisioning today; team membership is managed by invitation inside the app.

Recovery

Our database takes automated daily backups with point-in-time recovery, stored in multi-region storage separate from the primary database. We run periodic restore drills against a live clone of the production database to confirm the backups are actually restorable and that tenant-isolation policies survive the restore, not just that the backup job completed. For the most common recovery scenarios (application rollback, database instance restart, accidental data deletion) our internal recovery objectives are measured in minutes, backed by drill evidence rather than an untested target.

Availability

We do not currently publish a public status page and do not offer a contractual uptime SLA. We are a single-region deployment on Google Cloud infrastructure. If uptime history or an SLA is a requirement for your evaluation, ask us directly and we will tell you plainly where we stand.

API and agent key security

API keys are scoped, not all-or-nothing. Each key is created with an explicit read or write scope, and a write-scope key additionally requires selecting the specific write capabilities and tool groups it is allowed to use; a key cannot be granted more than what its organization's plan tier allows. Keys can carry an expiration date, are rate limited per hour, and can be suspended or permanently revoked by an organization admin at any time, immediately cutting off further use. API keys authenticate as themselves and cannot create or escalate other keys; only a signed-in human session can issue a new key.

Our compliance status

ReplenishRadar itself is not SOC 2 certified today. Our infrastructure provider, Google Cloud, holds SOC 2 Type II and ISO 27001 certifications for the underlying platform we run on; that is a statement about Google Cloud, not about ReplenishRadar, and we are not representing our own compliance posture through it. We do not have a committed certification date to share. If SOC 2 is a hard requirement for your evaluation, tell us and we will give you a straight answer about where that stands.

Reporting a vulnerability

Please email [email protected] with:

• A description of the issue and its potential impact
• Steps to reproduce, including affected URL, request, or component
• Any proof-of-concept code, screenshots, or logs you can share safely
• Your name or handle if you would like to be acknowledged (anonymous reports welcome)

Please do not:

• Disclose the vulnerability publicly before we have had a chance to triage and patch
• Test on customer accounts you do not own or have explicit permission to test
• Attempt to access, modify, or destroy other customers' data
• Run automated scanners that produce significant load
• Phish, social engineer, or otherwise target ReplenishRadar staff or customers

What you can expect from us

• Initial response within 2 business days acknowledging receipt
• Triage within 7 business days with severity assessment and rough timeline
• Status updates at least every 14 days while the issue is open
• Credit in our acknowledgments section below if you would like, and the report turns out to be a real issue
• We will not pursue legal action against good-faith researchers operating within this policy

Scope

In scope:

• replenishradar.com (marketing site)
• app.replenishradar.com (application)
• api.replenishradar.com (backend API)
• Our official Shopify app
• Our official Amazon SP-API integration

Out of scope:

• Third-party services we integrate with (Stripe, Shopify, Amazon SP-API, Google Cloud); report directly to them
• Social engineering of staff or customers
• Denial-of-service attacks or volumetric testing
• Issues in dependencies that have public CVEs we are tracking and patching on our normal cadence
• Self-inflicted issues (modifying your own browser to bypass controls and reporting the bypass)

Vulnerability classes we are particularly interested in

• Authentication or authorization bypass, cross-tenant data access especially. Row-level security is our primary defense, and we run quarterly RLS penetration tests. A failure here is the highest-severity class.
• Stored XSS, CSRF, or session-fixation in the app
• Server-side request forgery against backend endpoints
• Insecure direct object reference allowing access to another organization's data
• Webhook signature bypass on Shopify, Amazon, or Stripe handlers
• API key or session token leakage in logs, public assets, or error responses

Disclosure timeline

We aim to patch confirmed vulnerabilities within:

• Critical (RCE, cross-tenant data access, auth bypass): 7 days
• High (privilege escalation, stored XSS, data integrity): 30 days
• Medium (information disclosure, CSRF): 90 days
• Low (best-practice findings): next regular release

Public disclosure timing is coordinated with the reporter. We support a 90-day default disclosure window from initial report, extended if a fix requires more time and the reporter agrees.

Acknowledgments

Researchers who have responsibly disclosed vulnerabilities will be listed here. As of 2026-04-27, no public reports have been received yet. We will populate this list with the first acknowledgment.

Machine-readable policy

This policy is also published per RFC 9116 at /.well-known/security.txt.

Updates

This policy is reviewed at least annually. Current version last updated 2026-04-27.