01
Encryption in transit & at rest
All traffic is served over TLS 1.2+ with HSTS. Stored objects and database volumes are encrypted at rest with AES-256. There is no unencrypted path between your browser and our storage layer.
Trust & Security
Security at WavBin.
The technical controls behind the promise: encryption, access control, token hygiene and abuse defenses — written for the people who evaluate platforms for a living.
02
Row-level access control
Authorization is enforced at the database layer with row-level security policies on every table, and application queries additionally filter by owner ID. A policy failure returns zero rows — never an error that leaks existence.
03
Credential & session hardening
Passwords are salted and hashed with bcrypt. Accounts lock for 15 minutes after 5 consecutive failed logins, idle sessions expire after 30 minutes, and refresh tokens rotate on use.
04
Zero-exposure sharing
Share links resolve through secure views that strip internal IDs, storage paths and owner identifiers. Recipients never receive a value they could replay against another object.
How we protect your work
The controls that run under every upload, playback, share and sign-in.
01
Short-lived signed URLs
Audio playback and downloads are served through expiring signed URLs — 30 seconds for shared-track playback, 60 seconds for Board voice notes and images. Every fresh play revalidates the share link server-side before a new URL is minted.
02
Hashed, single-use invite tokens
Board guest and e-signature invites carry random 256-bit tokens stored only as SHA-256 hashes. Tokens are single-use, time-boxed and revocable; accepting one grants least-privilege access to exactly one Board or document.
03
Privilege separation
Administrative operations run under an isolated service role reachable only from server-side code after caller verification. Role checks execute as security-definer functions against a protected roles table — never from client-readable state.
04
Abuse & brute-force defenses
Auth forms use honeypot fields and submission-timing checks to reject automated signups. Sensitive endpoints enforce database-backed rate limits (e.g. 10/hour and 25/day on invite acceptance) that fail closed on error.
05
Path-scoped object storage
Every object is stored under a per-user prefix (user_id/filename) and storage policies require that prefix to match the authenticated principal. Cross-account reads are rejected at the storage layer, not by application convention.
06
Bit-exact file handling
Uploads are stored byte-for-byte with original filenames and extensions preserved; downloads set Content-Disposition accordingly. We never transcode, normalize or re-encode your audio.
07
Metadata-only AI processing
AI features operate on track metadata — titles, tags, tempo, folders — not on the contents of your audio. Dictation audio is transcribed in memory and never written to disk or retained.
08
Private support channel
Support tickets are readable only by the filing account and administrators, enforced by row-level policies. Ticket content is never indexed, shared or exposed to other users.
Technical FAQ
Straight answers for infrastructure evaluators.
How is access to my audio authorized?
Every request carries a signed JWT that the database evaluates against row-level security policies. Objects are additionally namespaced under your user ID in storage, so a valid token for another account still fails the path check. Authorization is re-evaluated per request — there is no cached "logged-in" bypass.
What can a share-link recipient actually reach?
Only the rows exposed by a dedicated secure view for that link: display-safe track fields, nothing else. Storage paths, internal UUIDs and owner identifiers are stripped before serialization, playback URLs expire in seconds, and password-protected links use PBKDF2-hashed credentials with rate-limited verification.
What happens cryptographically when I revoke or delete?
Revoking a share invalidates its token hash immediately; outstanding signed URLs expire within seconds. Deleting audio cascades through Lists, Boards and folders via foreign-key constraints and removes the storage object, so no residual reference can resolve.
How are guest and signer identities verified?
Invites are bound to an exact email address and a single-use, expiring token stored as a SHA-256 digest. Acceptance is rate-limited and fails closed. Guests receive a scoped grant to one Board — no account credentials are ever created or transmitted by the inviter.
Do you log access to my content?
Yes. Board mutations are recorded in an append-only audit log via database triggers, capturing actor, section and timestamp. Share views and downloads are counted for analytics. Audit data is private to the Board and never exposed publicly.
How do I report a vulnerability?
Use the contact button below. Reports go directly to the engineering team, are triaged as priority, and we ask for reasonable disclosure while we investigate and remediate.
Your catalog, kept safe
Put your audio somewhere private, organized and built for the way teams behind the music actually work.