We take security seriously at Mova Store. If you discover a security vulnerability, please report it responsibly.

1. Do NOT open a public GitHub issue for security vulnerabilities
2. Email security concerns to: security@movalabs.dev
3. Include a detailed description of the vulnerability
4. Provide steps to reproduce if possible

• Acknowledgment within 48 hours
• Regular updates on our progress
• Credit in the security advisory (if desired)

All sensitive configuration is stored in environment variables. Never commit secrets to the repository.

Required environment variables are documented in .env.local.example. Copy this file to .env.local and fill in your values.

cp .env.local.example .env.local

The Soroban escrow contract follows security best practices:

1. Non-custodial: Funds flow directly from buyer to contract to merchant
2. Access Control: Only authorized parties can dispatch/refund orders
3. Token Whitelist: Only approved tokens can be used for payment
4. Event Emission: All state changes emit events for transparency
5. Error Handling: Typed errors prevent unexpected failures

1. Input Validation: All user inputs are validated and sanitized
2. XSS Prevention: HTML entities are escaped before rendering
3. HTTPS Only: All API calls use HTTPS
4. No Sensitive Data in URLs: Sensitive data is sent via POST body
5. Content Security Policy: Configured in Next.js headers

• Supabase Authentication handles user sessions.
• Client-side admin UI access is controlled via NEXT_PUBLIC_ADMIN_EMAILS or the is_admin JWT claim in app_metadata.
• Server-side database and storage writes are enforced via PostgreSQL Row Level Security (RLS) policies in supabase/schema.sql.
• No passwords or private secrets are stored in the application repository.

To authorize an admin user for product mutations and storage uploads in Supabase, use one of the following methods:

1. Method 1: public.admin_users table (Recommended) Insert the admin's email address into the admin_users table:

   insert into public.admin_users (email)
   values ('admin@example.com')
   on conflict (email) do nothing;

2. Method 2: Custom JWT App Metadata (is_admin: true) Assign the is_admin: true flag to the user's app_metadata in Supabase Auth:

   update auth.users
   set raw_app_meta_data = coalesce(raw_app_meta_data, '{}'::jsonb) || '{"is_admin": true}'::jsonb
   where email = 'admin@example.com';

   Or via the Supabase Admin API / Dashboard:

   await supabase.auth.admin.updateUserById(userId, {
     app_metadata: { is_admin: true },
   });

3. Method 3: Whitelist Environment Variable (NEXT_PUBLIC_ADMIN_EMAILS) Include the admin email in .env.local:

   NEXT_PUBLIC_ADMIN_EMAILS=admin@example.com,lead@example.com
   

• Dependencies are regularly updated for security patches
• Use npm audit to check for vulnerabilities
• CI pipeline fails on high-severity vulnerabilities

Before submitting a PR, ensure:

• No secrets or API keys are committed
• User inputs are validated and sanitized
• No eval() or dangerouslySetInnerHTML usage
• Error messages don't expose sensitive information
• Dependencies are from trusted sources
• No console.log with sensitive data

The current OTP implementation generates codes client-side for demonstration purposes. In production:

• Move OTP generation to a server-side API route
• Implement rate limiting on OTP requests
• Add OTP expiration (recommended: 5 minutes)

The card number, expiry and CVV fields on /checkout are a UI-only demo affordance. No card data may be transmitted, persisted or processed by this application:

• Card values live only in React state for the lifetime of the tab. They are never sent to an API, logged, written to localStorage, placed in a URL, or handed to a third party.
• Because no card value leaves the browser, Mova Store stays outside PCI DSS scope for cardholder data.
• The UI labels the fields as demo-only so a shopper cannot mistake them for a real payment form; the sanctioned path is the Stellar (Soroban) checkout.

Do not "finish" this form in place. If real card payments are ever required, integrate a PCI-compliant processor (Stripe, etc.) and let it collect card data in its own iframe/tokenization flow — never handle raw card data on our servers.

Apply supabase/schema.sql. The shipped policies are already the hardened, admin-only model — there is no outstanding "tighten later" step:

• Products — public.products and the products storage bucket are publicly readable; insert, update and delete on both require public.is_admin() ("Admins can insert/update/delete products", "Admins can upload/update/delete product images").
• Orders — buyers may read only their own rows (auth.uid() = user_id or auth.email() = user_email); status changes and deletions are admin-only.
• Allowlist — public.admin_users, which backs public.is_admin(), is readable by admins only.

public.is_admin() (defined next to the admin_users table in supabase/schema.sql) is the single source of truth for admin access: it returns true when the caller's JWT carries app_metadata.is_admin = true, or when the caller's email is in public.admin_users. Grant admin rights through one of those two mechanisms; never widen a policy to work around a missing admin entry.

Never expose the Supabase service role key in the browser.

• Testnet: Used for development, tokens have no real value
• Mainnet: Real value transactions, requires additional auditing

Before mainnet deployment:

1. Smart contract security audit
2. Penetration testing
3. Rate limiting implementation
4. Monitoring and alerting setup

• Users connect their own Freighter wallet
• Private keys never leave the user's browser
• Transactions require explicit user approval

For security-related inquiries:

• Email: security@movalabs.dev
• Response time: Within 48 hours