Frontier
Security posture
Security is mostly about where trust lives and how small it is. Stone.js pushes trust to the boundary and keeps the core minimal, so the safe path is also the natural one. This page collects the posture the manual already implies.
#Trust the boundary, not the depths
Validate and authenticate at the edge; let the domain assume its inputs are clean and its caller known.
| Practice | Type | Description |
|---|---|---|
| Validate every input | validation | Put validate(...) on routes that accept input; the handler runs only on well-formed data. |
| Authenticate statelessly | auth | Verify JWT/OAuth at the boundary; no session store to protect or leak. |
| Authorize isomorphically | authz | One rule set guards the API and shapes the UI; they can never disagree. |
| Project your output | resources | Return resources, not raw models, so internal fields never leak by accident. |
#Secure defaults
- Cookies: set
httpOnly,secureand a strictsameSiteon anything sensitive; better still, prefer stateless tokens. - Secrets: read from the environment through typed getters at the edge, injected inward; never hard-code them or read
process.envin the domain. - Server-only code: keep database and secret access behind server loaders so it never ships to the browser bundle.
- Response headers: add security headers (nosniff, referrer policy, CSP) as a small response middleware, once, for every route.
#A small trusted base
The micro-kernel depends on three primitives and carries no platform code; capability is added as packages you choose. A smaller trusted base is a smaller attack surface, and the agnostic core means a vulnerability in one platform's plumbing stays in that adapter, not in your domain.