Data Encryption

Data security is foundational to everything we build at BttrForm. When people submit sensitive information through your forms -- personal details, financial data, health information -- they trust that the data is protected at every stage. This article explains the encryption and security measures BttrForm employs to safeguard your data from collection to storage.

Encryption at Rest (AES-256)

All data stored in BttrForm is encrypted at rest using AES-256 (Advanced Encryption Standard with 256-bit keys). This is the same encryption standard used by governments and financial institutions worldwide for protecting classified information.

What AES-256 Protects

• Form responses -- Every response submitted through your forms is encrypted before being written to disk.
• File uploads -- Documents, images, and other attachments uploaded through file fields are encrypted in object storage.
• User credentials -- Passwords are hashed with bcrypt (not stored in plaintext) and authentication tokens are encrypted.
• Database backups -- All automated backups are encrypted using the same AES-256 standard.

How It Works

When data enters BttrForm, the following process occurs:

1. Data received via API
2. Application processes and validates data
3. Data encrypted with AES-256 before storage
4. Encrypted data written to PostgreSQL / Object Storage
5. Encryption keys managed by cloud KMS (Key Management Service)

Encryption in Transit (TLS 1.3)

All data transmitted between your browser (or your respondents' browsers) and BttrForm servers is encrypted using TLS 1.3, the latest version of the Transport Layer Security protocol.

What TLS 1.3 Protects Against

• Eavesdropping -- Third parties cannot read data as it travels over the network.
• Tampering -- Data cannot be modified in transit without detection.
• Replay attacks -- TLS 1.3 uses unique session keys, preventing attackers from replaying captured traffic.

TLS Configuration Details

BttrForm enforces strict TLS policies:

Connection:  TLS 1.3
Cipher:      TLS_AES_256_GCM_SHA384
Certificate: Valid, issued by Let's Encrypt
HSTS:        Strict-Transport-Security: max-age=31536000

Row-Level Security (RLS)

BttrForm uses Supabase PostgreSQL as its primary database, and every table is protected by Row-Level Security (RLS) policies. RLS ensures that database queries can only access rows that belong to the authenticated user.

How RLS Works

RLS is enforced at the database level, not the application level. This means that even if there were a bug in BttrForm's application code, the database itself would prevent unauthorized data access.

-- Example: Users can only read their own forms
CREATE POLICY "Users can view own forms"
  ON public.forms
  FOR SELECT
  USING (auth.uid() = user_id);

-- Example: Users can only read responses for their own forms
CREATE POLICY "Users can view own responses"
  ON public.responses
  FOR SELECT
  USING (
    form_id IN (
      SELECT id FROM public.forms WHERE user_id = auth.uid()
    )
  );

What RLS Guarantees

• Data isolation -- User A can never see User B's forms or responses, even through direct database queries.
• Defense in depth -- Security is enforced at both the application layer (API authentication) and the database layer (RLS policies).
• Automatic enforcement -- RLS policies apply to every query, including those from internal tools and admin panels.

Key Management

Encryption is only as strong as the management of encryption keys. BttrForm follows industry best practices for key management:

Key Lifecycle

• Generation -- Encryption keys are generated using cryptographically secure random number generators provided by the cloud KMS.
• Storage -- Keys are stored in a dedicated Key Management Service (KMS), separate from the data they protect. Keys never exist in plaintext on disk.
• Rotation -- Master encryption keys are rotated annually. Data encryption keys (DEKs) are rotated more frequently using envelope encryption.
• Access control -- Only specific service accounts can request key operations. Human access to key material is prohibited.

Architecture:
  Master Key (KMS) --> Data Encryption Key (DEK) --> Your Data

  - Master key never leaves KMS hardware
  - DEK is encrypted by master key (envelope encryption)
  - DEK is decrypted in memory only when needed

Envelope Encryption

BttrForm uses envelope encryption, where data is encrypted with a data encryption key (DEK), and the DEK itself is encrypted with a master key stored in the KMS. This approach allows for efficient key rotation without re-encrypting all stored data.

Data Isolation

Beyond encryption, BttrForm implements multiple layers of data isolation:

• Logical isolation -- Each workspace operates as an isolated tenant with separate data boundaries enforced by RLS.
• Network isolation -- Database servers are in private subnets, not accessible from the public internet. Only BttrForm application servers can connect.
• Backup isolation -- Database backups are encrypted and stored in a separate region from the primary database.

Compliance Summary

BttrForm's encryption and security measures align with the requirements of major compliance frameworks:

Verifying Encryption

You can verify that your connection to BttrForm is encrypted by checking the padlock icon in your browser's address bar. Clicking on it will display the certificate details, confirming TLS 1.2 or 1.3 is in use.

For API connections, you can verify the TLS version programmatically:

curl -vI https://api.bttrlabs.com 2>&1 | grep "SSL connection"
# Output: SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384