Legal
Security
How StreamBoost protects accounts, money and credentials — limited to controls that are actually implemented.
Last updated
Authentication
- Passwords are stored as bcrypt hashes. The plaintext is never written to the database or to a log.
- Sessions are server-side records. The browser holds an opaque token; revoking the session row ends access immediately, and an expired session cannot be revived.
- Google and Apple sign-in are supported. StreamBoost never sees your password at those providers.
- Email addresses are verified before an account is fully usable, and password resets use single-use, short-lived, hashed tokens.
- Sign-in verification emails include the request’s address and browser so that you can recognise a sign-in that was not you.
Session cookies
- HttpOnly, so page JavaScript cannot read the token.
- Secure, derived from how the request actually arrived rather than assumed.
- SameSite, so another site cannot ride your session.
Authorisation
Administrative pages and actions call a server-side admin check before anything runs, and that check redirects rather than returning — there is no path through an admin action that executes with a customer’s authority. Customer queries are scoped by the user id resolved from the session, not by an identifier the browser supplies.
Provider credentials
Credentials for fulfilment providers are sealed with AES-256-GCM before they are stored. They are opened only inside the server-side adapter that makes the outbound call. They are never sent to a browser, never included in a server action’s response, and never written to a log. A provider whose credential cannot be decrypted is refused rather than called unauthenticated.
Payments
Card details are entered on Stripe’s own hosted page and never reach this application, so there is no card number here to lose. Payment webhooks are signature-verified, and each event is recorded once so a replayed webhook cannot credit a balance twice.
Money handling
Balances are integer cents, every movement is written to a ledger inside the same transaction that changes the balance, and refunds are claimed with a conditional update so a double-click cannot refund twice.
Anti-abuse
- Account creation requires a proof-of-work challenge and an attestation that first-party JavaScript actually ran, so a request-only script cannot sign up by replaying captured values.
- Authorisation values are server-issued, single-use and replay-resistant.
- Rate limiting is applied per address, email, account, session and endpoint. Identifiers are hashed rather than stored raw.
- Security events are recorded with their decision and score for review, and carry an expiry so they are not kept indefinitely.
Input validation
Prices, quantities and discounts are computed on the server from stored configuration. A value posted by a browser is treated as a request, never as an authority — a tampered client changes what it displays and nothing about what it is charged.
Data layer
PostgreSQL is reached exclusively through parameterised queries, and the database port is bound to localhost rather than exposed to the internet. Schema changes are applied as reviewed, additive migrations.
Transport
Traffic is served over HTTPS with certificates managed automatically by the reverse proxy.
Administrative accountability
Administrative actions — cancelling an order, issuing a refund, changing a provider, acting on an account — are written to an audit log with the administrator’s identity. Summaries are composed server-side rather than echoed from input, so a credential cannot reach the audit log by accident.
What StreamBoost does not claim
No certifications, no guarantees.
StreamBoost is not SOC 2, ISO 27001 or PCI DSS certified, and has not been through a third-party security audit or penetration test. No system is unhackable, and this page describes controls rather than promising outcomes.
Card data is handled by Stripe, which maintains its own compliance posture; that is Stripe’s certification and not StreamBoost’s.
Reporting a vulnerability
If you believe you have found a security issue, please report it privately by opening a ticket in the support area rather than disclosing it publicly. Include enough detail to reproduce the issue. Please do not run automated scans, denial-of-service tests, or anything that would degrade the service or touch another user’s data.
Your part
- Use a password you do not use anywhere else.
- Keep the email address on your account current and secured.
- Sign out on machines you do not control.
- Treat any unexpected sign-in email as worth investigating.