Trust
Security
HostraCore uses argon2id password hashing with pepper, opaque session cookies, M2M API keys with HMAC-SHA256, RBAC scopes per route, rate limiting, TLS, strict CORS, and a tamper-evident audit hash-chain with a proof-of-integrity endpoint. PAN is 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.
- Human sessions use an opaque, HttpOnly, Secure, SameSite=None cookie — no JWT in browser storage.
- M2M clients authenticate with API keys (hstra_ prefix) verified via HMAC-SHA256; the full key is shown once at creation.
- RBAC: 12 scopes evaluated per route; a key can only reach the surface its scopes allow.
Cardholder data
HostraCore never receives or stores a primary account 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 transmitted to or persisted by HostraCore.
Integrity and exactly-once
- Terminal compare-and-set commit prevents a settlement from committing twice.
- Exclusive leases with fencing tokens prevent two workers from executing the same intent.
- Transactional outbox guarantees events are never lost and never fabricated.
- Query-before-retry reconciles with the provider before any repeat call.
Transport and boundary
- TLS everywhere; HSTS on the web surface.
- CORS allow-list per origin with credentials; wildcard origins are rejected for credentialed requests.
- Rate limiting per identity and per IP on authentication and mutation 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 remediation before public disclosure.