H3ight

Security & Trust

Last Updated: October 2, 2026

At H3ight, security is foundational to everything we build. Our platform manages safety-critical data for rope access companies—equipment inspections, compliance records, workforce certifications, and financial information. We take the responsibility of protecting this data seriously.

This page outlines the security practices, architecture, and policies that protect your data on the H3ight Platform.

1. Data Encryption

1.1 Encryption in Transit

Production browser and device connections use HTTPS with TLS (Transport Layer Security) to protect data in transit. TLS termination and supported protocol versions are managed by our hosting and proxy providers.

  • The application recognizes HTTPS connections forwarded by the hosting proxy
  • Production settings enable HTTP Strict Transport Security (HSTS) headers, which tell browsers to use HTTPS for subsequent connections
  • HTTP-to-HTTPS redirects depend on deployment configuration

1.2 Encryption at Rest

The application encrypts selected sensitive database fields using Fernet encryption. Production startup requires a field encryption key. This protection applies to fields explicitly configured for encryption, rather than every database field or uploaded file.

  • Examples include person phone numbers and addresses, multi-factor authentication secrets, and JSA signature data
  • Encryption of database disks, object storage, and backups is a separate infrastructure control managed by the hosting providers and deployment configuration

2. Authentication & Session Security

2.1 Password Security

User passwords are never stored in plain text. We use PBKDF2 with SHA256 hashing, a key derivation function designed to slow password guessing. Each password is salted with a randomly generated value.

2.2 Session Management

Browser authentication tokens are managed using httpOnly cookie-based JWTs (JSON Web Tokens). This approach provides several security advantages:

  • httpOnly cookies prevent client-side JavaScript from reading those cookies, reducing the risk of token theft through cross-site scripting (XSS)
  • Secure flag restricts authentication cookies to HTTPS in production
  • CSRF checks protect cookie-authenticated requests that change data. Selected account endpoints use credential checks instead. SameSite is configurable and may be set to None for deployments with separate frontend and API domains
  • Tokens have limited lifetimes with automatic refresh mechanisms

API clients can also authenticate with bearer tokens or scoped API keys; the browser cookie protections apply to cookie-based sessions.

3. Multi-Tenant Data Isolation

The H3ight Platform is a multi-tenant system where each organization's access is controlled through organization membership, permissions, and organization-scoped API queries. The application also implements Row-Level Security (RLS) in PostgreSQL as an additional layer for tables with RLS policies.

  • Organization-scoped API views filter records to the active organization and check access permissions
  • The production deployment configuration enables RLS. Enforcement depends on the database role and organization context used by each code path
  • System tasks and authorized platform administration may need broader access. RLS does not automatically cover every query or replace application permission checks

4. Role-Based Access Control (RBAC)

Access within each organization is controlled through a permission system with six roles:

  • Admin
  • Manager
  • Supervisor
  • User
  • Inspector
  • Viewer

An organization Admin manages organization settings, users, and billing. Module roles and individual capabilities determine which operational actions a person may perform; a module can also be set to No access. Protected API actions check these permissions on the server. A role does not override restrictions on signed or otherwise protected records.

5. Audit Logging

The platform uses application request logging and stored audit records for different purposes. Request logging middleware is designed to write metadata for requests under /api/ to application logs, including:

  • The user and organization, when available to the middleware
  • The HTTP method and endpoint accessed
  • Response status code
  • Request duration

Stored audit records capture creates, updates, deletes, and selected workflow actions where audit helpers are integrated. They can include the actor, organization, timestamp, affected record, and field changes. Coverage varies by workflow; they are not a complete history of every request or database change. Application log availability and retention depend on logging configuration. Stored audit records are subject to retention policies.

6. Infrastructure

The platform's deployment configuration uses:

  • Render — Application hosting and managed PostgreSQL database
  • Cloudflare R2 — S3-compatible object storage supported for file uploads and off-site backups when configured
  • PostgreSQL — Our primary database, supporting database transactions, constraints, and row-level security policies

Storage locations depend on provider and deployment settings; this page does not promise that every service or copy of data stays in one country. See our Privacy Policy for data location and transfer information.

6.1 Backups and Recovery

The deployment configuration includes daily database dump and media backup jobs to separate R2 backup storage. These jobs require provisioned storage and credentials. Database uploads are checked for size, and media backups include content checks and a restore verification tool. These are scheduled copies; the application does not implement continuous point-in-time recovery. Any hosting-provider recovery features depend on the service plan and configuration.

7. Compliance-Ready Architecture

The H3ight Platform is built with compliance in mind from the ground up:

  • Soft delete — Many operational record types are marked as deleted and hidden from normal views. Some records and administrative cleanup operations use permanent deletion, so this is not a universal retention guarantee.
  • Audit records — Integrated workflows record actions and changes to support review and accountability, as described in Section 5.
  • Data export — Organizations can export supported records and reports in formats such as CSV and PDF, depending on the module and their permissions. These features do not provide a single export of all organization data.
  • Inspection scheduling — Configurable inspection intervals with automatic due-date tracking help organizations plan equipment checks. Using the platform does not itself establish compliance with an industry standard.
  • Electronic signatures — Safety documents (including JSAs and Safe Work Plans) support electronic signing and acknowledgements for accountability. Signing methods vary by workflow.

8. Application Security Practices

  • Input validation — API serializers and workflow checks validate submitted data. Client-side checks provide additional feedback. These controls reduce risk; they are not a guarantee against every injection attack.
  • CORS policies — Cross-Origin Resource Sharing uses a configured allowlist of browser origins. CORS controls browser access and does not replace authentication or authorization.
  • Rate limiting — API endpoints are subject to default user and API-key throttles, with separate limits for login and selected public workflows. Limits and coverage vary by endpoint and configuration; throttling reduces abuse rather than guaranteeing its prevention.
  • Dependency management — We use automated dependency update checks and vulnerability scans in CI. Findings still require review and remediation.
  • Secure defaults — Production settings include secure cookies, anti-framing headers, and content-type protections. The backend Content Security Policy (CSP) defaults to report-only: it reports violations without blocking resources unless enforcement is explicitly enabled in deployment configuration.

9. Incident Response

H3ight's documented incident response process covers:

  1. Detection and containment — Identify and contain the incident to prevent further impact.
  2. Assessment — Determine the scope, severity, and affected data.
  3. Notification — Affected users and organizations are notified without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach, in accordance with applicable law and our Privacy Policy.
  4. Remediation — Implement fixes and preventive measures to address the root cause.
  5. Post-incident review — Document lessons learned and update security practices accordingly.

10. Reporting Security Issues

If you discover a security vulnerability or have concerns about the security of the H3ight Platform, please contact us immediately:

Email: security@h3ight.com

We take all security reports seriously and will respond promptly. We ask that you:

  • Provide sufficient detail to reproduce the issue
  • Allow reasonable time for us to address the vulnerability before public disclosure
  • Do not access or modify other users' data during your research

11. Contact Us

For questions about our security practices or to request additional information, contact us:

Security: security@h3ight.com
General: hello@h3ight.com
Mail:
H3ight LLC
PO Box 370922
Las Vegas, NV 89137

This Security & Trust page was last updated on the date shown above. We continuously improve our security practices and will update this page as our security posture evolves.