Security Policy

This document describes the security practices, data protection measures, and incident response procedures for all Tempered Tools applications operated by Fire Burns Up Inc.

Infrastructure Security

Hosting and Deployment

• All applications are hosted on Railway, a SOC 2 Type II compliant platform.
• Each application runs in an isolated container with its own dedicated PostgreSQL database.
• Deployments are automated via Git push to the main branch. No manual server access is required or permitted during normal operations.
• All infrastructure configuration is managed through code and environment variables. No credentials are stored in source code.

Encryption

• In transit: All connections use TLS 1.2 or higher. HTTPS is enforced for all public endpoints. SSL certificates are automatically provisioned and renewed.
• At rest: All PostgreSQL databases use encrypted storage volumes. Redis instances use encrypted connections.
• Backups: Database backups are encrypted and managed by the hosting provider with automated retention policies.

Network Security

• Databases are accessible only within the private network. No database ports are exposed to the public internet during normal operation.
• Inter-service communication uses private networking within the hosting platform.
• All external API calls (Shopify, email delivery) use authenticated HTTPS connections.

Application Security

Authentication and Authorization

• All Shopify apps use Shopify's OAuth 2.0 session token authentication. No custom authentication schemes are used for admin access.
• API endpoints validate session tokens on every request. Expired or invalid tokens are rejected.
• Webhook endpoints verify Shopify HMAC signatures before processing any payload.

Input Validation

• All user input is validated at the boundary using Zod schema validation before processing.
• Database queries use parameterized statements via Prisma ORM. No raw SQL concatenation is used.
• Environment variables are validated at startup against typed schemas. Applications will not start with invalid configuration.

Dependency Management

• Dependencies are pinned via a lockfile and audited regularly for known vulnerabilities.
• The codebase uses TypeScript strict mode across all applications and packages.

Access Controls

• Access to production infrastructure (hosting dashboard, database consoles) is restricted to authorized personnel with multi-factor authentication.
• Source code is hosted in a private repository with branch protection rules. All changes require review before merging to main.
• Access to customer personal data is limited to automated application processes. Manual database access for debugging requires documented justification and is logged.
• Third-party service accounts (email delivery, hosting) use dedicated API keys with minimum required permissions.

Audit Logging

• All applications produce structured logs (JSON format) that include request identifiers, timestamps, and operation context.
• Email notifications log recipient, timestamp, and delivery status without logging email content or customer PII in plain text.
• Authentication events (OAuth installs, session validations, webhook verifications) are logged.
• Hosting platform provides infrastructure-level access logs and deployment audit trails.

Data Loss Prevention

• Each application has its own isolated PostgreSQL database. A failure in one application cannot affect data in another.
• Automated database backups run on a schedule managed by the hosting provider with point-in-time recovery capability.
• Test environments use separate databases populated with synthetic data. Production customer data is never copied to test environments.

Incident Response Policy

This section documents our procedures for identifying, responding to, and recovering from security incidents that may affect customer data or service availability.

Severity Levels

Response Procedures

1. Identification and Triage

• Assess the scope: which applications, databases, and customer data are affected.
• Assign a severity level based on the definitions above.
• Document the initial findings, including timestamps, affected systems, and indicators of compromise.

2. Containment

• Revoke any compromised credentials (API keys, database passwords, OAuth tokens) immediately.
• Isolate affected services. If a single application is compromised, take it offline without affecting other applications.
• Preserve logs and evidence before any remediation changes.

3. Notification

• Shopify: Notify Shopify Partner Support within 24 hours of confirming a breach that affects merchant or customer data.
• Affected merchants: Notify affected merchants within 72 hours with a description of what data was involved, when the incident occurred, and what remediation steps have been taken.
• Regulatory authorities: Notify relevant data protection authorities as required by applicable law (e.g., GDPR 72-hour notification requirement).

4. Remediation

• Identify and fix the root cause. Deploy the fix through the standard CI/CD pipeline with expedited review.
• Rotate all credentials that may have been exposed, even if compromise is not confirmed.
• Verify the fix by reviewing logs and monitoring for recurrence.

5. Post-Incident Review

• Conduct a post-incident review within 5 business days.
• Document the timeline, root cause, impact, and corrective actions.
• Update security procedures to prevent similar incidents.

Reporting a Vulnerability

If you discover a security vulnerability in any Tempered Tools application, please report it to security@temperedtools.xyz. We will acknowledge receipt within 48 hours and provide an initial assessment within 5 business days.

We ask that you do not publicly disclose the vulnerability until we have had an opportunity to investigate and address it.

Contact

For security-related inquiries: