hiroi Legal

Security Policy

Effective Date: February 7, 2026 Last Updated: February 7, 2026 Version: 1.0


1. Overview

hiroi is committed to maintaining the security, availability, and confidentiality of the hiroi platform and your data. This page describes the security measures we implement, aligned with SOC 2 Trust Service Criteria.

2. Infrastructure Security

2.1 Hosting

  • Containerized deployment using Docker for isolation and reproducibility
  • Application runs behind a reverse proxy with TLS termination
  • Network segmentation between application, database, and cache layers

2.2 Network Security

  • All external traffic encrypted with TLS 1.2 or higher
  • Content Security Policy (CSP) headers enforced
  • HTTP Strict Transport Security (HSTS) enabled
  • Firewall rules restricting unnecessary inbound/outbound traffic

2.3 Database Security

  • PostgreSQL with authentication required for all connections
  • Database accessible only from the application network
  • Regular automated backups

3. Application Security

3.1 Authentication

  • Google OAuth 2.0: Secure third-party authentication
  • Passkeys (WebAuthn): Phishing-resistant passwordless authentication
  • Magic Links: Time-limited, single-use email authentication tokens
  • Two-Factor Authentication (2FA): TOTP-based second factor support
  • Sessions managed server-side with secure cookie attributes

3.2 Authorization

  • Role-based access control (user, admin)
  • Resource-level authorization checks (IDOR prevention via JOIN queries)
  • API key scoping (widget-specific, non-transferable)

3.3 Input Validation

  • Server-side validation on all inputs
  • Parameterized database queries (SQL injection prevention)
  • Content Security Policy headers (XSS prevention)
  • CSRF protection on all state-changing operations

3.4 Rate Limiting

  • Redis-backed rate limiting on all API endpoints
  • Per-user and per-IP rate limits
  • Graduated limits for authentication endpoints
  • Widget chat endpoints rate-limited per visitor

4. Data Security

4.1 Encryption

  • In Transit: TLS 1.2+ for all communications
  • At Rest: Database-level encryption
  • Secrets: API keys hashed before storage, 2FA secrets encrypted

4.2 Access Controls

  • Principle of least privilege for all system components
  • No shared accounts or credentials
  • API keys generated with sufficient entropy
  • Server secrets never exposed to client-side code

4.3 Data Classification

Classification Examples Handling
Confidential API keys, server secrets, 2FA secrets Encrypted/hashed, never logged
Private Email, name, conversation content Access-controlled, retention limits
Internal Configuration, analytics (aggregate) Standard access controls
Public Documentation, widget embed code No restrictions

5. Widget Security

5.1 Authentication Modes

  • Domain Safelist: Origin header validation with exact domain matching
  • Session Signed: HMAC-SHA256 signed tokens with configurable TTL
  • Neither mode exposes API keys or secrets in the browser

5.2 Client-Side Security

  • No secrets embedded in widget JavaScript
  • Origin validation prevents cross-site misuse
  • Signed tokens are site-specific and expire

6. Operational Security

6.1 Monitoring and Logging

  • Comprehensive activity logging for all user actions
  • Security event logging (authentication, authorization failures)
  • Audit trail preserved even after account deletion

6.2 Incident Response

We maintain an incident response process that includes:

  1. Detection: Monitoring and alerting for security anomalies
  2. Containment: Immediate isolation of affected systems
  3. Investigation: Root cause analysis and impact assessment
  4. Notification: Affected users notified within 72 hours of confirmed breach
  5. Remediation: Fix and deploy countermeasures
  6. Review: Post-incident review and process improvement

6.3 Vulnerability Management

  • Dependencies monitored for known vulnerabilities
  • Security patches applied promptly
  • Responsible disclosure program for external researchers

7. Data Retention and Disposal

Data is retained according to our Privacy Policy retention schedule. When data reaches end of retention:

  • Personal data is permanently deleted or anonymized
  • Backup copies are removed within the backup rotation cycle
  • Deletion is logged in the audit trail

8. Business Continuity

  • Automated database backups
  • Container-based deployment enables rapid recovery
  • Documented recovery procedures

9. Compliance

9.1 SOC 2 Alignment

Our security controls are designed to align with AICPA SOC 2 Trust Service Criteria:

  • Security: Access controls, encryption, monitoring
  • Availability: Infrastructure redundancy, incident response
  • Processing Integrity: Input validation, error handling
  • Confidentiality: Data classification, encryption, access controls
  • Privacy: Data minimization, retention limits, user rights

9.2 GDPR Alignment

We implement measures to support GDPR compliance:

  • Data processing agreements with sub-processors
  • Data subject rights (access, portability, erasure)
  • Consent management and tracking
  • Data protection impact assessments for high-risk processing

10. Reporting Vulnerabilities

If you discover a security vulnerability, please report it to:

Email: [email protected]

We appreciate responsible disclosure and will:

  • Acknowledge receipt within 48 hours
  • Provide an initial assessment within 5 business days
  • Keep you informed of remediation progress
  • Not take legal action against good-faith security researchers

11. Contact

For security-related inquiries:

hiroi - Security Email: [email protected]

Cookie Preferences

We use essential cookies to make our service work. You can choose to enable optional cookies for a better experience. Learn more

Cookie Preferences

Essential

Required for the service to function

Always On

Analytics

Help us understand how the service is used