Open Storage Platform (OSP) Security Overview

Version: 0.7.1 Beta Draft Effective: [EFFECTIVE DATE] Organization: btec LLC Contact: b@btec.me

Plain-Language Summary

What this means for you:

Your data is isolated. Every customer gets their own database with tenant-level isolation. Nobody else can see your data.
We hash passwords properly (Bcrypt). We never store plaintext passwords.
Every change is logged. An append-only audit trail means you can always see who did what.
Financial operations are protected. Idempotency keys prevent double-charges. Approval gates prevent unauthorized money movement.
We use HTTPS everywhere. Data in transit is encrypted. We enforce strict content security policies.
This is beta. We haven't done SOC 2, PCI, or HIPAA certifications. Don't rely on those if you need them.
You have responsibilities too. Strong passwords, managing who has access, securing your Stripe account — Use a good password manager like Bitwarden.

This is a description of what we've built, not a guarantee. We're being transparent about how the system works.

1. Architecture Overview

OSP follows a single-tenant logical isolation model. Each customer gets a dedicated database instance on Neon PostgreSQL, with the application layer running on Vercel. While underlying infrastructure is shared, data isolation is enforced at multiple layers.

┌──────────────────────────────────────────────┐
│                  Client Browser               │
│              (HTTPS / TLS 1.3)                │
└──────────────────┬───────────────────────────┘
                   │
┌──────────────────▼───────────────────────────┐
│              Vercel Edge / Serverless          │
│     Next.js App Router + Middleware            │
│     - CSP headers                              │
│     - Session validation                       │
│     - Rate limiting (reasonable)               │
└──────────────────┬───────────────────────────┘
                   │
┌──────────────────▼───────────────────────────┐
│           Neon PostgreSQL (per-customer)       │
│     - Row-Level Security (RLS)                 │
│     - 3 database roles (owner/app/auth)       │
│     - Encrypted at rest                        │
│     - Append-only audit log                    │
└──────────────────┬───────────────────────────┘
                   │
        ┌──────────┼──────────┐
        │          │          │
   ┌────▼───┐ ┌───▼────┐ ┌──▼──────┐
   │ Stripe  │ │ Resend │ │ Inngest │
   │(your acct)│(email) │ │  (jobs) │
   └─────────┘ └────────┘ └─────────┘

2. Data Isolation

2.1 Database-Level Isolation

Each customer gets their own dedicated Neon PostgreSQL database. No customer data is co-mingled in the same database.

2.2 Row-Level Security (RLS)

Within each database, PostgreSQL Row-Level Security policies enforce tenant isolation:

Each tenant's data is tagged with a tenant_id
RLS policies ensure queries can only return rows belonging to the authenticated tenant
Even if the application layer has a bug, the database itself prevents cross-tenant data leakage

2.3 Three Database Roles

OSP uses three distinct PostgreSQL roles with escalating privileges:

Role	Purpose	Capabilities
auth	Authentication operations	Login validation, session management, user CRUD — no access to business data
app	Application operations	Business logic queries, CRUD on business tables — subject to RLS
owner	Schema management	DDL operations, migrations, RLS policy management — used only by b-tec tooling

The application connects using the app role. The auth role is used only for auth-specific queries. The owner role is never exposed to the application runtime.

3. Authentication & Sessions

3.1 Password Storage

Passwords are hashed using Bcrypt with appropriate work factor
Plaintext passwords are never stored, logged, or transmitted after initial hash
Password reset tokens are single-use and time-limited

3.2 Session Management

OSP uses Better Auth for session management
Sessions are server-side, with session tokens stored in HTTP-only cookies
Session duration: 7 days by default
Sessions are invalidated on password change and logout

3.3 API Authentication

API access uses per-user API keys
Keys are generated with sufficient entropy
Keys can be scoped
Keys are stored hashed in the database

4. Financial Operations Protections

4.1 Idempotency Keys

All financial-related operations use idempotency keys. This means the same operation submitted twice won't result in a double-charge. If a network timeout occurs and you retry, the system recognizes the duplicate and returns the original result.

4.2 Approval Gates

High-value or sensitive operations require explicit approval before execution.

4.3 Append-Only Audit Log

All changes to data are recorded in an append-only audit log. This means:

Actions cannot be modified or deleted after the fact
Every change is attributed to the authenticated user and timestamped
The audit log provides an immutable record for compliance and debugging

5. Network & Transport Security

5.1 HTTPS Everywhere

All client-to-server communication is encrypted via HTTPS (TLS 1.2+)
HSTS headers enforce HTTPS on subsequent visits
API endpoints require HTTPS — plain HTTP connections are rejected

5.2 Content Security Policy (CSP)

The application sends strict CSP headers that:

Restrict which scripts can execute
Prevent inline script execution
Limit resource loading to known origins

5.3 Database Connections

All database connections use TLS encryption
Connection strings with credentials are stored as environment variables, never in source code

6. Infrastructure Security

6.1 What b-tec Controls

OSP application code and deployments
Database schema, migrations, and RLS policies
Infrastructure provider configuration (Vercel, Neon, Resend, Inngest)
Session management and authentication systems
Security patches and dependency updates

6.2 What You Control

Your Stripe account security (API keys, dashboard access, webhook secrets) (Use a good password manager)
User account passwords and API key management
User access control and permission assignments within your instance
Facility and tenant data accuracy and integrity
Security of your own devices and networks used to access OSP

7. Subprocessor Security

Our subprocessors and their security postures:

Provider	Purpose	Security Notes
Vercel	Hosting	SOC 2 Type II, ISO 27001, GDPR compliant. Your data processed in USA
Neon	Database	SOC 2, encrypted at rest and in transit. Data in USA
Stripe	Payments	PCI DSS Level 1. Your own account, not b-tec's
Resend	Email	SOC 2. Only sends transactional email — no email content stored long-term
Inngest	Job queue	SOC 2. Job payloads may contain data needed for processing

8. Incident Response

8.1 Reporting

Report security issues to: b@btec.me We aim to acknowledge reports within 48 hours.

8.2 Breach Notification

If we discover a breach affecting your data, we will notify you within 72 hours of confirmation, describing:

Nature of the breach
Data potentially affected
Steps we've taken
Recommended actions for you

9. What We Have NOT Done (Yet)

The following security validations have NOT been completed:

Item	Status	Target
SOC 2 audit	Not started	Post-beta
PCI DSS assessment	Not applicable (Stripe handles payments)	N/A
HIPAA BAA	Not available	Post-beta if needed
Third-party penetration test
Formal threat model
Vulnerability disclosure program

10. Your Security Checklist

When you start using OSP, here's what you should do:

[ ] Use a strong, unique password (Store in a good password manager)
[ ] Enable any available multi-factor authentication [Future option after beta]
[ ] Review and manage user (team) access regularly
[ ] Secure your Stripe account with strong credentials and 2FA
[ ] Don't share API keys in chat, email, or version control
[ ] Report anything suspicious to b@btec.me

This document describes OSP's security architecture as of the version date. It is not a warranty or guarantee of security. Security is a shared responsibility.