Trust
Security
Hostra uses argon2id password hashing with pepper, opaque session cookies, server API keys verified with HMAC-SHA256, role-based scopes per route, rate limiting, TLS, strict CORS, and a tamper-evident audit hash-chain with an integrity check. Card numbers are never stored — Hostra works only with Stripe tokens, reducing PCI scope.
Credentials and sessions
- Passwords hashed with argon2id and a server-side pepper; never reversible, never logged.
- User sessions use an opaque, HttpOnly, Secure, SameSite=None cookie — no tokens in browser storage.
- Server clients authenticate with API keys (hstra_ prefix) verified via HMAC-SHA256; the full key is shown once.
- Role-based access: 12 scopes checked per route; a key only reaches what its scopes allow.
Cardholder data
Hostra never receives or stores a card number. Cards are tokenised in the browser by Stripe.js and only the resulting payment method token reaches the API, which materially reduces PCI DSS scope. CVV is never sent to or kept by Hostra.
Integrity and exactly-once
- A final compare-and-set commit prevents a settlement from committing twice.
- Exclusive leases with fencing tokens prevent two workers from executing the same intent.
- A transactional outbox guarantees events are never lost and never invented.
- Check-before-retry confirms with the provider before any repeat call.
Transport and boundary
- TLS everywhere; HSTS on the website.
- CORS allow-list per origin with credentials; wildcard origins are rejected for requests with credentials.
- Rate limiting per identity and per IP on sign-in and change routes.
- Outbound webhooks signed HMAC-SHA256 with a timestamped signature header; verify before processing.
Responsible disclosure
Report vulnerabilities to security@hostracore.com. Please include reproduction steps and allow reasonable time for a fix before public disclosure.