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

1. Do NOT open a public GitHub issue for security vulnerabilities
2. Report security concerns privately through the repository owner or GitHub Security Advisories. Do not disclose exploitable details in a public issue.
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)

Maintainers responding to production credential exposure or provider compromise should follow the production credential rotation and incident response runbook. Keep incident details and credentials in private systems; do not post them in a public issue or pull request.

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

EmailJS request controls must be configured in the EmailJS dashboard. Add only the production and staging origins to the Domains allowlist, enable the provider's IP-based rate limit, and enable reCAPTCHA for the contact template. The browser SDK also blocks headless browsers and throttles this app's sends to one request every 10 seconds; these client checks supplement provider-side limits and cannot replace them. lib/sendmail.js validates and length-limits template fields before sending and returns a generic error without exposing provider response details.

The newsletter currently collects no email address and does not send a provider request. Do not add a send until a verified subscription and unsubscribe flow is implemented.

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: A report-only policy is configured in next.config.mjs while storefront and wallet compatibility is verified.

next.config.mjs sends Content-Security-Policy-Report-Only for every route. This lets browsers report violations without blocking checkout, Firebase auth, or wallet integrations during the compatibility rollout. The allowlist covers the Firebase Auth, Firestore, Storage, and Installations APIs; EmailJS; the configured Stellar RPC networks and testnet Friendbot; and the image hosts used by the storefront. Freighter is a browser extension and injects its provider into the page, so it does not require a remote script source here.

The policy intentionally omits unsafe-eval. unsafe-inline remains for Next.js's current inline route/bootstrap scripts and the storefront's inline style attributes. Remove those exceptions only after migrating to nonce or hash-based scripts and class-based styles and verifying the rendered routes.

Before changing the header to enforcing Content-Security-Policy, inspect the browser console for report-only violations on the landing page, sign-in, image uploads, product pages, checkout, and the admin orders page. Confirm Google popup auth and Freighter signing in supported browsers. Add a source only when the violation maps to a dependency or service the app uses; never use a wildcard scheme or add unsafe-eval to silence reports. Keep the report-only header until those checks pass in staging, then switch the header name and repeat the same checks before production rollout.

• Firebase Authentication handles user sessions
• Admin access is controlled via email whitelist (NEXT_PUBLIC_ADMIN_EMAILS)
• No passwords are stored in the application

• 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 email OTP flow generates and verifies codes in the browser, so it is not secure proof of identity. Do not rely on it for account security. A production-grade flow must generate and verify expiring codes on a trusted server and protect them from replay. 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 payment form fields are UI-only placeholders. In production:

• Integrate with a PCI-compliant payment processor (Stripe, etc.)
• Never handle raw card data on your servers
• Use tokenization for card storage

Ensure your Firestore security rules restrict:

• Read/write access based on authentication
• Admin operations to authorized users only
• Data validation at the database level

Example rules:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /ShoeSafariProducts/{productId} {
      allow read: if true;
      allow write: if request.auth != null &&
        request.auth.token.email in ['admin@example.com'];
    }
  }
}

• 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, use a private GitHub Security Advisory or contact the repository maintainers directly. We aim to acknowledge reports within 48 hours.