Security Practices

All user sessions are managed through a standards-based identity provider using JWT bearer tokens. Password-based accounts enforce strong credentials and are checked against known breached-password databases (HIBP) at registration and during password changes.

Role-based access is enforced server-side via a dedicated roles table (never stored on the user profile). Administrative actions require an explicit admin role verified by a security-definer function. No client-side flag can grant elevated privileges.

Google OAuth is available as an additional sign-in method, brokered securely through the platform identity layer.

Every customer-facing table in our database has Row Level Security enabled. This means unauthenticated requests cannot read or write user data, even if a query is crafted outside the application.

Key RLS patterns we follow:

• User-scoped data — policies restrict reads and writes to the currently authenticated user ID.
• Admin checks via SECURITY DEFINER — a dedicated role-verification function is used inside policies so admin access does not introduce recursive policy loops.
• Column-level grants — draft or internal fields (e.g., draft payloads, update audit columns) are excluded from broad SELECT grants and are only accessible to authorized backend processes.

Some tables are reserved exclusively for backend workflows and internal operations. They remain protected by RLS with no policies and no API-level grants for anonymous or authenticated roles, which means the default behavior is deny-all.

Backend-only tables are accessed only via:

• Server-side functions running with service-role credentials for maintenance, deduplication, and reconciliation jobs.
• Admin-authenticated server functions that first verify the caller holds an admin role before performing any privileged read or write.

We maintain append-only audit tables for sensitive operations. These logs are not editable through the application and are retained for operational review and accountability.

Audited activities include:

• Password reset requests — who triggered the reset, for which customer email, timestamp, and outcome.
• Promo code usage — redemptions, attempted redemptions, and member-discount audit trails.
• Marketing preference changes — opt-in, opt-out, and verification events with IP and timestamp attribution.

Our incident-response process is designed for quick detection and containment:

• Detection — automated security scanning on code commits and scheduled database linting against known misconfiguration patterns.
• Assessment — findings are triaged against a maintained baseline of accepted risks; new or elevated findings are reviewed before deployment.
• Containment & recovery — RLS and role-based controls allow rapid revocation of access without rebuilding infrastructure.
• Post-incident — affected audit logs are reviewed, and any necessary policy or grant changes are applied through versioned database migrations.

We collect only the information necessary to fulfill orders, provide customer support, and maintain platform security. Sensitive fields are stored in the backend database and are never exposed through public APIs without an explicit, narrowly scoped policy.

Marketing preferences are stored with verification tokens and audit timestamps. Unsubscribe tokens are single-purpose and hashed where applicable. We do not sell customer data.

Dr Jays Peptides runs on a managed platform that provides automated infrastructure patching, encrypted data transport (TLS), and encrypted data at rest. The application layer (business logic, access rules, and audit handling) is the responsibility of Dr Jays Peptides.

Platform-level security features we rely on include: automated TLS termination, managed database backups, and network isolation between application and database layers.

If you discover a security issue, please report it to Support@drjayspeptides.com. Include enough detail to reproduce the issue, and allow reasonable time for us to investigate before any public disclosure.

We do not currently operate a bug-bounty program, but we review all good-faith reports and take appropriate action.